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

Julian Reschke <> Thu, 18 November 2010 08:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3721C3A6804 for <>; Thu, 18 Nov 2010 00:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.166
X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=-1.867, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y7jX0g+1Mx-Q for <>; Thu, 18 Nov 2010 00:59:23 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id C67863A67D3 for <>; Thu, 18 Nov 2010 00:59:22 -0800 (PST)
Received: (qmail invoked by alias); 18 Nov 2010 09:00:07 -0000
Received: from (EHLO []) [] by (mp020) with SMTP; 18 Nov 2010 10:00:07 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1++6zZ+IkO+azH+Mh7qXCSt1VZZnk+FGAymXC8xbR 2fQLcnKrBNRW/0
Message-ID: <>
Date: Thu, 18 Nov 2010 09:59:59 +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: "\"Martin J. Dürst\"" <>
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 08:59:24 -0000


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

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