Re: Registration of media typeimage/svg+xml

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


Best regards, Julian