Hello Mark, I have just sent a registration request for image/svg+xml to ietf-types http://www.alvestrand.no/pipermail/ietf-types/2010-June/002360.html Looking back in the archives I see an old message from you (2005!) which I don't recall answering. http://www.alvestrand.no/pipermail/ietf-types/2005-December/000903.html Some of the points no longer apply to the new registration, some are addressed. I wanted to close the loop with you on that anyway, so that if any of the items you mentioned in 2005 are not addressed to your satisfaction in the new registration, we can get them fixed.
On 12/7/05, Chris Lilley <chris at w3.org> wrote:
Optional parameters: None
The encoding of an SVG document shall be determined by the XML encoding declaration. This has identical semantics to the application/xml media type in the case where the charset parameter is omitted, as specified in RFC3023 sections 8.9, 8.10 and 8.11.
Can I assume this section above was supposed to be a replacement for the encoding section below?
For the new registration, that text no longer appears. To answer your question though: no, its one of those unfortunate terminology issues where different terms are used by different communities. What XML calls the 'encoding' or 'character encoding' is what IETF calls the 'charset'. So the section was in the right place and was explaining the lack of a charset parameter. However, the new registration has the optional charset parameter so no longer needs the explanatory prose.
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-Transfer-Encoding header; 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.
I don't see how that's a security issue. Seems more an encoding one to me.
I agree it could be described either way, but there have been concerns in the past about triggering compression libraries and potential security concerns due to fixed-length zlib buffers so on balance, we decided to leave that text in there. A secondary reason to mention it was that a few implementations accept uncompressed svg, but fail with compressed svg, or only allow compressed svg when served over http and not from local disk. So it seemed worth mentioning the various ways that compressed svg might be labelled or detected. If you strongly disagree though, and no-one else speaks up in favour of this being worth mentioning in the security section, we are happy to take it out or move it to the encoding section. Should the initial byte sequence of gzipped svg be mentioned under magic numbers? It only shows that the content is gzipped, not that it is svg, so we did not add it there.
On the topic of compression though, I had heard a while ago (back in the "image/svg-xml" days) that compressed SVG is sometimes sent as image/svg+xml. Is that still (assuming it was ever) the case?
Yes, it is the case. The same media type is used for svg regardless of whether it is compressed or not. For HTTP, other labelling is used to indicate the compression.
The spec seems to make it clear that SVG is compressed via HTTP compression.
Yes.
Published specification: This media type registration is extracted from Appendix M of the SVG 1.2 Tiny specification. http://www.w3.org/TR/SVGMobile12
There was no "Applications which used this media type" section. I think it would be useful to say that there are numerous implementations which currently support this media type.
This has been added to the current registration; please check that the language is satisfactory.
Also, you might want to mention - probably in "interoperability" - that this same media type was also prescribed for use in the SVG 1.0 and 1.1 specs. And if there are any backward compatibility issues between 1.2 and those, you might want to say something about that.
The current registration is in the context of SVG 1.1, while the old one was for SVG Tiny 1.2 SVG 1.1 obsoletes SVG 1.0 (but SVG 1.0 did use the same media type) The same media type is used for SVG Tiny 1.1, SVG Basic 1.1, and SVG Tiny 1.2. We would be happy to note this in the registration, although the defining specification covers the relationship in much more detail. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG