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

Ned Freed <ned.freed@mrochek.com> Thu, 25 November 2010 20:01 UTC

Return-Path: <ned.freed@mrochek.com>
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 9CE8328C175 for <ietf-types@core3.amsl.com>; Thu, 25 Nov 2010 12:01:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level:
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3]
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 UgdDfd15fKFa for <ietf-types@core3.amsl.com>; Thu, 25 Nov 2010 12:01:14 -0800 (PST)
Received: from pechora3.lax.icann.org (pechora3.icann.org [208.77.188.38]) by core3.amsl.com (Postfix) with ESMTP id 991FE3A68E8 for <ietf-types@ietf.org>; Thu, 25 Nov 2010 12:01:09 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id oAPK1Y1x022976 for <ietf-types@iana.org>; Thu, 25 Nov 2010 12:01:55 -0800
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NUO88GWW9S009UF4@mauve.mrochek.com> for ietf-types@iana.org; Thu, 25 Nov 2010 12:01:28 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset="ISO-8859-1"; format="flowed"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NULODV3C34007CHU@mauve.mrochek.com>; Thu, 25 Nov 2010 12:01:26 -0800 (PST)
Message-id: <01NUO88FRVH6007CHU@mauve.mrochek.com>
Date: Thu, 25 Nov 2010 12:01:13 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 25 Nov 2010 14:30:17 +0900" <4CEDF469.7060101@it.aoyama.ac.jp>
References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> <1034064166.20101124233635@w3.org> <4CEDF469.7060101@it.aoyama.ac.jp>
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1290712544; bh=PesQAzoIvXXqMdASQp/PLkLlt/NRy6ATGDOaBLZPDS4=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=Zq3xw9gxNjJK2YsjD4LJVdfcqbwQinse9krPxr2teLkobqo4k65fEBllVXt6HhTsV ABUcztJ5nf5nfNOCG8GWFPQV4i45iX69jtat8MLOejwNY5mtTiSp6z8DZnTMLXMLkR gWDmsCtJCTjfCT1PrygvJ/MviWefg1vLHnouv+W8=
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [208.77.188.38]); Thu, 25 Nov 2010 12:01:56 -0800 (PST)
Cc: 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
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: Thu, 25 Nov 2010 20:01:15 -0000

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