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

Re: SVG12: Transfer-Encoding

From: Chris Lilley <chris@w3.org>
Date: Sun, 21 Aug 2005 18:09:45 +0200
Message-ID: <6610070765.20050821180945@w3.org>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: www-svg@w3.org

On Sunday, April 24, 2005, 7:27:30 PM, Bjoern wrote:

BH> Dear Scalable Vector Graphics Working Group,

BH>   From http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/conform.html
BH> appendix D.4.3

BH> [...]
BH>   Also, if the SVG is compressed with gzip or deflate, Conforming
BH>   SVG Servers must indicate this with the "Content-Encoding: gzip"
BH>   or "Content-Encoding: deflate" headers, as appropriate.
BH> [...]

BH> The draft is unclear whether it is appropriate for a "SVG Server" to
BH> indicate this compression through the Transfer-Encoding header, please
BH> change the draft such that this is clarified.

Bjoern, looking at 3.6 Transfer Codings in the HTTP/1.1 specification
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6

We think you may be confusing Transfer-Coding with Content-Encoding,
described in section 14.11 Content-Encoding
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11
or possibly even the Content-Transfer-Encoding values of MIME.

Chunked transfer encoding is unrelated to Content-Encoding. As the
HTTP/1.1 specification makes clear, indicating compression in the way
you suggest would be completely incorrect.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
Received on Sunday, 21 August 2005 16:09:54 GMT

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