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: If it's an optional metadata tag that is backwards compatible with existing encoders and decoders I could see it providing quite a bit of value, even in the non-HTTP case of dictionary compression.
There was some discussion in the ZStandard repo about possibly reserving one of the skippable frame magic numbers for embedding a dictionary ID but there's some level of risk for collision with people who may be using those frames for watermarking or other application-specific use cases. As best as I can tell, the brotli stream format doesn't have a similar frame capability for metadata or application-specific data. We could create a container format that held the dictionary ID and stream (header basically, not unlike zip vs deflate) but that feels like a fairly large effort and the tooling would have to catch up to make it easy for developers to work with. At this point I'm hesitant to recommend adding anything to the payload itself that the existing brotli and zstd tooling can't process. Being able to create, fetch and test the raw files is quite useful for the developer workflow and for debugging deployments. Would it make sense to allow for future encoding formats to include a dictionary ID in the file itself and make the header optional in those cases (and make the embedded ID authoritative)? I'm not sure if that would make sense in this draft since this one is limited to the 2 existing encodings and it would be addressed in a new draft when the new encodings are created or if it makes sense to allow for it here without requiring that and explicitly require embedded ID's.
I don't think that you want to change the zstd or brotli format, only the content coding. That is, something like this: This does partly work against the idea that you might have a bunch of files that contain compressed versions of content. You can't just say . And you can't just decompress without some processing. What you get in exchange is a message payload with the advantages I described.
I do think we need to define a file format for it if we go down this path to ease adoption and it should probably have a magic signature at the beginning. Maybe something like gzip is to deflate but with a simple 3-byte signature followed by the hash followed by the stream data.