Re: 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 ([email protected]).
>> >
>> > 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=FCrst, Professor, Aoyama Gakuin University
>> #-# http://www.sw.it.aoyama.ac.jp mailto:[email protected]
>
> _______________________________________________
> ietf-types mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-types
>