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
