Re: Registration of media typeimage/svg+xml
"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Thu, 25 November 2010 05:30 UTC
Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAP5UWTC003870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 22:30:32 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id oAP5UWCk003869; Wed, 24 Nov 2010 22:30:32 -0700 (MST) (envelope-from owner-ietf-xml-mime@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAP5UT02003862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-xml-mime@imc.org>; Wed, 24 Nov 2010 22:30:31 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id oAP5USdJ025607 for <ietf-xml-mime@imc.org>; Thu, 25 Nov 2010 14:30:28 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0863_3768_1caaced6_f855_11df_88e3_001d096c566a; Thu, 25 Nov 2010 14:30:28 +0900
Received: from [IPv6:::1] ([133.2.210.1]:57846) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S148FB1E> for <ietf-xml-mime@imc.org> from <duerst@it.aoyama.ac.jp>; Thu, 25 Nov 2010 14:30:27 +0900
Message-ID: <4CEDF469.7060101@it.aoyama.ac.jp>
Date: Thu, 25 Nov 2010 14:30:17 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Chris Lilley <chris@w3.org>
CC: ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov <alexey.melnikov@isode.com>, Philippe Le Hegaret <plh@w3.org>
Subject: Re: Registration of media typeimage/svg+xml
References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> <1034064166.20101124233635@w3.org>
In-Reply-To: <1034064166.20101124233635@w3.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-xml-mime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Unsubscribe: <mailto:ietf-xml-mime-request@imc.org?body=unsubscribe>
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@w3.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@it.aoyama.ac.jp
- Registration of media typeimage/svg+xml Chris Lilley
- Re: Registration of media typeimage/svg+xml Chris Lilley
- Re: Registration of media typeimage/svg+xml Henry S. Thompson
- Re: Registration of media typeimage/svg+xml Paul Libbrecht
- Re: Registration of media typeimage/svg+xml Chris Lilley
- Re: Registration of media typeimage/svg+xml Paul Libbrecht
- Re: Registration of media typeimage/svg+xml Chris Lilley
- Re: Registration of media typeimage/svg+xml Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… Alexey Melnikov
- Re: [ietf-types] Registration of media typeimage/… Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… Julian Reschke
- Re: [ietf-types] Registration of media typeimage/… Julian Reschke
- Re: [ietf-types] Registration of media typeimage/… ned+xml-mime
- Re: Registration of media typeimage/svg+xml ned+xml-mime
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- Re: [ietf-types] Registration of media typeimage/… Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- Re: [ietf-types] Registration of media typeimage/… Keith Moore
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- Re: Registration of media typeimage/svg+xml Martin J. Dürst
- Re: Registration of media typeimage/svg+xml Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- Re: [ietf-types] Registration of media typeimage/… Julian Reschke
- Re: [ietf-types] Registration of media typeimage/… Alexey Melnikov
- Re: Registration of media typeimage/svg+xml Julian Reschke
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- Re: Registration of media typeimage/svg+xml Chris Lilley
- Re: Registration of media typeimage/svg+xml Chris Lilley
- Re: Registration of media typeimage/svg+xml ned+xml-mime
- Re: Registration of media typeimage/svg+xml Julian Reschke
- Re: Registration of media typeimage/svg+xml Chris Lilley
- Re: Registration of media typeimage/svg+xml Julian Reschke
- Re: Registration of media typeimage/svg+xml Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- Re: [ietf-types] Registration of media typeimage/… ned+xml-mime
- Re: [ietf-types] Registration of media typeimage/… Chris Lilley
- Registration of media typeimage/svg+xml Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… ned+xml-mime