Code change:
4. <del> The "br-d" content encoding identifies a resource that is a </del> <ins> The "dcb" content encoding identifies a resource that is a </ins> "Dictionary-Compressed Brotli" stream. <del> 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. </del> <ins> A "Dictionary-Compressed Brotli" stream has a fixed header that is followed by a Shared Brotli SHARED-BROTLI stream.  The header consists of a fixed 4 byte sequence and a 32 byte hash of the external dictionary that was used.  The Shared Brotli stream is created using the referenced external dictionary and a compression window that is at most 16 MB in size. The 36-byte fixed header is as follows: </ins> <del> Clients that announce support for br-d content encoding MUST be able </del> <ins> Clients that announce support for dcb content encoding MUST be able </ins> to decompress resources that were compressed with a window size of up to 16 MB.

Related discussion:
text: This made interpreting the body of the response quite challenging in that you needed to have a request in order to make sense of it. More recently, the specification has changed to having the client list available dictionaries, with the server echoing the one it chooses. Both use header fields. There is a third option, which is to embed the dictionary identification (which is a hash of the dictionary) ahead of the compressed content. This has some real advantages: Requests could use delta encoding. There is - of course - a real question about availability of the dictionary, but we have that problem with encrypted content codings and keys. That is a problem we solve for responses with a field. It might be solved using the same technique, combined with the client-initiated content coding advice. Or applications can use their own systems. A field costs a lot more bits. This would not benefit from header compression, so it might be a net loss in some cases, but in many cases it would be a distinct win because 32 bytes of hash in the body of a request is far less than a field name and field value containing a base64 encoding of those same 32 bytes. It also comes with disadvantages: Header compression could remove a lot of the cost in bytes. It might be ever-so-slightly more complex for encoding and decoding to have to split the first 32 bytes off the body of a message.
On the encoding side, the main downside is that the cli tooling for brotli and Zstandard don't currently do the embedding so tooling would have to be added to prepend the hash to the files in a way that isn't standard for either (yet anyway) and for manually decompressing the files. Zstandard has identifiers for the dictionaries when using non-raw dictionaries but both assume that raw dictionaries will be negotiated out of band. Technically it would be a pretty trivial modification for clients and servers that are doing the work, I'm just a bit concerned about the developer experience changes (and whatever needs to be done to get both brotli and Zstandard to understand what amounts to new file formats).
I opened issues with brotli and ZStandard to see if they would consider adding it to the format of their respective file formats.