Re: [ietf-types] Registration of media typeimage/svg+xml

Hello Chris, others,

On 2010/11/19 7:52, Chris Lilley wrote:
> This is an updated registration request, incorporating some feedback
> from Ned Freed<[email protected]>  and Julian Reschke<julian.reschk=
[email protected]>

I agree with Ned and Julian. This registration now looks good to me,=20
except for a little detail pointed out below.

As for why I was very uneasy with mentioning .svgz in the Mime Media=20
Type registration of image/svg+xml, please see the following excerpt=20
from a conversation between Larry Masinter and Henri Sivonen=20
(http://lists.w3.org/Archives/Public/www-tag/2010Nov/0053.html):

 >>>>
 > What were the problems with image/svg+xml, image/jp2 and/or video/mp4?

The problem with image/svg+xml is that after a decade of deployment and=20
W3C REC status, the type still isn't in the registry. Even if the IETF=20
experts found something wrong with the type, it would be way too late to=20
stop its deployment, so there's really no point in subjecting it to=20
expert review at this point.
 >>>>

 >>>>
 > As for image/svg+xml not being used for 'XML' format. I think this is=20
a 3023bis issue?

Do you mean sending gzipped data as image/svg+xml without=20
Content-Encoding: gzip?
 >>>>

I concluded (I hope erroneously) that there was gzipped SVG content out=20
there that was sent with a naked Content-Type: image/svg+xml, and that=20
some people in the industry thought that that was just okay. It is very=20
clear that it is not okay, and that the registry should not at all=20
suggest that it would be okay.


> Type name:
>
>      image
>
> Subtype name:
>
>      svg+xml
>
> Required parameters:
>
>      None.
>
> Optional parameters:
>
>      charset
>
>      Same as application/xml media type, as specified in [RFC3023] or
>      it's successors.
>
> Encoding considerations:
>
>      Same as for application/xml. See [RFC3023], section 3.2 or it's
>      successors.
>
> 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.
>
>      Several SVG elements may cause arbitrary URIs to be referenced. In
>      this case, the security issues of [RFC3986], section 7, should be
>      considered.
>
>      In common with HTML, SVG documents may reference external media
>      such as images, audio, video, style sheets, and scripting
>      languages. Scripting languages are executable content. In this
>      case, the security considerations in the Media Type registrations
>      for those formats shall apply.
>
>      In addition, because of the extensibility features for SVG and of
>      XML in general, it is possible that "image/svg+xml" may describe
>      content that has security implications beyond those described
>      here. However, if the processor follows only the normative
>      semantics of this specification, this content will be outside the

"this specification" doesn't work when the registration template is=20
taken out of the SVG spec. Either say "the SVG specification" or=20
explicitly reference a specific version of the specification.


>      SVG namespace and shall be ignored. Only in the case where the
>      processor recognizes and processes the additional content, or
>      where further processing of that content is dispatched to other
>      processors, would security issues potentially arise. And in that
>      case, they would fall outside the domain of this registration
>      document.
>
> Interoperability considerations:
>
>      This specification describes processing semantics that dictate

Same problem here.

>      behavior that must be followed when dealing with, among other
>      things, unrecognized elements and attributes, both in the SVG
>      namespace and in other namespaces.
>
>      Because SVG is extensible, conformant "image/svg+xml" processors
>      must expect that content received is well-formed XML, but it
>      cannot be guaranteed that the content is valid to a particular DTD
>      or Schema or that the processor will recognize all of the elements
>      and attributes in the document.
>
>      SVG has a published Test Suite and associated implementation
>      report showing which implementations passed which tests at the
>      time of the report. This information is periodically updated as
>      new tests are added or as implementations improve.
>
> Published specification:
>
>      This media type registration is extracted from Appendix P of the
>      SVG 1.1 specification. http://www.w3.org/TR/SVG/
>
> Applications that use this media type:
>
>      SVG is used by Web browsers, often in conjunction with HTML; by
>      mobile phones and digital cameras, as a format for interchange of
>      graphical assets in desk top publishing, for industrial process
>      visualization, display signage, and many other applications which
>      require scalable static or interactive graphical capability.
>
> Additional information:
>
>      Magic number(s):
>      File extension(s):
>          svg, svgz (if gzip-compressed)
>      Macintosh file type code(s):
>          "svg " (all lowercase, with a space character as the fourth
>          letter), "svgz" (all lowercase, if gzip-compressed).
>      Macintosh Universal Type Identifier code:
>          org.w3c.svg conforms to public.image and to public.xml
>      Windows Clipboard Name:
>          "SVG Image"
>      Fragment Identifiers
>          For documents labeled as application/svg+xml, the fragment
>          identifier notation is that for application/xml, as specified
>          in RFC 3023 or its successors, plus the SVG-specific SVG Views
>          syntax described in the SVG specification.
>
> Person&  email address to contact for further information:
>
>      Chris Lilley, Doug Schepers ([email protected]).
>
> Intended usage:
>
>      COMMON
>
> Restrictions on usage:
>
>      None
>
> Author:
>
>      The SVG specification is a work product of the World Wide Web Cons=
ortium's SVG Working Group.
>
> Change controller:
>
>      The W3C has change control over this specification.

And same problem here again. Actually, in this case, I'm under the=20
impression that "Change controller" refers to the change controller of=20
the registration, not the specification (which would be the same, but=20
would be written differently). But I might be wrong.

Regards,    Martin.

--=20
#-# Martin J. D=FCrst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email protected]