Re: errata for RFC 2616 & 2617

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