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

Re: errata for RFC 2616 & 2617

From: Patrick McManus <mcmanus@appliedtheory.com>
Date: Tue, 27 Jul 1999 15:43:24 -0400 (EDT)
Message-Id: <199907271943.PAA21312@justice.atc-bos.com>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg@hplb.hpl.hp.com, iana@iana.org
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/493
In a previous episode Larry Masinter said...

:: Ob-erratum RFC 2616:
:: Section 3.5 calls for IANA to establish a registry of
:: "content-coding value tokens" that includes gzip, compress,
:: and deflate.
::  Section 3.6 calls for IANA to establish a registry of
:: "transfer-coding value tokens" that includes
:: "chunked" and "identity", but goes on to list
:: "gzip", "compress" and "deflate". But "gzip", "compress"
:: and "deflate" are not transfer-coding value tokens, they're
:: content-coding value tokens.

I don't get it.. but, I am having a bad day so it's most likely my
fault at interpretation.. but I thought the various compression
codings made sense for both content-coding and transfer-coding..

here's my understanding: they are different things: the former is a
property of the entity, and the latter is a property of the
message.. and the various proxies and clients in the chain are going
to handle them differently depending on whether they are content or
transfer based (i.e. application/postscript that is content-coded gzip
should probably be saved to disk as .ps.gz but if it is transfer-coded
gzip then the UA would like decompress and display, and if anything
gets saved it's the .ps only), but the algorithms and encodings
themselves make sense in both contexts.. whereas something like
chunked or jeff's delta musings make sense only as transfer encodings.

and I thought that's exactly what the document says... so where am I

Received on Tuesday, 27 July 1999 12:46:13 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:06 UTC