IETF Logo Mail Archive

Re: [dispatch] Zstandard compression

Harald Alvestrand <harald@alvestrand.no> Thu, 14 December 2017 14:48 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2411293D6 for <dispatch@ietfa.amsl.com>; Thu, 14 Dec 2017 06:48:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1OWsUkMXh40 for <dispatch@ietfa.amsl.com>; Thu, 14 Dec 2017 06:48:44 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F361293F9 for <dispatch@ietf.org>; Thu, 14 Dec 2017 06:48:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 156EC7C3627; Thu, 14 Dec 2017 15:48:35 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWTBj21zG5Ip; Thu, 14 Dec 2017 15:48:33 +0100 (CET)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 28C1A7C0C3D; Thu, 14 Dec 2017 15:48:33 +0100 (CET)
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: DISPATCH list <dispatch@ietf.org>
References: <CAL0qLwatePp87tC6YGRj4=K0xivMfSr2QSDkn6VVkojvs4DW7A@mail.gmail.com> <E6EAC624-21A3-425A-B355-9D4EFA4F7CBB@seantek.com> <CAL0qLwbhPCJDBwNw0Q88kW5c2e_8msr+UwtV_4DnMXVOBZoGXA@mail.gmail.com> <2A0764E1-1ADA-4510-A717-23095A4362F0@seantek.com> <CAL0qLwYMA-HShoDvFtTcqK6dav=5Bfocf1TTJUsgB+3deVTzJA@mail.gmail.com> <dad5e711-3a91-69d1-d3ed-ee38e9237699@it.aoyama.ac.jp> <e88d3d87-a9e6-d37c-c138-68124c8aa449@alvestrand.no> <CAL0qLwYJXsE-kG1ev+na+ssYJM_QJCirJMt0_tsJK+fzCrHMVQ@mail.gmail.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <20c3e34b-a1f8-8aaa-81dd-88d8191d192c@alvestrand.no>
Date: Thu, 14 Dec 2017 15:48:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwYJXsE-kG1ev+na+ssYJM_QJCirJMt0_tsJK+fzCrHMVQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/TILjZL6Wnsfu1DPxlVilYzE12wo>
Subject: Re: [dispatch] Zstandard compression
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2017 14:48:46 -0000

Den 14. des. 2017 15:22, skrev Murray S. Kucherawy:
> On Tue, Nov 14, 2017 at 4:25 PM, Harald Alvestrand <harald@alvestrand.no
> <mailto:harald@alvestrand.no>> 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?
> 

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.

v2.26.15 | Report a Bug | By Email | System Status