SVG12: image/svg+xml gzip requirements

[Thomas DeWeese]

Hi Bjoern,

   Please don't rewrite the TAG finding.  The TAG indicates that
User agents should 'notify' the user of the problem.  It does not say
that these documents must be rejected.  From
http://www.w3.org/2001/tag/doc/mime-respect.html#handling-inconsistency

     For example, a small "bug" icon in a graphical browser's user
     interface can indicate that the user agent has overridden sender
     metadata and can also act as a button through which a curious user
     might inspect the error or reverse the agent's choice.

   I might also point out 4.2 where the last paragraph says:

     Representation providers SHOULD NOT in general specify the
     character encoding for XML data in protocol headers since the data
     is self-describing.

   Which would seem to support not including the character encoding
in the SVG mime type.

----

Bjoern Hoehrmann wrote:

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