Window Sizing for Zstandard Content Encoding
draft-ietf-httpbis-zstd-window-size-03
Yes
Francesca Palombini
No Objection
Erik Kline
Jim Guichard
Paul Wouters
Warren Kumari
Note: This ballot was opened for revision 02 and is now closed.
Francesca Palombini
Yes
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Comment
(2024-08-22 for -02)
Sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-httpbis-zstd-window-size-02 ## Many thanks for writing this document. It was a short to the point document and i have no objections to see this moving forward. ## It does seem a bit unusual that Section 3 of the document uses BCP14 normative language, especially since this is an informational document. I understand the intention is to clearly outline the boundaries, but because the document is informational, it doesn’t carry the same normative weight. This could allow implementers the flexibility to overlook the suggested boundaries if they choose to do so.
Jim Guichard
No Objection
Murray Kucherawy
No Objection
Comment
(2024-08-21 for -02)
Sent
We're updating the content encoding "zstd" to be defined explicitly as: > Description: A stream of bytes compressed using the Zstandard protocol with a Window_Size of not more than 8 MB. I'm a little worried about interoperability here. We're establishing a constraint on the use of that content encoding keyword where there wasn't one before, without some kind of signaling to any current use cases. If I'm successfully currently streaming using a Window_Size of 9 MB, and using this content encoding, what should happen once this is published?
Paul Wouters
No Objection
Roman Danyliw
No Objection
Comment
(2024-08-19 for -02)
Not sent
Thank you to Vijay K. Gurbani for the GENART review.
Warren Kumari
No Objection
Zaheduzzaman Sarker
No Objection
Comment
(2024-08-21 for -02)
Sent
Thanks for this document and I have no concerns from transport protocol point of view. This is an informational document updating another informational document. I am assuming that zstd has been deployed and used to that extend that the update was essential. does that also indicate that the "informational" may not be any more the accurate category for this? Has this been considered?
Éric Vyncke
No Objection
Comment
(2024-08-12 for -02)
Sent
Thanks for the work done with this document. I have only one suggestion: adding the IANA registry URI in the IANA considerations.