RE: SVG12: Transfer-Encoding

Hi, Bjoern-

Thanks for bringing this to our attention.

Bjoern Hoehrmann wrote:
| 
|   From http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/conform.html
| appendix D.4.3
| 
| [...]
|   Also, if the SVG is compressed with gzip or deflate, Conforming
|   SVG Servers must indicate this with the "Content-Encoding: gzip"
|   or "Content-Encoding: deflate" headers, as appropriate.
| [...]
| 
| The draft is unclear whether it is appropriate for a "SVG Server" to
| indicate this compression through the Transfer-Encoding header, please
| change the draft such that this is clarified.

We agree that this section could benefit from further clarification. 

We have revised this section as follows:

"Conforming SVG Servers

Conforming SVG Servers must meet all the requirements of a Conforming SVG
Generator. In addition, Conforming SVG Servers using HTTP or other protocols
that use Internet Media types must serve SVG stand-alone files with the
media type image/svg+xml.

Also, if the SVG file is compressed with gzip or deflate, Conforming SVG
Servers must indicate this with the appropriate header, according to what
the protocol supports. Specifically, for content compressed by the server
immediately prior to transfer, the server must use the "Transfer-Encoding:
gzip" or "Transfer-Encoding: deflate" headers as appropriate, and for
content stored in a compressed format on the server (i.e.with the file
extension "svgz"), the server must use the "Content-Encoding: gzip" or
"Content-Encoding: deflate" headers as appropriate.

Note: Compression of stored content (the "entity," in HTTP terms) is
distinct from automatic compression of the message,as defined in HTTP/1.1
TE/ Transfer Encoding."

Please let us know promptly if you do not feel that this wording addresses
your concern.

Thanks-
Doug, on behalf of the SVG WG

Received on Friday, 23 June 2006 19:24:39 UTC