Additional comments on image/svg+xml

[Julian Reschke]

On 08.09.2010 09:29, "Martin J. Dürst" wrote:
> Exactly what Julian said below. There are generic XML applications that
> assume they can process all types that end in "+xml", and would be
> hopelessly confused when seeing some compressed stuff.
>
> Regards, Martin.
> ...

Hi,

picking up an old thread. We talked about this yesterday evening at the 
W3C TPAC reception, and I believe that we do not really disagree on what 
should or should not be done, but just on the right way to phrase it 
properly.

(Chris, please correct me if I'm getting wrong what you said).

The main use case for "svgz" is that you could configure the web server 
to serve the content *as stored on disk* as

   Content-Type: image/svg+xml
   Content-Encoding: gzip

I don't think anybody disagrees that this is a good way to serve SVG 
content (I'll stick to Content-Encoding as opposed to Transfer-Encoding; 
it really doesn't change the argument).

The important point here is that applications using HTTP *usually* will 
see the uncompressed XML, and treat it accordingly (this is certainly 
true for XmlHttpRequest, for example).

I'm not completely sure how using "svgz" instead of "svg.gz" as 
extension changes this; but let's assume there are servers where it helps.

Now does this make the gzipped version of SVG content valid content 
according to the media type? No. We also wouldn't claim that the fact 
that we transfer HTML with

   Content-Type: text/html
   Content-Encoding: gzip

makes gzipped HTML files actual HTML files, right? (If we did, we had to 
rewrite MANY media type registrations).

Looking at the current registration template 
(<http://dev.w3.org/SVG/profiles/1.1F2/publish/mimereg.html>, hopefully 
this is the right one...):

"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-Encoding or Transfer-Encoding 
header, as appropriate; 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."

Question: why is this under "Security Considerations"???

All of this is correct, but it suggests that instances of gzipped SVG 
*are* SVG. They are not.

The part about transport over HTTP and similar protocols can be dropped 
(at least from here), it's just a natural aspect of these protocols.

I would drop the rest, and then, under Additional Information/File 
extensions, currently reading:

"File extension(s):
     svg, svgz (if gzip-compressed)
Macintosh file type code(s):
     "svg " (all lowercase, with a space character as the fourth 
letter), "svgz" (all lowercase, if gzip-compressed)."

Drop the mentions of svgz, here, and just add add a Note, such as

"Note:
	We recommend using the file extension "svgz" for SVG content that is 
gzip-compressed."

Feedback appreciated,

Julian