Re: [w3ctag/design-reviews] jxl Content-Encoding (#541)

In the specification, I see this:
`If the codestream starts with bytes {0xFF, 0xD8, 0xFF, 0xE0}, the decoder shall decode a JPEG1 as specified in ISO/IEC 10918-1:1993(E). Otherwise, if the codestream starts with bytes {0x0A, 0x04, 0x42, 0xD2, 0xD5, 0x4E}, the decoder shall reconstruct the original JPEG1 codestream as specified in Annex M. Otherwise, the codestream shall be structured as shown in Table 1; the syntax is described in Annex A.`

So it seems linked heavily to JPEG processing, at least for the `{0x0A, 0x04, 0x42, 0xD2, 0xD5, 0x4E}` case. 

Is there a way to recognise the generic encoding, if this applies to other formats, or just the signature above is used and only for JPEG? 
If it is only for JPEG, then a new media type would be easier to deploy than going through the [IETF Review](https://tools.ietf.org/html/rfc5226#section-4.1) which is needed to update https://www.iana.org/assignments/http-parameters/http-parameters.xhtml , although the Content coding option is not wrong.

@annevk mime sniff applies only after Content-Encoding is processed, so it shouldn't be an issue if the content coding option is used (ie: no need to add a new signature for a repacking of jpeg)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/541#issuecomment-673348728