> On Jan 31, 2018, at 5:46 AM, Keith Moore <[email protected]> wrote:
>
> 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.
Fine, but could you explain, so I understand going forward, what
existing mail processors you have in mind that understand the
application/tlsrpt+json media type, or even expect it to be JSON?
Or generically understand a "+json" suffix (there's no special
semantics for the "+" character and such a media type suffix in
RFC2045).
What useful processing can they do with such JSON, without
understanding the schema?
If, as I expect, processing this media type in any meaningful
way requires new code, surely said new code can equally make
note of an optional "conversions" parameter associated with the media
type.
I accept that I am not "winning" on this point, but I am entirely
mystified as to why. There is no legacy here, and nothing useful
for general-purpose MUAs to display to users. The payload is a
file attachment that will be filed away for machine processing.
The media type could be:
application/tlsrpt+json [ ; conversions=gzip ]
or it could be
application/tlsrpt+{json,gzip}
And, I rather expect that in order to avoid problems with
line breaks and the like in email transport, the attachment
will *always* be compressed for transmission in email. Indeed
that should be strongly recommended if not outright required
by this specification.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
