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: IIRC, regular (as opposed to large-window) brotli allows distances up to ~56MiB, i.e. larger shared dictionaries would not be useful (== referenced)
Thanks. For the dictionaries to be usable for a broad set of apps (including large wasm bundles), I'm considering spec'ing: Brotli: Regular 16MB window, allowing for delta-compression of resources up to ~50MB. ZStandard: 128MB window, allowing for delta compression of resources up to around that size, depending on where the duplicated bytes are in the updated resource. The main difference with regular content-encoding is on the ZStandard side where the window is 8MB. For platforms that are resource constrained and are not willing to support a 128MB window they would be limited to Brotli (and then decide how large of a dictionary they are willing to keep and use). Another option on the ZStandard side would be to allow for a maximum window that is a multiple of the dictionary size (i.e. 8MB or 2 * dictionary size whichever is larger with a 128MB max). That way the client can have an upper limit that it knows in advance before advertising as being available. That adds complexity to the encoding side though. We have already seen cases where people want to delta-compress resources > 50MB (wasm apps) where they had to use ZStandard instead of Brotli because of the Brotli limits so I don't think a small limit like 8MB for ZStandard would work with this use case.
That massive resources exist is not sufficient justification to build a system that will not be available to some users. I would prefer a far smaller default. If only to encourage the use of smaller resources overall. Defining a separate codepoint for massive windows is possible, say . The scalable option also seems reasonable. Clients can then choose to offer dictionaries when they exceed available resources.
I'm ok using the same 8MB window ( I believe) that we use for for and note that the effectiveness of delta compression for responses > 8MB using may be limited. The scalable option concerns me that people are likely to get it wrong and it won't be obvious and the decompression will start to fail as the dictionary and resource size changes. NAME does that sound about right?