> On Jan 29, 2018, at 10:51 AM, Alexey Melnikov <[email protected]>
> 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.
Note, compression in this context is NOT a transfer encoding, it cannot be
added by MTAs en route (as is the case with Base64 or Quoted-Printable)
nor is it an encoding applied at submission time by the MUA. This is
the original Content-Encoding associated with the payload. So I am NOT
proposing a new Content-Transfer-Encoding. Rather, I am proposing a way
of tagging a new MIME type as having its content optionally compressed
prior to (not during) transmission.
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. 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.
I don't yet agree with your objection. Why have two essentially identical
MIME types, when one will do? What's wrong with using a "conversions"
parameter to indicate compression? (There's precedent for this, as
indicated upthread in my message from Dec 7th, quoted below my signature)
Either way, the present draft version has partially adopted my suggestion.
It should either be fully adopted, or the relevant changes reverted.
--
Viktor.
Quoting my post of Dec 7th:
The issue is perhaps that while "HTTP" has "Content-Encoding",
MIME as defined in RFC-2045 does not:
https://www.ucolick.org/~sla/fits/mime/inetstds.html
MIME media types and the WWW
...
Section 14.11 gives the proper means of describing the HTTP
transmission of a file which is already compressed
The Content-Encoding entity-header field is used as a modifier
to the media-type. When present, its value indicates what
additional content codings have been applied to the entity-body,
and thus what decoding mechanisms must be applied in order to
obtain the media-type referenced by the Content-Type header field.
Content-Encoding is primarily used to allow a document to be
compressed without losing the identity of its underlying media
type. Unfortunately it seems reasonably clear that Content-Encoding
cannot be applied as if it were a MIME "Optional parameter" with the
expectation that it could be used when transferring compressed files
via e-mail. This observation is based upon section 19.4.4. It appears
that a complete description of compressed files transmitted via e-mail
requires a new RFC enhancing the MIME standard.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.4
19.4.4 Introduction of Content-Encoding
RFC 2045 does not include any concept equivalent to HTTP/1.1's
Content-Encoding header field. Since this acts as a modifier on
the media type, proxies and gateways from HTTP to MIME-compliant
protocols MUST either change the value of the Content-Type header
field or decode the entity-body before forwarding the message.
(Some experimental applications of Content-Type for Internet mail
have used a media-type parameter of ";conversions=<content-coding>"
to perform a function equivalent to Content-Encoding. However, this
parameter is not part of RFC 2045.)
Thus, at the very least for HTTP, there should be just one media type,
and Content-Encoding should be used to signal compression. For email,
since we're introducing a new "multipart/report" subtype, and "Content-Encoding"
is not a standard MIME header, an appropriate media-type parameter (what
I earlier referred to as MIME "attribute") should be defined for
"application/tlsrpt". It could be the above "; conversions=gzip" or
something similar. The "application/tlsrpt" being a new media type,
you're free to define appropriate additional metadata.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
