W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Content Codings

From: Roy Fielding <fielding@beach.w3.org>
Date: Thu, 14 Sep 1995 15:45:31 -0400
Message-Id: <199509141945.PAA07847@beach.w3.org>
To: JP.Martin-Flatin@ecmwf.int
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Based on HTTP/1.0 Internet Draft 03, I have 2 comments about Content Codings:
>
>1) In Section 3.5, it states:
>
>  Note: Use of program names for the identification of encoding formats
>  is not desirable and should be discouraged for future encodings. Their
>  use here is representative of historical practice, not good design.
>
>My reading of this is that rather than the name of a compression program, one
>should probably use the name of the underlying algorithm, e.g. LZW instead of
>x-compress and LZ77 instead of x-gzip.

Not algorithm -- data format.  The data format used by gzip is not just
the LZW algorithm applied to the source; it also includes filename info
and a CRC.  As far as I know, there is no exact description of the format
other than the source code for decoding it.

>The rationale is that 2 different
>programs based on the same algorithm may uncompress the file, so the
>reference to the name of a specific implementation of the algorithm is not a
>good idea.

Yes.

>In practice, you may compile a program like Jean-Loup Gailly's gzip on
>virtually all platforms, so most people use a single implementation of LZ77.

And what version of gzip?  Do you also guarantee gzip will never use a
different file format?

>Many will know what x-gzip refers to, but few will for LZ77. So it seems
>likely that most people will keep on using x-gzip even if x-lz77 is defined
>by IANA in the future.
>
>I therefore propose that the abovementioned comment be removed from the HTTP
>spec.

I do not agree.  In addition, since the Note is not a normative part
of the specification, I consider it part of my editorial domain.  In
any case, the note was added in response to an opposite comment to yours.

>2) In Section 3.5, it states:
>
>  Note: For future compatibility, HTTP/1.0 applications should consider
>  "gzip" and "compress" to be equivalent to "x-gzip" and "x-compress",
>  respectively.
>
>I guess the rationale is that IANA plans to register "gzip" and "compress" as
>new MIME types in the near future (anyone up-to-date with IANA's plans ?). If
>that's indeed the case, then I suggest to say it explicitly in this comment.

I think you misunderstand the role of IANA in this process.  IANA is
a registration authority, not a decision-making body, and has not yet
been assigned the task of maintaining the content coding namespace.
These issues will need to be answered in the standards-track HTTP/1.1
specification, not in the HTTP/1.0 BCP.

In any case, Internet standards *never* register x-prefix names,
and that is why the current "x-whatever" should be treated as "whatever".

And a plague shall befall any programmer that ships code using
an "x-" prefix!  Experimental tags must only be used for experiments!

 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)
Received on Thursday, 14 September 1995 12:47:32 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:32 EDT