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

Chris Lilley <chris@w3.org> Tue, 30 November 2010 17:15 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAUHF1U3054007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Nov 2010 10:15:01 -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 oAUHF1FA054006; Tue, 30 Nov 2010 10:15:01 -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 jay.w3.org (ssh.w3.org [128.30.52.60]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAUHExUc053998 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-xml-mime@imc.org>; Tue, 30 Nov 2010 10:15:00 -0700 (MST) (envelope-from chris@w3.org)
Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtpa (Exim 4.69) (envelope-from <chris@w3.org>) id 1PNTmn-00088X-Q5; Tue, 30 Nov 2010 12:14:38 -0500
Date: Tue, 30 Nov 2010 18:14:17 +0100
From: Chris Lilley <chris@w3.org>
X-Mailer: The Bat! (v3.95.6) Home
Reply-To: Chris Lilley <chris@w3.org>
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <477680602.20101130181417@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Ned Freed <ned.freed@mrochek.com>, "=?iso-8859-1?Q?=22Martin_J._D=FCrst=22?=" <duerst@it.aoyama.ac.jp>, <ietf-types@iana.org>, <ietf-xml-mime@imc.org>, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
In-Reply-To: <4CF4B395.80001@gmx.de>
References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> <1034064166.20101124233635@w3.org> <4CEDF469.7060101@it.aoyama.ac.jp> <01NUO88FRVH6007CHU@mauve.mrochek.com> <4CF4B395.80001@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id oAUHF0Ub054000
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>

On Tuesday, November 30, 2010, 9:19:33 AM, Julian wrote:

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

Re-reading Martin's latest comments, in a calmer frame of mind, there is merit to his proposed wording. I'm going to check it a little and then send in a (final? please?) last revision, likely tomorrow.

JR> Let's get this finished...

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

>> _______________________________________________
>> ietf-types mailing list
>> ietf-types@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-types





-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups