On 29/01/2018 16:17, Viktor Dukhovni wrote:
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.
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. This is limitation of some existing systems,
for example Windows.
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. 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.
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 don't yet agree with your objection. Why have two essentially identical
MIME types, when one will do?
Because your proposal doesn't work.
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.
Best Regards,
Alexey
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
