- From: Chris Lilley <chris@w3.org>
- Date: Tue, 11 Oct 2005 16:41:02 +0200
- To: Yves Lafon <ylafon@w3.org>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, Bjoern Hoehrmann <derhoermi@gmx.net>, <www-svg@w3.org>
On Tuesday, October 11, 2005, 3:51:20 PM, Yves wrote: YL> 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. YL> wrt Transfer-Encoding, they are defined in section 3.6 of RFC2616 YL> <<< YL> The Internet Assigned Numbers Authority (IANA) acts as a registry for YL> transfer-coding value tokens. Initially, the registry contains the YL> following tokens: "chunked" (section 3.6.1), "identity" (section YL> 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" YL> (section 3.5). >>>> YL> However I did not find any IANA registry containing all those tokens... It seems to be in http://www.iana.org/assignments/http-parameters YL> digging a bit (down to [1]), I think that the spec is correct as it talks YL> only about the data (entity in the HTTP world) TE/Transfer-Encoding deals YL> with the message level and is completely hidden from a data presentation YL> layer. Yes, I agree with that. So,whether the HTTP layer understands or does not understand gzip as a Transfer-Encoding is a) orthogonal to the use of Content-Transfer-Encoding b) transparent to the SVG implementation It also looks as if nothing needs to be said regarding conformance - if the client sends a TE header and the server uses the values from the TE header, it all works and if not,the TE header will not be sent. Either way, by the time the SVG implementation sees the content,any encoding of the message has been undone. YL> Also Transfer-Encoding is only hop-by-hop while Content-Encoding is end-to YL> end, meaning that a proxy can add or remove or keep (remove then add) a YL> Transfer-Encoding. Good point. YL> As a side note, the use Transfer-Encoding is very useful for proxies YL> between a high-speed link and a slow link, but only a few UA implements YL> it. A bit like Content-Location which is almost mandatory when you want to YL> do serious editing, and that almost only a few UA care about... YL> Thanks, YL> [1] http://lists.w3.org/Archives/Public/www-svg/2005Apr/0239.html -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Tuesday, 11 October 2005 14:41:16 UTC