W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

RE: Clarification of the term "deflate"

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 07 Aug 2007 23:36:23 +0200
To: paul.marquess@ntlworld.com
Cc: ietf-http-wg@w3.org
Message-Id: <1186522583.19935.119.camel@henriknordstrom.net>
On tis, 2007-08-07 at 17:10 +0100, Paul Marquess wrote:

> One possibility is to remove the reference to RFC 1951 completely.
>   deflate
>     The "zlib" format defined in RFC 1950 [31]. 

1950 doesn't reference 1951.

> This variant keeps both RFC 1950 & 1951 but drops the troublesome labels.
>   deflate
>     The compressed data format defined in RFC 1950 [31] in combination with
>     the compression mechanism described in RFC 1951 [29].

RFCs define formats and protocols, not implementation. So it should
refer to the format defined by 1951, not the mechanism used for
producing that format.

And "zlib" isn't a compressed data format even if it's title says so.
It's just a wrapper around compressed data (only deflate defined, others
may be added in future).

     The "zlib" format defined in RFC 1950 [31] in combination
     with the compressed data format described in RFC 1951 [29].

On a side note it's worth noting that the "gzip" compressed format is
also just a different wrapper around deflate. And that the gzip
compressor is a different implementation producing RFC1951 deflate

> Indeed - the choice of name is the source of the ambiguity - there are two
> conflicting uses of "deflate" in the definition. If 2616 had used "zlib"
> instead of "deflate" the problem wouldn't have happened. 

Personally I don't really understand why the zlib wrapper is required
around the deflate stream, but that is a different question and too late
to do anything about.


Received on Tuesday, 7 August 2007 21:36:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC