Re: [dispatch] Zstandard compression

Sean Leonard <> Mon, 13 November 2017 02:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49D10127136 for <>; Sun, 12 Nov 2017 18:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W6po4dzdUiTN for <>; Sun, 12 Nov 2017 18:22:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB01F127077 for <>; Sun, 12 Nov 2017 18:22:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 108612754E; Sun, 12 Nov 2017 21:22:51 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Leonard <>
In-Reply-To: <>
Date: Mon, 13 Nov 2017 10:22:48 +0800
Cc: DISPATCH list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Murray S. Kucherawy" <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [dispatch] Zstandard compression
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Nov 2017 02:22:55 -0000

Checked out the draft.

To simplify it, it looks like it is most analogous to the RFC 1950 / RFC 1951 documents that describe the algorithm(s) for ZLIB / DEFLATE, for compression of arbitrary data streams.

Those documents do not specify MIME types, and I do not think this document draft-kucherawy-dispatch-zstd should do so either. The media type registration is weak: there is no way to signal inside the format what is inside other than an arbitrary stream of bytes. It is not a file archive format, or another kind of container format that identifies parts.

3.2. Content Encoding is fine.

I request that we get an OID registration for this for use with Compressed Data Content Type for CMS, RFC 3274. That way it could be used with S/MIME or other formats that use CMS or S/MIME (seeing as how CMS / S/MIME are general container formats).

Surveying other container formats and doing the appropriate registrations with them in this draft would be appropriate, if one can articulate a use case in those respective formats.


> On Nov 2, 2017, at 5:35 AM, Murray S. Kucherawy <> wrote:
> <chair hat clearly off>
> In September, I submitted draft-kucherawy-dispatch-zstd, which introduces a new compression  mechanism and seeks to register media types and content encodings for it.  The most obvious application for it is HTTP payloads, but it has other possible applications.
> I don't know of IETF venues other than this one and maybe the ART list where this kind of thing might be discussed, or how we might dispatch it.  Offlist conversation with Mark Nottingham suggested maybe HTTPBIS might like to at least discuss this, but I haven't looked to see if it fits within their current charter.
> Suggestions for discussion venues or processing options are welcome.
> -MSK
> _______________________________________________
> dispatch mailing list