Registration of media type image/svg+xml

Mark Baker distobj at
Thu Dec 8 16:39:05 CET 2005

Hey Chris,

On 12/7/05, Chris Lilley <chris at> 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?

>    Encoding considerations:
>           Same as for application/xml. See RFC3023, section 3.2.

>    Security considerations:
>           As with other XML types and as noted in RFC3023 section
>           10, repeated expansion of maliciously constructed XML
>           entities can be used to consume large amounts of memory,
>           which may cause XML processors in constrained environments to
>           fail.
>           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.

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?  The
spec seems to make it clear that SVG is compressed via HTTP

>    Published specification:
>           This media type registration is extracted from Appendix M of
>           the SVG 1.2 Tiny specification.

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.

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.


Mark Baker.  Ottawa, Ontario, CANADA.
Coactus; Web-inspired integration strategies

More information about the Ietf-types mailing list