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

OK, is there anything left to do? Or is this already on the way to IANA?

Let's get this finished...

On 25.11.2010 21:01, Ned Freed wrote:
> Looks good to me as well.
>
> Ned
>
> > This looks good to me. I hope this can move forward to the next step
> > (IESG approval?) soon, so that image/svg+xml can finally be properly
> > registered.
> > Regards, Martin.
> > On 2010/11/25 7:36, Chris Lilley wrote:
> > >
> > > This is an updated registration request, incorporating the latest
> > > round of feedback.
> > >
> > >
> > > Type name:
> > >
> > > image
> > >
> > > Subtype name:
> > >
> > > svg+xml
> > >
> > > Required parameters:
> > >
> > > None.
> > >
> > > Optional parameters:
> > >
> > > charset
> > >
> > > Same as application/xml media type, as specified in [RFC3023] or
> > > its successors.
> > >
> > > Encoding considerations:
> > >
> > > Same as for application/xml. See [RFC3023], section 3.2 or its
> > > 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 the published specification, this content will be
> > > outside the 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:
> > >
> > > The published specification describes processing semantics that
> > > dictate 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/mimereg.html
> > >
> > > 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
> > >
> > > Note that the extension 'svgz' is used as an alias for
> > > 'svg.gz' [RFC1952], i.e. octet streams of type image/svg+xml,
> > > subsequently compressed with gzip.
> > >
> > > Macintosh file type code(s):
> > >
> > > "svg " (all lowercase, with a space character as the fourth letter).
> > >
> > > Note that the Macintosh file type code 'svgz' (all lowercase)
> > > is used as an alias for GZIP [RFC1952] compressed "svg ", i.e.
> > > octet streams of type image/svg+xml, subsequently compressed
> > > with gzip.
> > >
> > > 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 (member-svg-media-type(_at_)w3(_dot_)org).
> > >
> > > Intended usage:
> > >
> > > COMMON
> > >
> > > Restrictions on usage:
> > >
> > > None
> > >
> > > Author:
> > >
> > > The SVG specification is a work product of the World Wide Web
> > > Consortium's SVG Working Group.
> > >
> > > Change controller:
> > >
> > > The W3C has change control over this specification.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > --
> > #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> > #-# http://www.sw.it.aoyama.ac.jp 
> > mailto:duerst(_at_)it(_dot_)aoyama(_dot_)ac(_dot_)jp
> _______________________________________________
> ietf-types mailing list
> ietf-types(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf-types