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

Chris Lilley <> Thu, 18 November 2010 16:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC18E28C0E5 for <>; Thu, 18 Nov 2010 08:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.599
X-Spam-Status: No, score=-12.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jPIcvBsr9w24 for <>; Thu, 18 Nov 2010 08:30:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CB53928C0CF for <>; Thu, 18 Nov 2010 08:30:52 -0800 (PST)
Received: from localhost ([]) by with esmtpa (Exim 4.69) (envelope-from <>) id 1PJ7OZ-0003K3-ND; Thu, 18 Nov 2010 11:31:35 -0500
Date: Thu, 18 Nov 2010 17:30:02 +0100
From: Chris Lilley <>
X-Mailer: The Bat! (v3.95.6) Home
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <>
To: Julian Reschke <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Alexey Melnikov <>,,
Subject: Re: [ietf-types] Additional comments on image/svg+xml
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Chris Lilley <>
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:30:54 -0000

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

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