- From: Yves Lafon <ylafon@w3.org>
- Date: Tue, 11 Oct 2005 15:51:20 +0200 (MEST)
- To: Chris Lilley <chris@w3.org>
- cc: Boris Zbarsky <bzbarsky@mit.edu>, Bjoern Hoehrmann <derhoermi@gmx.net>, www-svg@w3.org
On Tue, 11 Oct 2005, Chris Lilley wrote:
> Do I have the wrong registry, or is HTTP/1.1 inconsistent wrt the IANA
> registry, using terms it claims are registered but in fact are not?
>
> Looking at http://www.iana.org/numbers.html I don't see any other
> applicable registry.
>
> The HTTP/1.1 references
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec17.html#sec17
> does not list a registry of Transfer-Encoding tokens either.
wrt Transfer-Encoding, they are defined in section 3.6 of RFC2616
<<<
The Internet Assigned Numbers Authority (IANA) acts as a registry for
transfer-coding value tokens. Initially, the registry contains the
following tokens: "chunked" (section 3.6.1), "identity" (section
3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
(section 3.5).
>>>
However I did not find any IANA registry containing all those tokens...
digging a bit (down to [1]), I think that the spec is correct as it talks
only about the data (entity in the HTTP world) TE/Transfer-Encoding deals
with the message level and is completely hidden from a data presentation
layer.
Also Transfer-Encoding is only hop-by-hop while Content-Encoding is end-to
end, meaning that a proxy can add or remove or keep (remove then add) a
Transfer-Encoding.
As a side note, the use Transfer-Encoding is very useful for proxies
between a high-speed link and a slow link, but only a few UA implements
it. A bit like Content-Location which is almost mandatory when you want to
do serious editing, and that almost only a few UA care about...
Thanks,
[1] http://lists.w3.org/Archives/Public/www-svg/2005Apr/0239.html
--
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Tuesday, 11 October 2005 13:52:03 UTC