On Jan 29, 2018, at 10:51 AM, Alexey Melnikov wrote: > Viktor, > > > On 29/01/2018 15:46, Viktor Dukhovni wrote: >>> On Jan 29, 2018, at 2:35 AM, Valery Smyslov <[email protected]> wrote: >>> >>> Again, please provide the text. Otherwise the iterations >>> update-review may last forever. >> It is unclear from the current state of the document whether >> my suggestion to have just one MIME type with compression >> signalled separately was deemed acceptable or not. >> >> Unless others feel strongly otherwise, I think the document >> should have just one MIME type, with compression indicated >> via "Content-Encoding" for HTTP and: >> >> Content-Type: application/tlsrpt+json; conversions=gzip >> >> for email. > What you propose above doesn't work for email, because this is no longer > JSON, so can't be decoded by a generic JSON parser. What you are proposing is > a new Content-Transfer-Encoding, which has absolutely 0 chance of being > deployed in email.
Alexey is 100% correct. The whole point of the "+json" convention is to let email processors know that they can parse the attachment as JSON without having to know more about the rest of the content. So existing mail processors (including spam and virus filters) might well try to parse the gzipped content as JSON and fail because it's not JSON, and either delete the attachment, bounce the message, or declare it unreadable. Even if you omit the "+json" suffix from the content-type name, most mail readers essentially ignore the other parameters to the content-type header when deciding how to interpret the attachment (except in a small number of special cases), and don't pass those parameters to whatever application interprets the content. This is unfortunate and contrary to the design of MIME, but it's also been the behavior of the vast majority of implementations practice for the entire history of MIME deployment. It was relatively easy for mail readers to lookup content-type in a table and determine what application to launch to pass the content to, but there was no obvious mechanism that could be used to pass the content-type parameters to that application that didn't also allow the sender of a message to invoke existing applications in dangerous ways. Keith _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
