Re: SVG12: Transfer-Encoding

On Tuesday, October 11, 2005, 7:30:55 PM, Boris wrote:

BZ> Chris Lilley wrote:
>> 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

BZ> There is no Content-Transfer-Encoding in HTTP.

I always do that. Content-Encoding.

>> b) transparent to the SVG implementation

BZ> The relevant part of the specification is talking about the server, not 
BZ> the SVG implementation.  It's not transparent to the server.

>> 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.

BZ> My problem with the spec as written is that it's encouraging SVG servers
BZ> to send Content-Encoding for what is actually a Transfer-Encoding, 
BZ> leading the client to wonder which it really was.

Right; I agree that this is not the intent. Here is what the spec
currently says for Conforming SVG Servers:

<p>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 <tt>image/svg+xml</tt>.</p>

<p>Also, if the SVG content is compressed with gzip or deflate (i.e.an
svgz file), Conforming SVG Servers must indicate this with the
"Content-Encoding:&#xA0;gzip" or "Content-Encoding:&#xA0;deflate"
headers, as appropriate,if the protocol supports them.</p>

<p><em>Note:</em> This compression of <em>content</em> (the entity,in
HTTP terms) is distinct from automatic compression of the
<em>message</em>,as defined in HTTP/1.1 <a
href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39">TE</a>/<a
href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.41">Transfer
Encoding</a>.</p>

So, it distinguishes between compression of the content and compression
of the message, as you and Yves explained, and it defers to HTTP/1.1 for
whether Transfer-Encoding uses gzip or not.


BZ>   Doesn't matter for 
BZ> rendering purposes, but does matter for saving, for example -- if it's a
BZ> really a Content-Encoding, then compressed SVG should be saved.  If the 
BZ> compression was just added to speed up HTTP transfer, then uncompressed 
BZ> SVG should be saved.  But if the server uses Content-Encoding for both 
BZ> cases, how is a client to tell?

Its not intended to be using it for both cases. Yves seemed to think it
was already clearly about only content compression, not message
compression. I believe this latest change makes that abundantly clear.
Do you agree?


-- 
 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 17:58:53 UTC