Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB87dSMP050099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Dec 2010 00:39:28 -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 oB87dSHk050098; Wed, 8 Dec 2010 00:39:28 -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 scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB87dPRR050091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Dec 2010 00:39:27 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id oB87dMTv002464 for ; Wed, 8 Dec 2010 16:39:24 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5b65_9830_464bb914_029e_11e0_8bb2_001d096c5782; Wed, 08 Dec 2010 16:39:22 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51126) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 8 Dec 2010 16:39:24 +0900 Message-ID: <4CFF3622.2060502@it.aoyama.ac.jp> Date: Wed, 08 Dec 2010 16:39:14 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Chris Lilley CC: Alexey Melnikov , ietf-types@iana.org, ietf-xml-mime@imc.org 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> <4CEE0291.2040305@it.aoyama.ac.jp> <335994208.20101207155219@w3.org> In-Reply-To: <335994208.20101207155219@w3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello Chris, others, I'm glad to confirm that I'm extremely happy with your new wording. And I strictly promise I won't find any new hair in the soup anymore. Regards, Martin. On 2010/12/07 23:52, Chris Lilley wrote: > On Thursday, November 25, 2010, 7:30:41 AM, Martin wrote: > > MJD> What about: > > MJD> Fragment Identifiers > > MJD> For documents labeled as application/svg+xml, the fragment > MJD> identifier notation follows the XML Pointer Language (XPointer) > MJD> Framework (see http://www.w3.org/TR/xptr-framework/). Fragment > MJD> identifiers are either Shorthand Pointers (formerly called barenames) or > MJD> SVG view specifications. For details, please see Section 17.3.2 of the > MJD> SVG specification > MJD> (http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers). > > > MJD> or some such. > > I looked into this. At first, I was going to normatively reference XPointer Framework as you suggested. > > However, the SVG WG had made a decision not to reference XPointer (superceeded) and not to reference XPointer Framework either, partly because of concerns over the scope of the conformance criteria > http://www.w3.org/TR/xptr-framework/#conformance > and also because this is not in any case needed just to define barenames. > > So I have added adapted wording: > > > Fragment Identifiers > > For documents labeled as application/svg+xml, the > fragment identifier notation is either Shorthand Pointers > (formerly called barenames) or the SVG-specific SVG Views > syntax; > http://www.w3.org/TR/SVG/linking.html#LinksIntoSVG > both described in the fragment identifiers section of the > SVG specification. > http://www.w3.org/TR/SVG/linking.html#SVGFragmentIdentifiers > > > >>> 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 > > MJD> First, we made some tweaks, and second, the published specification is > MJD> all of SVG 1.1, not just the mimereg part, as far as I understand. > > Also fixed; both Appendix P and the spec as a whole are separately referenced. > > Published specification: > > This media type registration is extracted from Appendix P > http://www.w3.org/TR/SVG/mimereg.html > of the SVG 1.1 specification. > http://www.w3.org/TR/SVG/ > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB7HBPew015567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 10:11:25 -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 oB7HBPrC015566; Tue, 7 Dec 2010 10:11:25 -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 mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB7HBOH3015560 for ; Tue, 7 Dec 2010 10:11:24 -0700 (MST) (envelope-from ned+xml-mime@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NV4TRPQBSG00DA62@mauve.mrochek.com> for ietf-xml-mime@imc.org; Tue, 7 Dec 2010 09:11:22 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NUZOZ6T6UO007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Tue, 7 Dec 2010 09:11:16 -0800 (PST) From: ned+xml-mime@mrochek.com Cc: ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov , Philippe Le Hegaret Message-id: <01NV4TRMHDSC007CHU@mauve.mrochek.com> Date: Tue, 07 Dec 2010 09:10:56 -0800 (PST) Subject: Re: [ietf-types] Registration of media typeimage/svg+xml In-reply-to: "Your message dated Tue, 07 Dec 2010 15:52:24 +0100" <2110595737.20101207155224@w3.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <2110595737.20101207155224@w3.org> To: Chris Lilley DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1291739097; bh=vpl3bJ6p65H3zhPoY0cK5PMDrwpTvXM2/EP0yfFArD0=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=EZZmn4i7MAd/Y/HOQcDtSat1zn0V7MGpQ72k6uHeMaIsKxtSnL1VmhmopMQj62CNc CoRMyiUrAmP7C4bRTshvID5fAQxCn/jQkGfZ4hW8I6O+51znx0Xsx7M4SQq/RNx1bs PPYdPLh8u5zzlA0OtsoYWXxf0YqVgHn0DlWRg6aw= Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This looks ready to go to me. Ned > This is an updated and final registration request, incorporating the latest round of feedback. Philippe, this is ready to go to the IESG now. > 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 > http://www.w3.org/TR/SVG/mimereg.html > of the SVG 1.1 specification. > http://www.w3.org/TR/SVG/ > 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 either Shorthand Pointers > (formerly called barenames) or the SVG-specific SVG Views > syntax; > http://www.w3.org/TR/SVG/linking.html#LinksIntoSVG > both described in the fragment identifiers section of the > SVG specification. > http://www.w3.org/TR/SVG/linking.html#SVGFragmentIdentifiers > 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. > -- > Chris Lilley Technical Director, Interaction Domain > W3C Graphics Activity Lead, Fonts Activity Lead > Co-Chair, W3C Hypertext CG > Member, CSS, WebFonts, SVG Working Groups > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB7EqRsR008699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 07:52:27 -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 oB7EqRYK008698; Tue, 7 Dec 2010 07:52:27 -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 oB7EqP5w008685 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 7 Dec 2010 07:52:26 -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 ) id 1PPytw-0005Pg-Ae; Tue, 07 Dec 2010 09:52:20 -0500 Date: Tue, 7 Dec 2010 15:52:19 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <335994208.20101207155219@w3.org> To: "=?iso-8859-1?Q?=22Martin_J._D=FCrst=22?=" CC: Alexey Melnikov , ietf-types@iana.org, Subject: Re: [ietf-types] Registration of media typeimage/svg+xml In-Reply-To: <4CEE0291.2040305@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> <4CEE0291.2040305@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thursday, November 25, 2010, 7:30:41 AM, Martin wrote: MJD> What about: MJD> Fragment Identifiers MJD> For documents labeled as application/svg+xml, the fragment MJD> identifier notation follows the XML Pointer Language (XPointer) MJD> Framework (see http://www.w3.org/TR/xptr-framework/). Fragment MJD> identifiers are either Shorthand Pointers (formerly called barenames) or MJD> SVG view specifications. For details, please see Section 17.3.2 of the MJD> SVG specification MJD> (http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers). MJD> or some such. I looked into this. At first, I was going to normatively reference XPointer Framework as you suggested. However, the SVG WG had made a decision not to reference XPointer (superceeded) and not to reference XPointer Framework either, partly because of concerns over the scope of the conformance criteria http://www.w3.org/TR/xptr-framework/#conformance and also because this is not in any case needed just to define barenames. So I have added adapted wording: Fragment Identifiers For documents labeled as application/svg+xml, the fragment identifier notation is either Shorthand Pointers (formerly called barenames) or the SVG-specific SVG Views syntax; http://www.w3.org/TR/SVG/linking.html#LinksIntoSVG both described in the fragment identifiers section of the SVG specification. http://www.w3.org/TR/SVG/linking.html#SVGFragmentIdentifiers >>> 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 MJD> First, we made some tweaks, and second, the published specification is MJD> all of SVG 1.1, not just the mimereg part, as far as I understand. Also fixed; both Appendix P and the spec as a whole are separately referenced. Published specification: This media type registration is extracted from Appendix P http://www.w3.org/TR/SVG/mimereg.html of the SVG 1.1 specification. http://www.w3.org/TR/SVG/ -- Chris Lilley Technical Director, Interaction Domain W3C Graphics Activity Lead, Fonts Activity Lead Co-Chair, W3C Hypertext CG Member, CSS, WebFonts, SVG Working Groups Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB7EqRnc008697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 07:52:27 -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 oB7EqRbG008695; Tue, 7 Dec 2010 07:52:27 -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 oB7EqPg0008686 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 7 Dec 2010 07:52:26 -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 ) id 1PPyu1-0005Q0-18; Tue, 07 Dec 2010 09:52:25 -0500 Date: Tue, 7 Dec 2010 15:52:24 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <2110595737.20101207155224@w3.org> To: ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov , Philippe Le Hegaret Subject: Registration of media typeimage/svg+xml MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello , This is an updated and final registration request, incorporating the latest round of feedback. Philippe, this is ready to go to the IESG now. 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 http://www.w3.org/TR/SVG/mimereg.html of the SVG 1.1 specification. http://www.w3.org/TR/SVG/ 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 either Shorthand Pointers (formerly called barenames) or the SVG-specific SVG Views syntax; http://www.w3.org/TR/SVG/linking.html#LinksIntoSVG both described in the fragment identifiers section of the SVG specification. http://www.w3.org/TR/SVG/linking.html#SVGFragmentIdentifiers 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. -- Chris Lilley Technical Director, Interaction Domain W3C Graphics Activity Lead, Fonts Activity Lead Co-Chair, W3C Hypertext CG Member, CSS, WebFonts, SVG Working Groups Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB1JSSK2037908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Dec 2010 12:28:28 -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 oB1JSS6e037907; Wed, 1 Dec 2010 12:28:28 -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 mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB1JSPL6037901 for ; Wed, 1 Dec 2010 12:28:25 -0700 (MST) (envelope-from ned+xml-mime@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NUWKTHGFCG005VHV@mauve.mrochek.com> for ietf-xml-mime@imc.org; Wed, 1 Dec 2010 11:28:22 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NUWJ55RO74007CHU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Wed, 1 Dec 2010 11:27:55 -0800 (PST) From: ned+xml-mime@mrochek.com Cc: Ned Freed , =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov Message-id: <01NUWKSYCD2G007CHU@mauve.mrochek.com> Date: Wed, 01 Dec 2010 11:25:47 -0800 (PST) Subject: Re: [ietf-types] Registration of media typeimage/svg+xml In-reply-to: "Your message dated Tue, 30 Nov 2010 09:19:33 +0100" <4CF4B395.80001@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed 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> To: Julian Reschke DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1291228936; bh=3o2aI5ithxG/DTu2kl9bNdVvQfHzXFarts9bMzNYT38=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=L5Ck+pm0nU9xCqgpIw1fsY2MBuSX+Oyb3MvtH8cFXufzeePNnllp/yYAhwLhVwrzB ms2KTB2Xmuujv9NpQAEQn9wZu1PbqujQs2FiG/1heHJOB7bprDmCj690aFLzPbj9Dm 5xkH+ZN+NM/cgK+gAUeoOsa7XoPjdggrbHHpbb7U= Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > OK, is there anything left to do? The only remaining issue, which came up afer I sent this, is the bit about fragment ids. I'm happy with Martin's proposal change on that front, but others may not be. > Or is this already on the way to IANA? This is a standards tree registration so it goes to the IESG, not IANA. Ned