RE: SVG12: gzip 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 
| 
| [...]
|   SVG implementations must correctly support gzip-encoded and
|   deflate-encoded SVG data streams. SVG implementation that
|   support HTTP must support these encodings according to the
|   HTTP 1.1 specification [RFC2616]; in particular, the client
|   must specify with an "Accept-Encoding:" request header 
|   [HTTP-ACCEPT-ENCODING] those encodings that it accepts,
|   including at minumum gzip and deflate, and then decompress
|   any gzip-encoded and deflate-encoded data streams that are
|   downloaded from the server.
| [...]
| 
| Please change the draft such that it is clear whether implementations
| are required to support the gzip Transfer-Encoding and if whether they
| are required to send the corresponding TE header aswell.

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 18:53:32 UTC