Re: Registration of media typeimage/svg+xml

Julian Reschke <> Thu, 18 November 2010 19:19 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id oAIJJZY9083419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 12:19:35 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id oAIJJZ2g083418; Thu, 18 Nov 2010 12:19:35 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.4/8.14.3) with SMTP id oAIJJWRA083411 for <>; Thu, 18 Nov 2010 12:19:33 -0700 (MST) (envelope-from
Received: (qmail invoked by alias); 18 Nov 2010 19:19:30 -0000
Received: from (EHLO []) [] by (mp003) with SMTP; 18 Nov 2010 20:19:30 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+//OFpiXq/OPDqmKc8sJ+FLwmY5IRZVg90JjHZG6 opXEx5Z8TGk5sQ
Message-ID: <>
Date: Thu, 18 Nov 2010 20:19:20 +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 <>
CC:,, Alexey Melnikov <>
Subject: Re: Registration of media typeimage/svg+xml
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

On 18.11.2010 19:02, Chris Lilley wrote:
> ...
> Security considerations:
> ...
>      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.
> ...

1) What does this have to do with "Security Considerations"?

2) I find the whole paragraph misleading; I'd like to see a clear 
statement about whether the stream of octets resulting from gzipping SVG 
can be labeled as "image/svg+xml" or not (please consider transports 
other than HTTP, such as a file system that actually supports typing by 
Internet media types).

If yes, that's a violation of "+xml" (and the last sentence points into 
this direction). If not, please remove the paragraph above.

3) If the intent is to say that "svgz" acts as file extension for 
gzipped SVG, and *that* content can be served over HTTP as-is with

	Content-Type: image/svg+xml
	Content-Encoding: gzip

than this is obviously ok because it follows from RFC 2616, and has 
*nothing* to do with the media type (except for the extension 

Best regards, Julian