Re: [ietf-types] Registration of media typeimage/svg+xml
Chris Lilley <chris@w3.org> Tue, 30 November 2010 17:14 UTC
Return-Path: <chris@w3.org>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF2528C0F6 for <ietf-types@core3.amsl.com>; Tue, 30 Nov 2010 09:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.005
X-Spam-Level:
X-Spam-Status: No, score=-5.005 tagged_above=-999 required=5 tests=[AWL=-1.606, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, J_CHICKENPOX_65=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzAKHOwV-gL2 for <ietf-types@core3.amsl.com>; Tue, 30 Nov 2010 09:14:11 -0800 (PST)
Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.73]) by core3.amsl.com (Postfix) with ESMTP id 7CF2F3A6BCC for <ietf-types@ietf.org>; Tue, 30 Nov 2010 09:14:09 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id oAUHEkM8022252 for <ietf-types@iana.org>; Tue, 30 Nov 2010 12:15:06 -0500
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
Organization: W3C
X-Priority: 3 (Normal)
Message-ID: <477680602.20101130181417@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>
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: quoted-printable
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.73]); Tue, 30 Nov 2010 12:15:06 -0500 (EST)
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, ietf-types@iana.org, ietf-xml-mime@imc.org
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Chris Lilley <chris@w3.org>
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2010 17:14:12 -0000
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
- Re: [ietf-types] Registration of media typeimage/… Chris Lilley
- 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 Freed
- Re: [ietf-types] Registration of media typeimage/… Chris Lilley
- 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/… Yves Lafon
- Re: [ietf-types] Registration of media typeimage/… Julian Reschke
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- 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/… Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… Larry Masinter
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- 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/… Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst
- Re: [ietf-types] Registration of media typeimage/… Ned Freed
- Re: [ietf-types] Registration of media typeimage/… Ned Freed
- 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/… Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… Alexey Melnikov
- Re: [ietf-types] Registration of media typeimage/… Ned Freed
- Re: [ietf-types] Registration of media typeimage/… Chris Lilley
- [ietf-types] Registration of media typeimage/svg+… Chris Lilley
- Re: [ietf-types] Registration of media typeimage/… Ned Freed
- Re: [ietf-types] Registration of media typeimage/… Martin J. Dürst