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.
With "conversions" defined in the document in
section 6.3, optional parameters. And section 6.4 and
all reference to the additional gzip-specific MIME type
deleted.
I am not a fan of a separate MIME type, just for compression,
when there is just a single underlying entity type.
While I have some sympathy to your argument, it is not going to work for
email (It could have worked for HTTP).
Best Regards,
Alexey
I'll have to leave fixing the MIME text to the document editors.
Too cycle-starved. Sorry about that.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
