IMO if you want to define application/tlsrpt in such a way that readers/processors can reliably distinguish between clear text JSON and gzipped JSON , say by looking at the first few bytes of the content for the header magic number indicating gzip compression, you're free to do so. You just can't name the content-type something+gzip, nor expect readers to parse a parameter to tell them how to interpret it.
Sent from my iPhone > On Jan 31, 2018, at 3:52 PM, Viktor Dukhovni <[email protected]> wrote: > > > >>> On Jan 31, 2018, at 3:12 PM, [email protected] wrote: >>> >>> I fail to see any interoperability concern. Perhaps, I'm missing >>> something. Please explain. >> >> The +json suffix is defined to mean that the content consists of JSON, >> and can be parsed as such, independent of any understanding of the >> rest of the media type name or its parameters. >> >> So unless you have a time machine and can go back and change the rules >> defining >> +json, structured syntax suffixes, content type parameters, etc. this is a >> nonstarter. > > Ah finally, the right keywords to help me find the relevant document: > > https://tools.ietf.org/html/rfc6838#section-4.2.8 > https://tools.ietf.org/html/rfc6839#section-3.1 > > I have never before run into RFC6839. So "+json" is special after all. > > I don't see a "+gzip" in the relevant IANA registry: > > > https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml > > It seems that is that's to be used, then this draft must also register "+gzip" > with IANA. > > The alternative is to forgo the explicit "+json" and "+gzip" structured syntax > suffixes entirely and stick with application/tlsrpt (with optional > "conversions"), > because, for example, the compressed document is actually still ultimately > JSON, > so it is not clear why we elide that fact when compressing, if it is useful > when > not compressing? > > It does not look like multiple suffixes are allowed, such as: > > application/tlsrpt+json+gzip > > And since the content should almost always be compressed in email > (to make sure the contend is not broken by in-transit line folding, > or is too large), the "+json" tag is will be rarely present, while > "+gzip" adds little information. > > Indeed tlsrpt already implies "JSON" anyway. So "+json" is redundant. > > Bottom line, I guess I don't care anymore. The editors can just > fix the draft to remove the partial use of the "conversions" approach. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
