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: But if the new resource is 11.25 MB or larger, then the compressor will automatically limit the window size to 11 MB (since it's the largest representable window size under the limit, which, in this particular instance, is ), achieving the wanted memory size control.
Since neither the server not the client may know what the resource size will be when compression starts (say, in a streaming HTML case), won't the 1/8th power of 2 granularity apply even for cases where the resource is the same size (or sometimes smaller) than the dictionary? For resources slightly larger than the old one, the dictionary would still be used for the majority of the resource but the last bit would fall back to regular window-based compression. I agree that having the dictionary available for the whole resource would provide better compression but I'm not sure where to draw the line. Something like a 25% fudge factor can be quite a bit when you start talking about 50 MB+ resources that might be close to where the client wants to draw the line anyway. They may have allowed the dictionary at 50 MB but not allow it's use at all if it needed 62 MB available for a window. A similar case could be made for the non-update case where you have a custom-built dictionary but the resource being compressed exceeds 8 MB. Only the first 8 MB of the resource would be able to use the dictionary. Hopefully at that point the compression window would have most of the stuff that was in the dictionary but the dictionary becoming unavailable is something we should expect for some cases with ZStandard, even if we use a fudge factor. Is there a way to convey the 1/8th power of two granularity on the window size or is it something that the ZStandard libraries will take care of automatically for users (i.e. setting the window size to 11 MB when the caller sets it to 11.24 MB)? I'm wondering how much of this implementors are going to have to deal with directly.
It depends if the compression side (server) is informed upfront of the size of the payload to compress. If not, then indeed you are right, the compressor will have to set a Window Size, and the granularity rule applies. So for example, let's assume the payload to delta-compress is 50 MB, and the reference dictionary is also 50 MB.