> 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
