Code change:
request, the algorithm to be used is negotiated through the regular mechanism for negotiating content encoding in HTTP. <del> This document introduces two new content encoding algorithms: </del> The dictionary to use is negotiated separately and advertised in the "Available-Dictionary" request header. 3.1. <ins> This document introduces two new content encoding algorithms: br-d: Brotli RFC7932 using an external compression dictionary and a compression window of not more than 16 MB. zstd-d: Zstandard RFC8878 using an external compression dictionary and a compression window of not more than 8 MB. 3.2. </ins> The client adds the algorithms that it supports to the "Accept- Encoding" request header. e.g.: <del> 3.2. </del> <ins> 3.3. </ins> If a server supports one of the dictionary algorithms advertised by the client and chooses to compress the content of the response using

Related discussion:
text: If we end up that bundles the dictionary hash with the compressed stream we can make sure the tooling for that file format handles the window size stuff for zstandard automatically (my main concern is around unexpected breakage from different server and client window requirements that only trigger when resources grow). The language will be a bit complex but will probably have to look something like
If I may chime in for some tactical consideration : In an update scenario, it's common for a new resource to be slightly larger than the old one it replaces. The expectation is that we generally tend to add stuff over time. A formulation which caps the window size to the size of the dictionary would introduce problems for all these update cases, which are expected to be the majority of update scenarios. On the other hand, we don't want this increase in size to be completely uncapped, in order to keep control of memory size. And if the new resource is really much larger than the old one, the benefits of delta compression are dubious anyway. So the suggestion is to authorize a window size which is slightly larger than the external dictionary size. As to how much larger exactly, a suggestion here is by +25% (x1.25). I would expect a large majority of update scenarios to fit into this picture, with the new resource being slightly larger than the old one by a few %. For the less common cases where the new ressource is much larger than the old one, Zstandard could still employ the dictionary but only for the beginning of decompression. The compression process will have to select a window size which remains under the specified limit (x1.25 external dictionary size). As a technical insight, note that byte-accurate window size is only a thing when the window is the entire decompressed content. Otherwise, the window size is encoded in a condensed format, which can only represent increments by 1/8th of a power of 2. This is not a problem to determine this "largest window size under the specified limit", but due to limited accuracy, you can already guess what would be the problem is we were to keep the formulation "not more than the larger of 8 MB and the size of the dictionary". Imagine that the external dictionary size is bytes, and the new resource to delta-compress is , aka 1-byte larger than the dictionary.