Re: [dispatch] Zstandard compression

Harald Alvestrand <harald@alvestrand.no> Wed, 15 November 2017 00:26 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 CED4A1250B8 for <dispatch@ietfa.amsl.com>; Tue, 14 Nov 2017 16:26:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DOjs4ZWgxs-g for <dispatch@ietfa.amsl.com>; Tue, 14 Nov 2017 16:26:06 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A701270AC for <dispatch@ietf.org>; Tue, 14 Nov 2017 16:26:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4D7C87C3891 for <dispatch@ietf.org>; Wed, 15 Nov 2017 01:26:05 +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 ydNJoBhL0lgr for <dispatch@ietf.org>; Wed, 15 Nov 2017 01:26:03 +0100 (CET)
Received: from [31.133.145.32] (dhcp-9120.meeting.ietf.org [31.133.145.32]) by mork.alvestrand.no (Postfix) with ESMTPSA id D166F7C3862 for <dispatch@ietf.org>; Wed, 15 Nov 2017 01:26:02 +0100 (CET)
To: 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>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <e88d3d87-a9e6-d37c-c138-68124c8aa449@alvestrand.no>
Date: Wed, 15 Nov 2017 01:25:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <dad5e711-3a91-69d1-d3ed-ee38e9237699@it.aoyama.ac.jp>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/ERlk9jl55IihF2wYdodRKX79Bdk>
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: Wed, 15 Nov 2017 00:26:09 -0000

On 11/13/2017 10:25 AM, Martin J. Dürst wrote:
> On 2017/11/13 15:18, Murray S. Kucherawy wrote:
>> On Mon, Nov 13, 2017 at 2:01 PM, Sean Leonard <dev+ietf@seantek.com>
>> wrote:
>
>>> Working on this. It strikes me as either…odd…or just not really that
>>> useful for the purpose. It is a format, but it’s just a format for a
>>> stream
>>> of arbitrary bytes. There is no way to label it internally beyond the
>>> implicit “application/octet-stream” type.
>>>
>>
>> Don't you need a hint as to how to decode an octet stream that's
>> encoded in
>> some way?
>
> 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.

>
> Regards,    Martin.
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


-- 
Surveillance is pervasive. Go Dark.