re: Registration of media type image/svg+xml

[Chris Lilley <[e-mail]>]

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:[e-mail]
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG