Dear Scalable Vector Graphics Working Group, The current http://www.w3.org/TR/SVG12/mimereg.html notes: [...] SVG documents may be transmitted in compressed form using gzip compression. For systems which employ MIME-like mechanisms, such as HTTP, this is indicated by the Content-Transfer-Encoding header; for systems which do not, such as direct filesystem access, this is indicated by the filename extension and by the Macintosh File Type Codes. In addition, gzip compressed content is readily recognised by the initial byte sequence as described in RFC1952 section 2.3.1. [...] Unless the document is meant to introduce a new HTTP header, this is clearly false, RFC 2616 explicitly notes that Content-Transfer-Encoding is not used in HTTP/1.1, please change the text to refer to an actual HTTP header. I am puzzled by the last sentence here, the text seems to suggest that implementations of the image/svg+xml MIME type are required to sniff for gzip compressed content so that much of the ill-formed SVG content http://lists.w3.org/Archives/Public/www-svg/2004Dec/0031.html where content is compressed but the compression is not indicated through the relevant HTTP headers would actually be conforming. This is not accetable as it is inconsistent with the Authoritative Metadata TAG finding http://www.w3.org/2001/tag/doc/mime-respect.html and RFC 3023 and 2616 which do not include such a requirement which means that such content would not work in general purpose XML processors which means that use of the +xml convention for image/svg+xml would not be appropriate. Please change the text to clearly indicate that this is not allowed and that SVG Viewers are required to treat such content as ill-formed XML and thus reject it entirely. regards. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/