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

[Chris Lilley]

On Thursday, November 18, 2010, 9:59:59 AM, Julian wrote:

JR> Hi,

JR> we do not seem to make any progress.

Every time we seem to make progress, (most recently at TPAC when i discussed this with Alexey) someone comes a day later suggesting a change which is incompatible with deployed tools and content, or ill-advised, or both.

JR> How about publishing a small IETF document registering the type, 
JR> delegating for most of the content to the W3C SVG spec, but pointing out
JR> that gzipped SVG is *not* conforming image/xvg+xml content?

JR> At least that would populate the registry with useful information.

I was about to populate it, when you suggested a breaking change, Julian

Existing tools generate and handle gzipped svg just fine, as they have since, erm, 1998 or so. And they are happy to consider that it has both a content-type and also an encoding.


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

You seem to be assuming that, in a MIME environment, they would see the compressed stuff. The point of labelling it is that it can be recognised, decompressed, and handed off to the 'generic application'.

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


JR> _______________________________________________
JR> ietf-types mailing list
JR> ietf-types at ietf.org
JR> https://www.ietf.org/mailman/listinfo/ietf-types




-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups