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

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Nov 2010 17:18:40 +0100

(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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Nov 2010 17:18:40 +0100

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Nov 2010 09:59:59 +0100

Hi,

we do not seem to make any progress.

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

At least that would populate the registry with useful information.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Nov 2010 10:05:35 +0100

> that gzipped SVG is *not* conforming image/xvg+xml content?

s/xvg/svg/ (sorry)

---

From: Chris Lilley <[email-masked]>
Date: Thu, 18 Nov 2010 17:30:02 +0100

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.

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

>> Julian

JR> _______________________________________________
JR> ietf-types mailing list
JR> [email-masked]
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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Nov 2010 17:47:45 +0100

> 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, o…

I wasn't aware of any progress being made :-).

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

Do existing tools treat gzipped SVG properly *when used with _that_ 
media type*?

(In the meantime I heard about the workaround Safari is using for that, 
but that confirms to me that the described behavior just is wrong.)

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

But in that case, the gzipped version really is *not* an instance of 
image/svg+xml.

Why can't you just simply state the recommendation for "svgz" *outside* 
the description of the media type?

Best regards, Julian

---

From: Ron Wilson <[email-masked]>
Date: Thu, 18 Nov 2010 16:20:23 -0500

On Thu, Nov 18, 2010 at 11:47 AM, Julian Reschke <[email-masked]> wrote:
>> 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'.
>
> Why can't you just simply state the recommendation for "svgz" *outside* the
> description of the media type?

This is certainly consistant with my understanding of the use of
"Transfer-encoding:". "svg" would be the official extension for
"image/svg+xml" and the only one that applications should have to deal
with. Any other extension used would be an implementation detail of
the service providing/hosting the SVG resource.

As a related side point, if there really is a need for a type to cover
gzip'ed SVG, I think that "application/vnd.svg" would be more
appropriated.