- From: Martin Thomson <mt@lowentropy.net>
- Date: Tue, 05 Mar 2024 15:12:09 +1100
- To: "nidhijaju@google.com" <nidhijaju@google.com>, ietf-http-wg@w3.org
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:internet-drafts@ietf.org>> > 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 <felixh@meta.com>, Nidhi Jaju <nidhijaju@google.com> > > > 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
Received on Tuesday, 5 March 2024 04:12:37 UTC