W3C home > Mailing lists > Public > www-svg@w3.org > December 2004

Re: SVG12: image/svg+xml gzip requirements

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 09 Dec 2004 22:15:01 -0600
Message-ID: <41B922C5.4090704@mit.edu>
To: Chris Lilley <chris@w3.org>
CC: www-svg@w3.org, ietf-types@iana.org

Chris Lilley wrote:
> IH> I would strongly recommend that specs disallow sniffing of any kind,
> IH> treating all metadata as authorative
> They do, although the xml encoding declaration is metadata too.

I'm sorry, but that's not what was being claimed about user-agents receiving 
content with a Cotent-Type of image/xml+svg, and Content-Encoding or 
Transfer-Encoding that happened to look like it was compressed (the argument was 
about gzip, but I'm not sure it was ever claimed that gzip compression is 
special in this regard, except insofar as support for it is required by the SVG 

The claim was that under these circumstances, the UA should disregard the 
server-provided encoding value ("identity", in the only way that it can be 
provided), should decompress the data based on its guess as to what type of 
compression was used, and should tell the user that it did so.

The futher claim was that this is consistent with all existing specifications 
and best practices and was a desirable behavior.

These claims hinged on the claim that the magic numbers at the beginning of 
common compressed formats are actually metadata.  Per this argument, of course, 
it's not clear why we have Content-Encoding and Transfer-Encoding headers at 
all, but such was the argument.

Note that none of this has to do with XML encoding declarations or "charset" 
parameter of the Content-Type header, and it's unfortunate that the two issues 
ended up getting intermixed this way...

Received on Friday, 10 December 2004 04:15:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:04 UTC