Re: [ietf-types] Additional comments on image/svg+xml

[Julian Reschke <[e-mail]>]

(resending to the proper mailing list)

On 04.11.2010 17:33, Julian Reschke wrote:
> 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