Re: Content Codings

On Sep 14, 15:45, Roy Fielding wrote:
>
> >  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.

Point taken. But who would write today a program based on LZ77 using a
different data format than gzip's, and expect it to be widely used on the
Internet ? De facto, algorithm <=> data format in this case.

> >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?

Backwards compatibility is of paramount importance to all application
developers, so this argument is probably only theoretical. If gzip were to
use a different data format one day, then people would refer to this new
version as gzip2 instead of gzip, i.e. define a new content coding. I don't
see a problem here.

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

OK, you're in charge !

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

We completely agree on this. There's been much speculation that IANA may
start registering content codings sooner rather than later, hence my comment.

> These issues will need to be answered in the standards-track HTTP/1.1
> specification, not in the HTTP/1.0 BCP.

OK

> 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!

I find this last comment a bit tough, because we face a catch 22 situation
here: using "gzip" and "compress" breaks the rules, because these types
aren't official MIME types. So you have to use "x-gzip" and "x-compress"
instead. But as soon as your experimental WWW tool starts to be used widely,
then you break the rules by using "x-whatever" for something which is no
longer experimental ! My understanding is that as long as IANA is not
officially in charge of maintaining the content coding namespace, all content
codings should be considered experimental, so "x-*" is the proper syntax.

To get back to the point, and taking into account your correction, I suggest
to replace the comment in section 3.5 with:

  Note: IANA is not maintaining the content coding namespace yet, so only
  experimental MIME types "x-whatever" may be used for content coding. It
  is believed at this point in time that IANA will be officially assigned
  the control of this namespace soon, and that 2 MIME types, "gzip" and
  "compress" will be registered. Therefore, for future compatibility,
  HTTP/1.0 applications should consider "gzip" and "compress" to be
  equivalent to "x-gzip" and "x-compress" respectively.

Jean-Philippe

Received on Friday, 15 September 1995 04:19:37 UTC