W3C home > Mailing lists > Public > www-svg@w3.org > October 2005

Re: SVG12: Transfer-Encoding

From: Chris Lilley <chris@w3.org>
Date: Tue, 11 Oct 2005 16:41:02 +0200
Message-ID: <17710311225.20051011164102@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:31 GMT