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

Julian Reschke <julian.reschke@gmx.de> Tue, 30 November 2010 08:18 UTC

Return-Path: <julian.reschke@gmx.de>
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 4BE713A6B3A for <ietf-types@core3.amsl.com>; Tue, 30 Nov 2010 00:18:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.666
X-Spam-Level:
X-Spam-Status: No, score=-104.666 tagged_above=-999 required=5 tests=[AWL=-1.267, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100]
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 saHgLQAyZb2K for <ietf-types@core3.amsl.com>; Tue, 30 Nov 2010 00:18:52 -0800 (PST)
Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::72]) by core3.amsl.com (Postfix) with ESMTP id 472393A6831 for <ietf-types@ietf.org>; Tue, 30 Nov 2010 00:18:50 -0800 (PST)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora7.dc.icann.org (8.13.8/8.13.8) with SMTP id oAU8JfJE007077 for <ietf-types@iana.org>; Tue, 30 Nov 2010 03:20:01 -0500
Received: (qmail invoked by alias); 30 Nov 2010 08:19:40 -0000
Received: from p508FB94B.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.185.75] by mail.gmx.net (mp002) with SMTP; 30 Nov 2010 09:19:40 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18Z9yMZK7UZd4qBYygRDux9Pm0DUgHkyjdwCD/JKm oLuD+sLIYmzHo4
Message-ID: <4CF4B395.80001@gmx.de>
Date: Tue, 30 Nov 2010 09:19:33 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Ned Freed <ned.freed@mrochek.com>
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>
In-Reply-To: <01NUO88FRVH6007CHU@mauve.mrochek.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.72]); Tue, 30 Nov 2010 03:20:01 -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
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 08:18:56 -0000

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