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

[Julian Reschke <[e-mail]>]

On 18.11.2010 17:30, Chris Lilley wrote:
> 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.

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

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

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

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

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