Code change:
3. <del> When a compression dictionary is available for use for a given request, the algorithm to be used is negotiated through the regular mechanism for negotiating content encoding in HTTP. </del> <ins> The "br-d" content encoding identifies a resource that is a "Dictionary-Compressed Brotli" stream. </ins> <del> The dictionary to use is negotiated separately and advertised in the "Available-Dictionary" request header. </del> <ins> A "Dictionary-Compressed Brotli" stream is a Brotli RFC7932 stream for a response that has been compressed with an external dictionary using a compression window not larger than 16 MB. Clients that announce support for br-d content encoding MUST be able to decompress resources that were compressed with a window size of up to 16 MB. With Brotli compression, the full dictionary is available during compression and decompression independent of the compression window, allowing for delta-compression of resources larger than the compression window. </ins> <del> 3.1. </del> <ins> 4. The "zstd-d" content encoding identifies a resource that is a "Dictionary-Compressed Zstandard" stream. </ins> <del> This document introduces two new content encoding algorithms: </del> <ins> A "Dictionary-Compressed Zstandard" stream is a Zstandard RFC8878 stream for a response that has been compressed with an external dictionary. </ins> <del> br-d: Brotli RFC7932 using an external compression dictionary and a compression window of not more than 16 MB. </del> <ins> Clients that announce support for zstd-d content encoding MUST be able to decompress resources that were compressed with a window size of at least 8 MB or 1.25 times the size of the dictionary, which ever is greater, up to a maximum of 128 MB. </ins> <del> zstd-d: Zstandard RFC8878 using an external compression dictionary and a compression window of not more than 8 MB. </del> <ins> The window size used will be encoded in the content (currently, this can be expressed in powers of two only) and it MUST be lower than this limit.  An implementation MAY treat a window size that exceeds the limit as a decoding error. </ins> <del> 3.2. </del> <ins> With Zstandard compression, the full dictionary is available during compression and decompression until the size of the input exceeds the compression window.  Beyond that point the dictionary becomes unavailable.  Using a compression window that is 1.25 times the size of the dictionary allows for full delta compression of resources that have grown by 25% between releases while still giving the client control over the memory it will need to allocate for a given response. </ins> <del> The client adds the algorithms that it supports to the "Accept- Encoding" request header. e.g.: </del> <ins> 5. </ins> <del> 3.3. </del> <ins> When a compression dictionary is available for use for a given request, the encoding to be used is negotiated through the regular mechanism for negotiating content encoding in HTTP through the "Accept-Encoding" request header and "Content-Encoding" response header. The dictionary to use is negotiated separately and advertised in the "Available-Dictionary" request header and "Content-Dictionary" response header. </ins> <del> If a server supports one of the dictionary algorithms advertised by </del> <ins> 5.1. The client adds the content encodings that it supports to the "Accept-Encoding" request header. e.g.: 5.2. If a server supports one of the dictionary encodings advertised by </ins> the client and chooses to compress the content of the response using the dictionary that the client has advertised then it sets the "Content-Encoding" response header to the appropriate value for the

Related discussion:
text: This changes the maximum ZStandard compression window to be the larger of 8 MB and the size of the dictionary. This allows for clients to limit the maximum window size to as low as 8 MB if they like (by not advertising support) while also allowing for clients to use larger dictionaries with ZStandard than they would be able to if the global limit was 8 MB.
NAME and NAME could you also take a look and see if the language looks ok?
Context: URL aims to clarify the window size limit for the Content Encoding token as it wasn't clear in RFC8878. Since the Compression Dictionary Transport draft hasn't been published yet, we should also add some window size considerations to it for and to maintain interoperability. I think in Chrome we ended up using . NAME
NAME could you comment on how this impacts Brotli dictionary decode? Is the dictionary independent from the compression window (so we can adopt the same defaults as or do we need to specify something relative to the size of the dictionary? NAME NAME for ZStandard, to allow for delta-encoding large resources, is reasonable or should it be ? We have use cases for delta-encoding wasm applications where the dictionary can easily be upwards of 50 MB.
For Zstandard, the states that the entirety of the dictionary is accessible as long as the input is <= Window Size. Therefore, to give an extreme case, it's possible to have a 50 MB dictionary, and it's entirely accessible even if the Window Size is only 1 KB, but only as long as the data to de/compress is <= 1 KB. As soon as we reach 1 KB + 1, reaching the dictionary is no longer valid. For delta compression, this has consequences. Presuming the reference is ~50 MB, and the updated content is also ~50 MB, one would need a window size of ~50 MB to ensure access into the dictionary during the entire reconstruction process. But if the updated content is just a bit bigger, say ~51 MB, a ~50 MB window size would allow delta operation only during the first ~50 MB, the last ~1 MB would have to be compressed without dictionary. If follows that the size of the dictionary is irrelevant for the Window size. What matters is for how long one wants to access the dictionary while rebuilding the content.