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

["Martin J. Dürst" <[e-mail]>]

Sorry to pull back yet another time. I just found a comment by Björn 
Höhrmann in another thread saying that RFC 3032 doesn't define fragment 
identifiers. Upon checking, I found the following:

http://tools.ietf.org/html/rfc3023#section-5
 >>>>
5. Fragment Identifiers

    Section 4.1 of [RFC2396] notes that the semantics of a fragment
    identifier (the part of a URI after a "#") is a property of the data
    resulting from a retrieval action, and that the format and
    interpretation of fragment identifiers is dependent on the media type
    of the retrieval result.

    As of today, no established specifications define identifiers for XML
    media types.  However, a working draft published by W3C, namely "XML
    Pointer Language (XPointer)", attempts to define fragment identifiers
    for text/xml and application/xml.  The current specification for
    XPointer is available at http://www.w3.org/TR/xptr.
 >>>>

On top of that, http://www.w3.org/TR/xptr/ says it's superseeded. In 
this light, the following text from the registration may need 
reconsideration:

 >> 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.

What about:

 >>>>
Fragment Identifiers

For documents labeled as application/svg+xml, the fragment
identifier notation follows the XML Pointer Language (XPointer) 
Framework (see http://www.w3.org/TR/xptr-framework/). Fragment 
identifiers are either Shorthand Pointers (formerly called barenames) or 
SVG view specifications. For details, please see Section 17.3.2 of the 
SVG specification 
(http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers).
 >>>>

or some such. I hope that RFC 3023bis can be completed soon, and make 
this easier, but I hope we don't need to wait for this to complete the 
image/svg+xml registration.

This also brings me to another nit. The registration currently says:

 >> 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

First, we made some tweaks, and second, the published specification is 
all of SVG 1.1, not just the mimereg part, as far as I understand. So 
what about something like:

 >>>>
Published specification:

This media type registration is an extracted and slightly adapted 
version of Appendix P of the SVG 1.1 specification
(http://www.w3.org/TR/SVG11/).
 >>>>

I'm not against replacing SVG 1.1 with something like "the latest and 
greatest SVG specification" (and a link to http://www.w3.org/TR/SVG/), 
but I think we should be consistent.

Regards,    Martin.



On 2010/11/25 14:30, "Martin J. Dürst" wrote:
> 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 ([e-mail]).
>>
>> 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:[e-mail]