- From: Patrick McManus <mcmanus@appliedtheory.com>
- Date: Tue, 27 Jul 1999 15:43:24 -0400 (EDT)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg@hplb.hpl.hp.com, iana@iana.org
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 confused? -Pat
Received on Tuesday, 27 July 1999 12:46:13 UTC