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

Julian Reschke <> Thu, 18 November 2010 16:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62D6528C0EE for <>; Thu, 18 Nov 2010 08:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.297
X-Spam-Status: No, score=-105.297 tagged_above=-999 required=5 tests=[AWL=-2.698, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j8lbb-QXHYtI for <>; Thu, 18 Nov 2010 08:47:07 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 0B6CF28C0E5 for <>; Thu, 18 Nov 2010 08:47:06 -0800 (PST)
Received: (qmail invoked by alias); 18 Nov 2010 16:47:53 -0000
Received: from (EHLO []) [] by (mp037) with SMTP; 18 Nov 2010 17:47:53 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+oeFFsrL6oRE5RTet3BrZMXiaYXWsW2m5M22+1n5 Aouwh0xF3yMWxh
Message-ID: <>
Date: Thu, 18 Nov 2010 17:47:45 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Chris Lilley <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Alexey Melnikov <>,,
Subject: Re: [ietf-types] Additional comments on image/svg+xml
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Media \(MIME\) type review" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Nov 2010 16:47:08 -0000

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 

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

Best regards, Julian