Define MIME type for stand-alone compression dictionaries

[pmeenan]

For raw stand-alone compression dictionaries for br-d and zstd-d content encoding, there should be a recommended file extension and MIME type to use for the resources. The MIME type should not be required for dictionary use.

For cases where a resource is used as a dictionary for future versions, it will have a MIME type already associated with the resource (javascript, css, wasm, etc). In the case where a custom dictionary is built, it is a raw bytestream without an inherent (or valid) type.

Something like application/compression-dictionary and cdict for a file extension.

See https://github.com/WICG/compression-dictionary-transport/issues/44

[annevk]

The MIME type should not be required for dictionary use.

I think we should require it (in Fetch prolly) for the standalone case.

[pmeenan]

The dictionaries are opaque blobs of octets with no structure, format or processing associated with them (to that extent, maybe application/octet-stream is a better default to reflect that they aren't "special").

A stand-alone dictionary could be a custom file containing snippets of html, js, image binary data, etc but it could also be an existing file that already has a mime type with it (i.e. common.js). I can't think of a strong case for wanting to use an existing resource as a stand-alone dictionary when it isn't being fetched/preloaded/prefetched but there's nothing technically wrong with it.

The only place where the format/structure matters is to the resources that were dictionary-compressed when they are decoded. The negotiation includes the dictionary hash to make sure both sides are working from the same set of reference octets for the dictionary when compressing or reconstituting the actual resource and that resource has whatever enforcements are already in place for MIME types.

Requiring a MIME type for dictionaries only for the stand-alone case doesn't bring any assurance. Even if a given origin doesn't want certain files to be used as dictionaries, they wouldn't be unless that had explicitly added the Use-As-Dictionary request header anyway.

[annevk]

I see. Curious to hear from @mnot and @reschke. If any kind of MIME type is in principle okay I guess we can't really enforce anything anyway.

[mnot]

It sounds like the media type should be whatever the 'native' format is -- if there's no 'native' structured format or format-associated processing model for a dictionary, it doesn't need a media type, UNLESS there is some security consideration for the standalone case?

[annevk]

As @pmeenan stated, the Use-As-Dictionary response header is the security mechanism, essentially.

[pmeenan]

Closing this out. If stand-alone raw dictionaries should have a dedicated MIME type we can tackle that separately as it's not specific to the content-encoding use case.