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