Subject: Re: [dispatch] Zstandard compression

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Dec 2017 06:22:51 -0800

On Tue, Nov 14, 2017 at 4:25 PM, Harald Alvestrand <[email-masked]>
wrote:

> > Yes. But I think what Sean is saying is that above and beyond that,
> > you'd (in many if not most use cases) also want to know what the
> > decoded octet stream is about. Otherwise, this information has to be
> > transmitted on a side channel.
>
> One (horribly ugly) way of doing this is to have something like a
> "contains" parameter:
>
> mime-type: application/zstandard; contains="text/plain; charset=utf-8"
>
> That's one form of side channel for passing the data around. Not sure if
> anyone would use it.
> But it's such an ugly way of doing things that it should definitely be
> suggested on the media-types list, not here.
>

Interesting.  I haven't seen this technique used before.  Do other
compression methods have such a mechanism described and registered?

-MSK

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 14 Dec 2017 15:48:32 +0100

Den 14. des. 2017 15:22, skrev Murray S. Kucherawy:
> On Tue, Nov 14, 2017 at 4:25 PM, Harald Alvestrand <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

No - it's been quite controversial the times (long ago) that it's been
proposed.

I think it was suggested for RFC 6713 (application/gzip), but it didn't
survive the discussion. Probably that RFC should be taken as precedent.

---

From: "John Levine" <[email-masked]>
Date: 14 Dec 2017 10:02:35 -0500

>>     mime-type: application/zstandard; contains="text/plain; charset=utf-8"

Ugh.

>survive the discussion. Probably that RFC should be taken as precedent.

As far as I recall It didn't come up for 6713 which whizzed through
and had a concrete use case of DMARC aggregate reports where everyone
knew that the contents were XML.

Perhaps it came up for RFCs 1950, 1951, and 1952 which describe the
underlying encoding.

R's,
John