Re: SVG12: Transfer-Encoding

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

There is no Content-Transfer-Encoding in HTTP.

> b) transparent to the SVG implementation

The relevant part of the specification is talking about the server, not 
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.

My problem with the spec as written is that it's encouraging SVG servers 
to send Content-Encoding for what is actually a Transfer-Encoding, 
leading the client to wonder which it really was.  Doesn't matter for 
rendering purposes, but does matter for saving, for example -- if it's a 
really a Content-Encoding, then compressed SVG should be saved.  If the 
compression was just added to speed up HTTP transfer, then uncompressed 
SVG should be saved.  But if the server uses Content-Encoding for both 
cases, how is a client to tell?

-Boris