Re: Murray Kucherawy's No Objection on draft-ietf-httpbis-zstd-window-size-02: (with COMMENT)

Hi Murray,

Thank you for the comments.

As far as I know, there were not many widely deployed HTTP clients that
supported zstd until recently. While there is an interoperability risk
today, the publication of this document enables implementations to agree
upon a limit that was previously not consistently enforced, especially with
increasing deployment and adoption of zstd.

When we were rolling out zstd support in Chromium, we saw only some rare
cases of people using a window size of more than 8 MB. For anyone using a 9
MB window size like in your example, the decoding would fail. To better
inform anyone experiencing failures caused by the limit, we added a more
specific error code and additional debugging messages related to window
sizes and decoding failures to help them understand what they need to do in
that situation. It'd be helpful for other HTTP client implementations to
add similar logging.

Best,
Nidhi

On Thu, Aug 22, 2024 at 2:53 PM Murray Kucherawy via Datatracker <
noreply@ietf.org> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-httpbis-zstd-window-size-02: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-zstd-window-size/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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?
>
>
>