Re: Fwd: New Version Notification for draft-jaju-httpbis-zstd-window-size-00.txt

[Martin Thomson <[e-mail]>]

This seems fine.  And 8M is a fine choice of limit.

However, I don't think that ㄟ( ▔, ▔ )ㄏ is a good interoperability strategy:

> Decoders are free to support higher or lower limits, depending on local limitations, if negotiated out-of-band. Many deployments of Zstandard operate in controlled, private environments and can directly communicate with their encoder and decoder to negotiate a higher or lower limit.

I think that it is obvious that decoders could support more.  But supporting less would not be following the standard.  The same goes for an encoder that wants a larger window.

We should encourage people to choose a different way of identifying that content-coding.  In other words, encoding > 8M or decoding < 8M is not Content-Encoding: zstd.

On Tue, Mar 5, 2024, at 14:16, Nidhi Jaju wrote:
> Hi all,
>
> I wrote a draft regarding window sizes in Zstandard Content Encoding 
> that aims to update RFC8878 
> <https://datatracker.ietf.org/doc/html/rfc8878> to require a specific 
> limit for improved interoperability.
>
> For context, we recently shipped zstd Content Encoding support in 
> Chrome 123 and came across incompatibilities in the field where 
> developers were confused when their compressed content was not able to 
> be decoded by Chrome, but was correctly decoded by curl and the zstd 
> CLI. Having an explicit agreed-upon limit would help deployers of zstd 
> to align their implementations and cause less user friction.
>
> I believe this topic was also previously discussed at 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2021JulSep/0137.html 
> and 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0178.html. 
> This was also discussed at the W3C WebPerf WG meeting 
> <https://docs.google.com/document/d/1ijP7yc6UXZVgzpXDVmBa7h70gxLpFcqdlOZzL3DRT_0/edit#heading=h.xn2d3li0b8op> 
> at TPAC 2023.
>
> Please let us know what you think.
>
> Best regards,
> Nidhi
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf..org <mailto:[e-mail]>>
> Date: Tue, Mar 5, 2024 at 7:26 AM
> Subject: New Version Notification for draft-jaju-httpbis-zstd-window-size-00.txt
> To: W. Felix P. Handte <[e-mail]>, Nidhi Jaju <[e-mail]>
>
>
> A new version of Internet-Draft draft-jaju-httpbis-zstd-window-size-00.txt has
> been successfully submitted by Nidhi Jaju and posted to the
> IETF repository.
>
> Name:     draft-jaju-httpbis-zstd-window-size
> Revision: 00
> Title:    Window Sizing for Zstandard Content Encoding
> Date:     2024-03-04
> Group:    Individual Submission
> Pages:    5
> URL:      
> https://www.ietf.org/archive/id/draft-jaju-httpbis-zstd-window-size-00.txt
> Status:   
> https://datatracker.ietf.org/doc/draft-jaju-httpbis-zstd-window-size/
> HTML:     
> https://www.ietf.org/archive/id/draft-jaju-httpbis-zstd-window-size-00.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-jaju-httpbis-zstd-window-size
>
>
> Abstract:
>
>    Deployments of Zstandard, or "zstd", can use different window sizes
>    to limit memory usage during compression and decompression.  Some
>    browsers and user agents limit window sizes to mitigate memory usage
>    concerns, causing interoperability issues.  This document updates the
>    window size limit in RFC8878 from a recommendation to a requirement
>    in HTTP contexts.
>
>
>
> The IETF Secretariat