RE: Clarification of the term "deflate"

From: Henrik Nordstrom [mailto:henrik@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.

Indeed - it references this instead

   [3] Deutsch, L.P.,"DEFLATE Compressed Data Format Specification",
       available in ftp://ftp.uu.net/pub/archiving/zip/doc/  

The ftp link takes you to a list of files, one of which is 1951, but that
isn't a precise enough reference.

> > 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].

That's better.

So how about adding a note that tells the reader the reality of the
implementations that are out in the wild? Something like this perhaps?

Note: Experience has shown that some implementations of "deflate" encoding
have incorrectly used RFC 1951 without the RFC 1950 wrapper. In order to
maximise interoperability an implementation should consider accepting
"deflate" encoding that uses either RFC 1950 in combination with RFC 1951 or
"deflate" encoding that uses RFC 1951 on its own.

> 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
> streams.
> 
> > 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.

Using the zlib wrapper means an implementation can quickly determine whether
the content is what it claims to be by checking the zlib signature. With
1951, you have to try to uncompress it before you can tell.

Paul

Received on Wednesday, 8 August 2007 09:43:53 UTC