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

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

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAU8Jign020607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Nov 2010 01:19:44 -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 oAU8JiOq020606; Tue, 30 Nov 2010 01:19:44 -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 mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by hoffman.proper.com (8.14.4/8.14.3) with SMTP id oAU8JgJM020601 for <ietf-xml-mime@imc.org>; Tue, 30 Nov 2010 01:19:42 -0700 (MST) (envelope-from julian.reschke@gmx.de)
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>
CC: =?ISO-8859-1?Q?=22Martin_J=2E_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
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
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>

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
>