> On Jan 29, 2018, at 11:36 AM, Alexey Melnikov <[email protected]>
> wrote:
>
> What you are proposing is not a part of MIME. You can't introduce
> Content-Encoding header field in email and remaing backward compatible with
> existing code. The time for this proposal was unfortunately 20 years ago.
>> Are you sure your objection is a barrier to adoption? The proposed MIME
>> type defines an optional "conversions" parameter, which takes the value
>> "gzip" to mean that the content is compressed.
> MIME handling need to operate only on MIME type without optional parameters
> being
> available.
In practice, or in principle based on the standard? Surely MIME content-type
parameters are there for a reason, and can and do affect the interpretation of
various MIME types. For example "text/plain" has an optional "format = flowed".
> This is limitation of some existing systems, for example Windows.
This is not actually relevant to Windows, since compressed TLSRPT attachments
will have a ".json.gz" suffix, and when they are saved as files (no MUA will
display compressed JSON inline for the user to read). Once stored, the MIME
type will be inferred by Windows from the file extension, and everything will
work as expected.
This MIME type is primarily for machine processing with the aggregated results
from multiple sources available to users to be viewed via a suitable UI. Even
if it sometimes fails to display natively in email, it is not material, so long
as the content remains machine readable. Email messages with TLSRPT payloads
will be read primarily by bots, not people, and the bots could/would handle
a "conversions" parameter just fine.
>> Any implementation of
>> this MIME type would need to decompress the payload before reading it as
>> JSON, just as it would if the content type were "application/tlsrpt+gzip"
>> from section 6.4. That too can't be read (directly) by a JSON parser,
>> without first decompressing the content.
> You are proposing non backward compatible change.
No, this is a new MIME type, there is no legacy. The proposed parameter
applies *only* to this type. I am not proposing any sort of universal
retrofit of gzip encoding for legacy MIME types.
> An application that doesn't understand your "conversions" parameters
> wouldn't be able to decode and process application/tlsrpt+json. "+json"
> suffix means that the payload is JSON and not some other format.
No such applications presently exist. This is a new media type.
If this specification requires support for "conversions", then
the applications that parse this new media type will have to
support "conversions".
> The only way to make it work for email is to introduce a new MIME suffix
> which will mean "this is either JSON or gzip of JSON" and let applications
> guess whether something is gzip or not. For example"+jgzip". This suffix
> will need to be registered with IANA and has to be reviewed by Ned Freed
> (as the Designated Expert).
I'd agree with you, if I were trying to retrofit "conversions" on existing
media types. But that's not the case. I'd be curious to hear what Ned or
has to say on the subject.
> Because your proposal doesn't work.
I don't think the object is valid. The proposal does not change
email MIME in an incompatible way. Just another new media type, with
a new optional parameter. If media types are not able to add parameters,
then why bother with parameters?
RFC2045 says:
Parameters are modifiers of the media subtype, and as such do not
fundamentally affect the nature of the content. The set of
meaningful parameters depends on the media type and subtype. Most
parameters are associated with a single specific subtype. However, a
given top-level media type may define parameters which are applicable
to any subtype of that type. Parameters may be required by their
defining content type or subtype or they may be optional. MIME
implementations must ignore any parameters whose names they do not
recognize.
I think that matches this situation quite well, the content is a
JSON TLSRPT, that may be compressed if the conversions=gzip parameter
is present.
All this said, I will accept two media types if need be, the important
thing is that draft now needs some editing to make it conform to one
view or the other, not a chimera.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
