Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAUINBJ0057633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Nov 2010 11:23:11 -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 oAUINBMT057632; Tue, 30 Nov 2010 11:23:11 -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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAUIN94a057627 for ; Tue, 30 Nov 2010 11:23:10 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.2.157] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Nov 2010 18:23:07 +0000 Message-ID: <4CF540BF.50301@isode.com> Date: Tue, 30 Nov 2010 18:21:51 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Chris Lilley CC: 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> <01NUO88FRVH6007CHU@mauve.mrochek.com> <4CF4B395.80001@gmx.de> <477680602.20101130181417@w3.org> In-Reply-To: <477680602.20101130181417@w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris Lilley wrote: >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. > > Ok. Please also ask IESG to approve the registration through W3C liaison. I would like to get this done during the December 16th IESG telechat. Thanks, Alexey Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAUHF1U3054007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Nov 2010 10:15:01 -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 oAUHF1FA054006; Tue, 30 Nov 2010 10:15:01 -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 oAUHExUc053998 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 30 Nov 2010 10:15:00 -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 1PNTmn-00088X-Q5; Tue, 30 Nov 2010 12:14:38 -0500 Date: Tue, 30 Nov 2010 18:14:17 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <477680602.20101130181417@w3.org> To: Julian Reschke CC: Ned Freed , "=?iso-8859-1?Q?=22Martin_J._D=FCrst=22?=" , , , Alexey Melnikov Subject: Re: [ietf-types] Registration of media typeimage/svg+xml 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id oAUHF0Ub054000 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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 ; 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 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 CC: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov 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: List-ID: List-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 > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAQBFDlj092446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Nov 2010 04:15:13 -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 oAQBFDOa092445; Fri, 26 Nov 2010 04:15:13 -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 oAQBFBnr092438 for ; Fri, 26 Nov 2010 04:15:11 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 26 Nov 2010 11:15:09 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp046) with SMTP; 26 Nov 2010 12:15:09 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19loeFRgIdlGTb2SVIF7F7bMOPSD/wcwpeXMFddDb IV6jbawqRgqB7q Message-ID: <4CEF96B2.5080300@gmx.de> Date: Fri, 26 Nov 2010 12:14:58 +0100 From: Julian Reschke 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 CC: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov 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> <1984688973.20101125075332@w3.org> <4CEE2B4A.1090700@it.aoyama.ac.jp> <01NUO99PJNAC007CHU@mauve.mrochek.com> In-Reply-To: <01NUO99PJNAC007CHU@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 25.11.2010 21:25, Ned Freed wrote: > ... > So if we cannot nail this down I'm OK with moving forward with something > that's understood to be less than perfect. Remember, registrations can > always be revised. > ... Absolutely. Best regards, Julian Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAPKVcFk053054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Nov 2010 13:31:38 -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 oAPKVch9053053; Thu, 25 Nov 2010 13:31:38 -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 oAPKVZLs053040 for ; Thu, 25 Nov 2010 13:31:36 -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 <01NUO99QV00W0084ZO@mauve.mrochek.com> for ietf-xml-mime@imc.org; Thu, 25 Nov 2010 12:31:34 -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> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Thu, 25 Nov 2010 12:31:29 -0800 (PST) From: ned+xml-mime@mrochek.com Cc: Chris Lilley , Alexey Melnikov , ietf-types@iana.org, ietf-xml-mime@imc.org Message-id: <01NUO99PJNAC007CHU@mauve.mrochek.com> Date: Thu, 25 Nov 2010 12:25:07 -0800 (PST) Subject: Re: [ietf-types] Registration of media typeimage/svg+xml In-reply-to: "Your message dated Thu, 25 Nov 2010 18:24:26 +0900" <4CEE2B4A.1090700@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> <1984688973.20101125075332@w3.org> <4CEE2B4A.1090700@it.aoyama.ac.jp> To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1290714349; bh=LXcUNSUX8Xe6k2WxX9w1KeBBOLWOW+DM4GmJFhIHe/M=; h=MIME-version:Content-type:From:Cc:Message-id:Date:Subject: In-reply-to:References:To; b=OZ6mSdvSUFh0WdyIJUsWDVeOasF+KLcy/e/7AM+iipdeczwAoCCbLpDcEZvbWU80v QTzXy8Gc18WJRlNudrx/PX4LKsAaUWB14EpiZfR87TpJTWsVnz4N5ab6FaOJ5Jhbnv 81q8ulXqGkwtehWK3fTWLMz7kCS/LtEcvUXWwhPU= Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: First of all, I prefer Martin's text, modulo correcting any technical errors it may contain. THat said, the more important point is we cannot have registrations wait on some future clarification to the confusion surrounding fragment identifiers and how they should be handled in media type registrations. I cannot, for example, wait on 3023bis before approving the registrations in other trees that arrive at a rate of several every week. We've tried that tack before and we know what happens - people simply stop registrating things and it takes years for the process to recover. So if we cannot nail this down I'm OK with moving forward with something that's understood to be less than perfect. Remember, registrations can always be revised. Ned > Hello Chris, > On 2010/11/25 15:53, Chris Lilley wrote: > > On Thursday, November 25, 2010, 7:30:41 AM, Martin wrote: > > > > MJD> Sorry to pull back yet another time. > > > > Oh, after a decade of not getting registered, I'm getting used to someone bringing up a last minute problem as soon as it looks like we can go ahead. > Really sorry about that. > > MJD> I just found a comment by Björn > > MJD> Höhrmann in another thread saying that RFC 3032 doesn't define fragment > > MJD> identifiers. > > > > I know. But the TAG wants its successor to talk about them (and it does). > I know. I recently had the chance to attended the respective session > where the TAG discussed this issue. > > You seem to have missed the *** part below: > No, I didn't. > > 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 *** > That would be fine (with me, in any case) if RFC 3023 said something > definite about this issue. But it just mentions an "attempt". > > MJD> Upon checking, I found the following: > > > > MJD> http://tools.ietf.org/html/rfc3023#section-5 > > > > MJD> As of today, no established specifications define identifiers for XML > > MJD> media types. However, a working draft published by W3C, namely "XML > > MJD> Pointer Language (XPointer)", attempts to define fragment identifiers > > MJD> for text/xml and application/xml. The current specification for > > MJD> XPointer is available at http://www.w3.org/TR/xptr. > > > > But that language is no use either, > I agree. I just put it in there so that everybody can see what it says. > > because as you point out > > > > MJD> On top of that, http://www.w3.org/TR/xptr/ says it's superseeded. > > > > Which I also know, because RFC 3023bis has better language and was written after XPointer was superceeded. > That will be great, once RFC 3023bis will actually be an RFC. > > MJD> In > > MJD> this light, the following text from the registration may need > > MJD> reconsideration: > > > > No, it really doesn't, because it already has some future proofing built in because of "or its successors" > I don't mind "future proofing" if the present is also well defined. But > I don't think it's very appropriate to use "future proofing" if the > present isn't well defined. > > plus the fact that I have a fair idea what its successor will say. > I know you are one of the authors, and I trust you to do a good job on > this, but I also know that things often change. > > >>> 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. > > > > 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. > > > > No, because that misses out the XPonter registry for example. > I was under the impression that the only fragment syntaxes usable in SVG > would be 'barenames' and the view syntax. So I thought that the XPointer > registry was essentially irrelevant. If that's wrong, feel free to tweak > the above text. > However, if we actually had different ideas of what would be allowed as > SVG fragment identifiers, then this might show that pointing to a text > like "attempts to define fragment identifiers" isn't clear enough. > > MJD> 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 hope that RFC 3023bis can be completed soon, > > > > Martin, how can I put this politely. > > > > No. NO! > > > > No, we are not waiting for 3023bis to be done before registering image/svg+xml. > Sorry, but if you had read the whole sentence I wrote (see below for the > rest) before writing this, you would have understood that you don't have > to disagree with me, because I already agree with you: Let's register > image/svg+xml without waiting for RFC 3023bis to be completed. > > For one thing, 3023bis was sort of ready when there was an objection to its deprecation of text/xml. I'm working on a way around that, but it depends in turn on resolution of a longstanding issue on HTTPbis. > > > > For another thing, TAG is currently noodling some more on fragments and may want some 3023bis changes to special case RDF fragment identifiers. > [My understanding is that they already made their mind up on this, and > set the authors (including you) an email about this, but that there may > be an issue left with fragment identifiers and RDF*a*.] > > So, I am much more comfortable with the current wording than with your proposed change. > The current wording points to an "attemt" and some future spec that we > don't know when it will be done. I'm not sure what makes you comfortable > about that. > My wording was an attempt to remove these dependencies to make it clear > what can actually be used as a fragment identifier. If I got something > wrong, I don't have any problem with my proposal being fixed. > > MJD> and make > > MJD> this easier, but I hope we don't need to wait for this to complete the > > MJD> image/svg+xml registration. > > > > Exactly. So - no. > > > > MJD> This also brings me to another nit. The registration currently says: > > > > >>> 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, > > > > Martin, I have made the tweaks *to the editors draft* and it will show up under /TR next time it gets published, okay? > Ah, okay, then that's fine with me. > > In fact, to be sure, I made the tweaks to the editors draft and *then* after that converted the HTML to plain text, to create the email plain text version, to be sure they were identical. > > > > MJD> and second, the published specification is > > MJD> all of SVG 1.1, not just the mimereg part, > > > > Obviously > > > > MJD> as far as I understand. So > > MJD> what about something like: > > > > > > MJD> Published specification: > > > > MJD> This media type registration is an extracted and slightly adapted > > MJD> version of Appendix P of the SVG 1.1 specification > > MJD> (http://www.w3.org/TR/SVG11/). > > > > No to the 'slightly adapted' for reasons given above, > Just to confirm, fine with me. > > and no to the changing the link from appendix P to the entire spec because that is what the text says. > It is not clear whether the parenthesis is a clarification to "Appendix > P of the SVG 1.1 specification" or "the SVG 1.1 specification". I was > expecting the later, also because that would be in line with the title > of the section (Publish Specification must be SVG 1.1, not only appendix P). > Regards, Martin. > > The registration is appendix P and the spec is the spec, and no-one is going to mix them up surely. > > > > It says that there is the SVG 1.1 specification, and it says the media type registration is extracted from appendix P of it. > > > > Alexey, Keith, I request that we move ahead with the text that I submited earlier, on Wednesday, 24 November 2010, 23:36:35 (Wed, 24 Nov 2010 23:36:35 +0100) > > > -- > #-# 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 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAPK1atG052005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Nov 2010 13:01:36 -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 oAPK1a0q052003; Thu, 25 Nov 2010 13:01:36 -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 oAPK1WdV051997 for ; Thu, 25 Nov 2010 13:01:32 -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 <01NUO88GWW9S009UF4@mauve.mrochek.com> for ietf-xml-mime@imc.org; Thu, 25 Nov 2010 12:01:29 -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> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Thu, 25 Nov 2010 12:01:26 -0800 (PST) From: ned+xml-mime@mrochek.com Cc: Chris Lilley , ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov , Philippe Le Hegaret Message-id: <01NUO88FRVH6007CHU@mauve.mrochek.com> Date: Thu, 25 Nov 2010 12:01:13 -0800 (PST) Subject: Re: Registration of media typeimage/svg+xml 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: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1290712545; bh=PesQAzoIvXXqMdASQp/PLkLlt/NRy6ATGDOaBLZPDS4=; h=MIME-version:Content-type:From:Cc:Message-id:Date:Subject: In-reply-to:References:To; b=ntUQg/63gUXy7bVS7NNiLLnWylFn7k+PkSEGdRIUBsKIH0d/uraPe7Rl9knMVBN8E kTmT/t+xAUuYz1qe2tbcwt5e5hJmzUFHq4tWE8J8quEzfd1eCHqZz57MxhrWqUD1gv KYz/d6muTcu+Eh8dCZ/40K0qhoF7/v4OF9JfonBE= Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAP9Ofm3017962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Nov 2010 02:24:41 -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 oAP9OfO9017961; Thu, 25 Nov 2010 02:24:41 -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 oAP9OcMp017955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Nov 2010 02:24:40 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id oAP9ObXO012203 for ; Thu, 25 Nov 2010 18:24:37 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0861_3e08_d27212ae_f875_11df_88e3_001d096c566a; Thu, 25 Nov 2010 18:24:36 +0900 Received: from [IPv6:::1] ([133.2.210.1]:54799) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 25 Nov 2010 18:24:35 +0900 Message-ID: <4CEE2B4A.1090700@it.aoyama.ac.jp> Date: Thu, 25 Nov 2010 18:24:26 +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> <1984688973.20101125075332@w3.org> In-Reply-To: <1984688973.20101125075332@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, On 2010/11/25 15:53, Chris Lilley wrote: > On Thursday, November 25, 2010, 7:30:41 AM, Martin wrote: > > MJD> Sorry to pull back yet another time. > > Oh, after a decade of not getting registered, I'm getting used to someone bringing up a last minute problem as soon as it looks like we can go ahead. Really sorry about that. > MJD> I just found a comment by Björn > MJD> Höhrmann in another thread saying that RFC 3032 doesn't define fragment > MJD> identifiers. > > I know. But the TAG wants its successor to talk about them (and it does). I know. I recently had the chance to attended the respective session where the TAG discussed this issue. > You seem to have missed the *** part below: No, I didn't. > 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 *** That would be fine (with me, in any case) if RFC 3023 said something definite about this issue. But it just mentions an "attempt". > MJD> Upon checking, I found the following: > > MJD> http://tools.ietf.org/html/rfc3023#section-5 > > MJD> As of today, no established specifications define identifiers for XML > MJD> media types. However, a working draft published by W3C, namely "XML > MJD> Pointer Language (XPointer)", attempts to define fragment identifiers > MJD> for text/xml and application/xml. The current specification for > MJD> XPointer is available at http://www.w3.org/TR/xptr. > > But that language is no use either, I agree. I just put it in there so that everybody can see what it says. > because as you point out > > MJD> On top of that, http://www.w3.org/TR/xptr/ says it's superseeded. > > Which I also know, because RFC 3023bis has better language and was written after XPointer was superceeded. That will be great, once RFC 3023bis will actually be an RFC. > MJD> In > MJD> this light, the following text from the registration may need > MJD> reconsideration: > > No, it really doesn't, because it already has some future proofing built in because of "or its successors" I don't mind "future proofing" if the present is also well defined. But I don't think it's very appropriate to use "future proofing" if the present isn't well defined. > plus the fact that I have a fair idea what its successor will say. I know you are one of the authors, and I trust you to do a good job on this, but I also know that things often change. > >>> 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. > > 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. > > No, because that misses out the XPonter registry for example. I was under the impression that the only fragment syntaxes usable in SVG would be 'barenames' and the view syntax. So I thought that the XPointer registry was essentially irrelevant. If that's wrong, feel free to tweak the above text. However, if we actually had different ideas of what would be allowed as SVG fragment identifiers, then this might show that pointing to a text like "attempts to define fragment identifiers" isn't clear enough. > MJD> 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 hope that RFC 3023bis can be completed soon, > > Martin, how can I put this politely. > > No. NO! > > No, we are not waiting for 3023bis to be done before registering image/svg+xml. Sorry, but if you had read the whole sentence I wrote (see below for the rest) before writing this, you would have understood that you don't have to disagree with me, because I already agree with you: Let's register image/svg+xml without waiting for RFC 3023bis to be completed. > For one thing, 3023bis was sort of ready when there was an objection to its deprecation of text/xml. I'm working on a way around that, but it depends in turn on resolution of a longstanding issue on HTTPbis. > > For another thing, TAG is currently noodling some more on fragments and may want some 3023bis changes to special case RDF fragment identifiers. [My understanding is that they already made their mind up on this, and set the authors (including you) an email about this, but that there may be an issue left with fragment identifiers and RDF*a*.] > So, I am much more comfortable with the current wording than with your proposed change. The current wording points to an "attemt" and some future spec that we don't know when it will be done. I'm not sure what makes you comfortable about that. My wording was an attempt to remove these dependencies to make it clear what can actually be used as a fragment identifier. If I got something wrong, I don't have any problem with my proposal being fixed. > MJD> and make > MJD> this easier, but I hope we don't need to wait for this to complete the > MJD> image/svg+xml registration. > > Exactly. So - no. > > MJD> This also brings me to another nit. The registration currently says: > > >>> 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, > > Martin, I have made the tweaks *to the editors draft* and it will show up under /TR next time it gets published, okay? Ah, okay, then that's fine with me. > In fact, to be sure, I made the tweaks to the editors draft and *then* after that converted the HTML to plain text, to create the email plain text version, to be sure they were identical. > > MJD> and second, the published specification is > MJD> all of SVG 1.1, not just the mimereg part, > > Obviously > > MJD> as far as I understand. So > MJD> what about something like: > > > MJD> Published specification: > > MJD> This media type registration is an extracted and slightly adapted > MJD> version of Appendix P of the SVG 1.1 specification > MJD> (http://www.w3.org/TR/SVG11/). > > No to the 'slightly adapted' for reasons given above, Just to confirm, fine with me. > and no to the changing the link from appendix P to the entire spec because that is what the text says. It is not clear whether the parenthesis is a clarification to "Appendix P of the SVG 1.1 specification" or "the SVG 1.1 specification". I was expecting the later, also because that would be in line with the title of the section (Publish Specification must be SVG 1.1, not only appendix P). Regards, Martin. > The registration is appendix P and the spec is the spec, and no-one is going to mix them up surely. > > It says that there is the SVG 1.1 specification, and it says the media type registration is extracted from appendix P of it. > > Alexey, Keith, I request that we move ahead with the text that I submited earlier, on Wednesday, 24 November 2010, 23:36:35 (Wed, 24 Nov 2010 23:36:35 +0100) > -- #-# 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 oAP6s9Sh007596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 23:54:09 -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 oAP6s92M007595; Wed, 24 Nov 2010 23:54:09 -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 oAP6s8Ti007590 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 24 Nov 2010 23:54:08 -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 1PLViU-0002eL-5L; Thu, 25 Nov 2010 01:54:02 -0500 Date: Thu, 25 Nov 2010 07:53:32 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1984688973.20101125075332@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=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id oAP6s9Th007591 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> Sorry to pull back yet another time. Oh, after a decade of not getting registered, I'm getting used to someone bringing up a last minute problem as soon as it looks like we can go ahead. MJD> I just found a comment by Björn MJD> Höhrmann in another thread saying that RFC 3032 doesn't define fragment MJD> identifiers. I know. But the TAG wants its successor to talk about them (and it does). You seem to have missed the *** part below: 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 *** MJD> Upon checking, I found the following: MJD> http://tools.ietf.org/html/rfc3023#section-5 MJD> As of today, no established specifications define identifiers for XML MJD> media types. However, a working draft published by W3C, namely "XML MJD> Pointer Language (XPointer)", attempts to define fragment identifiers MJD> for text/xml and application/xml. The current specification for MJD> XPointer is available at http://www.w3.org/TR/xptr. But that language is no use either, because as you point out MJD> On top of that, http://www.w3.org/TR/xptr/ says it's superseeded. Which I also know, because RFC 3023bis has better language and was written after XPointer was superceeded. MJD> In MJD> this light, the following text from the registration may need MJD> reconsideration: No, it really doesn't, because it already has some future proofing built in because of "or its successors" plus the fact that I have a fair idea what its successor will say. >>> 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. 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. No, because that misses out the XPonter registry for example. MJD> 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 hope that RFC 3023bis can be completed soon, Martin, how can I put this politely. No. NO! No, we are not waiting for 3023bis to be done before registering image/svg+xml. For one thing, 3023bis was sort of ready when there was an objection to its deprecation of text/xml. I'm working on a way around that, but it depends in turn on resolution of a longstanding issue on HTTPbis. For another thing, TAG is currently noodling some more on fragments and may want some 3023bis changes to special case RDF fragment identifiers. So, I am much more comfortable with the current wording than with your proposed change. MJD> and make MJD> this easier, but I hope we don't need to wait for this to complete the MJD> image/svg+xml registration. Exactly. So - no. MJD> This also brings me to another nit. The registration currently says: >>> 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, Martin, I have made the tweaks *to the editors draft* and it will show up under /TR next time it gets published, okay? In fact, to be sure, I made the tweaks to the editors draft and *then* after that converted the HTML to plain text, to create the email plain text version, to be sure they were identical. MJD> and second, the published specification is MJD> all of SVG 1.1, not just the mimereg part, Obviously MJD> as far as I understand. So MJD> what about something like: MJD> Published specification: MJD> This media type registration is an extracted and slightly adapted MJD> version of Appendix P of the SVG 1.1 specification MJD> (http://www.w3.org/TR/SVG11/). No to the 'slightly adapted' for reasons given above, and no to the changing the link from appendix P to the entire spec because that is what the text says. The registration is appendix P and the spec is the spec, and no-one is going to mix them up surely. It says that there is the SVG 1.1 specification, and it says the media type registration is extracted from appendix P of it. Alexey, Keith, I request that we move ahead with the text that I submited earlier, on Wednesday, 24 November 2010, 23:36:35 (Wed, 24 Nov 2010 23:36:35 +0100) -- 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 oAP6UtAj006661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 23:30:55 -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 oAP6Utko006660; Wed, 24 Nov 2010 23:30:55 -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 oAP6UrNZ006655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Nov 2010 23:30:54 -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 oAP6Uq6g008767 for ; Thu, 25 Nov 2010 15:30:52 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 0b81_335c_8cac3bd6_f85d_11df_a477_001d096c5782; Thu, 25 Nov 2010 15:30:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:54862) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 25 Nov 2010 15:30:50 +0900 Message-ID: <4CEE0291.2040305@it.aoyama.ac.jp> Date: Thu, 25 Nov 2010 15:30:41 +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> In-Reply-To: <4CEDF469.7060101@it.aoyama.ac.jp> 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: Sorry to pull back yet another time. I just found a comment by Björn Höhrmann in another thread saying that RFC 3032 doesn't define fragment identifiers. Upon checking, I found the following: http://tools.ietf.org/html/rfc3023#section-5 >>>> 5. Fragment Identifiers Section 4.1 of [RFC2396] notes that the semantics of a fragment identifier (the part of a URI after a "#") is a property of the data resulting from a retrieval action, and that the format and interpretation of fragment identifiers is dependent on the media type of the retrieval result. As of today, no established specifications define identifiers for XML media types. However, a working draft published by W3C, namely "XML Pointer Language (XPointer)", attempts to define fragment identifiers for text/xml and application/xml. The current specification for XPointer is available at http://www.w3.org/TR/xptr. >>>> On top of that, http://www.w3.org/TR/xptr/ says it's superseeded. In this light, the following text from the registration may need reconsideration: >> 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. What about: >>>> Fragment Identifiers For documents labeled as application/svg+xml, the fragment identifier notation follows the XML Pointer Language (XPointer) Framework (see http://www.w3.org/TR/xptr-framework/). Fragment identifiers are either Shorthand Pointers (formerly called barenames) or SVG view specifications. For details, please see Section 17.3.2 of the SVG specification (http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers). >>>> or some such. I hope that RFC 3023bis can be completed soon, and make this easier, but I hope we don't need to wait for this to complete the image/svg+xml registration. This also brings me to another nit. The registration currently says: >> 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 First, we made some tweaks, and second, the published specification is all of SVG 1.1, not just the mimereg part, as far as I understand. So what about something like: >>>> Published specification: This media type registration is an extracted and slightly adapted version of Appendix P of the SVG 1.1 specification (http://www.w3.org/TR/SVG11/). >>>> I'm not against replacing SVG 1.1 with something like "the latest and greatest SVG specification" (and a link to http://www.w3.org/TR/SVG/), but I think we should be consistent. Regards, Martin. On 2010/11/25 14:30, "Martin J. Dürst" wrote: > 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 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAP6LDj1006234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 23:21:13 -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 oAP6LDDo006233; Wed, 24 Nov 2010 23:21:13 -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 new1.smtp.messagingengine.com (new1.smtp.messagingengine.com [66.111.4.221]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAP6LBYQ006227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Nov 2010 23:21:12 -0700 (MST) (envelope-from moore@network-heretics.com) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id AC5C720079; Thu, 25 Nov 2010 01:21:10 -0500 (EST) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 25 Nov 2010 01:21:10 -0500 X-Sasl-enc: Q5D2DL4GJBS6y8iY2a7CKEYxLZv/wGYTozgrTuzVAEdh 1290666069 Received: from 99-205-106-50.pools.spcsdns.net (99-205-106-50.pools.spcsdns.net [99.205.106.50]) by mail.messagingengine.com (Postfix) with ESMTPA id D6753400B34; Thu, 25 Nov 2010 01:21:07 -0500 (EST) Subject: Re: [ietf-types] Registration of media typeimage/svg+xml Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <4CEDF82A.7000502@it.aoyama.ac.jp> Date: Thu, 25 Nov 2010 01:21:05 -0500 Cc: Chris Lilley , Alexey Melnikov , "ietf-types@iana.org" , "ietf-xml-mime@imc.org" , Henri Sivonen , Larry Masinter Message-Id: <82567D04-0B63-4508-A3BB-2A966A447809@network-heretics.com> References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> <4CE60C77.6000601@it.aoyama.ac.jp> <701217612.20101124231612@w3.org> <4CEDF82A.7000502@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1082) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id oAP6LCYP006228 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: +1. Let's try to make things clear for people who are reading just the type registration. Someone who looks at the registration separately from the RFC or other specification shouldn't have to guess as to what "this specification" is. Keith On Nov 25, 2010, at 12:46 AM, Martin J. Dürst wrote: > Hello Chris, Larry, > > On 2010/11/25 7:16, Chris Lilley wrote: >> >> On Wednesday, November 24, 2010, 9:14:12 PM, Larry wrote: >> >> LM> Martin, in a couple of places you complained that the SVG registration >> LM> template, contained in a W3C document, referred to "this specification", >> LM> and said: >> >> LM> # "this specification" doesn't work when the registration template is >> LM> # taken out of the SVG spec. Either say "the SVG specification" or >> LM> # explicitly reference a specific version of the specification. >> >> LM> However, I think it is common practice both in W3C and IETF, that >> LM> a registration template embedded within another document can >> LM> reasonably say "this specification" to mean the document in which >> LM> it is embedded, > > In that context, this looks reasonable, but out of context, it does no longer make sense. Registration are often taken out of context, and should be able to stand alone, without readers having to guess what "the specification" might be. > >> LM> with the registry itself pointing to an >> LM> explicit version of the spec as well as the template within. > > IANA often, if not always, lists the relevant RFC. But I haven't seen them listing other specifications. I may have missed it. Anyway, that's usually outside the registration, so the registration is still not standalone. > >> Larry, your interjection is timely, as I was just about to edit the registration to address Martin's comment. >> >> Given that we already have >> >> Published specification: >> >> This media type registration is extracted from Appendix P of the >> SVG 1.1 specification. http://www.w3.org/TR/SVG/ >> >> I'm tempted to just s/this specification/the published specification/ > > Great! That makes the registration standalone, while at the same time doesn't look weird inside the specification. > >> LM> There are plenty of examples... perhaps those comments don't apply? > > The fact that there are plenty of examples doesn't mean that we can't fix it when we have a chance. I don't think it's worth doing back and fixing one by one, but if we are working on a registration anyway, we can make it better form the start. > >> LM> (This comment applies to all registries, not just of media types.) > > Agreed. > > > Regards, Martin. > > -- > #-# 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 > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAP5kYT5004501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 22:46:34 -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 oAP5kY8b004500; Wed, 24 Nov 2010 22:46:34 -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 scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAP5kWZb004495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Nov 2010 22:46:33 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id oAP5kVgZ024074 for ; Thu, 25 Nov 2010 14:46:31 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 0b84_3025_5ac4d2be_f857_11df_a477_001d096c5782; Thu, 25 Nov 2010 14:46:31 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40011) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 25 Nov 2010 14:46:29 +0900 Message-ID: <4CEDF82A.7000502@it.aoyama.ac.jp> Date: Thu, 25 Nov 2010 14:46:18 +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: Larry Masinter , Alexey Melnikov , "ietf-types@iana.org" , "ietf-xml-mime@imc.org" , Henri Sivonen Subject: Re: [ietf-types] Registration of media typeimage/svg+xml References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> <4CE60C77.6000601@it.aoyama.ac.jp> <701217612.20101124231612@w3.org> In-Reply-To: <701217612.20101124231612@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, Larry, On 2010/11/25 7:16, Chris Lilley wrote: > > On Wednesday, November 24, 2010, 9:14:12 PM, Larry wrote: > > LM> Martin, in a couple of places you complained that the SVG registration > LM> template, contained in a W3C document, referred to "this specification", > LM> and said: > > LM> # "this specification" doesn't work when the registration template is > LM> # taken out of the SVG spec. Either say "the SVG specification" or > LM> # explicitly reference a specific version of the specification. > > LM> However, I think it is common practice both in W3C and IETF, that > LM> a registration template embedded within another document can > LM> reasonably say "this specification" to mean the document in which > LM> it is embedded, In that context, this looks reasonable, but out of context, it does no longer make sense. Registration are often taken out of context, and should be able to stand alone, without readers having to guess what "the specification" might be. > LM> with the registry itself pointing to an > LM> explicit version of the spec as well as the template within. IANA often, if not always, lists the relevant RFC. But I haven't seen them listing other specifications. I may have missed it. Anyway, that's usually outside the registration, so the registration is still not standalone. > Larry, your interjection is timely, as I was just about to edit the registration to address Martin's comment. > > Given that we already have > > Published specification: > > This media type registration is extracted from Appendix P of the > SVG 1.1 specification. http://www.w3.org/TR/SVG/ > > I'm tempted to just s/this specification/the published specification/ Great! That makes the registration standalone, while at the same time doesn't look weird inside the specification. > LM> There are plenty of examples... perhaps those comments don't apply? The fact that there are plenty of examples doesn't mean that we can't fix it when we have a chance. I don't think it's worth doing back and fixing one by one, but if we are working on a registration anyway, we can make it better form the start. > LM> (This comment applies to all registries, not just of media types.) Agreed. Regards, Martin. -- #-# 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 oAP5UWTC003870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 22:30:32 -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 oAP5UWCk003869; Wed, 24 Nov 2010 22:30:32 -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 oAP5UT02003862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Nov 2010 22:30:31 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id oAP5USdJ025607 for ; Thu, 25 Nov 2010 14:30:28 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0863_3768_1caaced6_f855_11df_88e3_001d096c566a; Thu, 25 Nov 2010 14:30:28 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57846) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 25 Nov 2010 14:30:27 +0900 Message-ID: <4CEDF469.7060101@it.aoyama.ac.jp> Date: Thu, 25 Nov 2010 14:30:17 +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: ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov , Philippe Le Hegaret Subject: Re: Registration of media typeimage/svg+xml References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> <1034064166.20101124233635@w3.org> In-Reply-To: <1034064166.20101124233635@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: 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 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAOMacNd087700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 15:36:38 -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 oAOMacRl087699; Wed, 24 Nov 2010 15:36:38 -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 oAOMabTX087687 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 24 Nov 2010 15:36:38 -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 1PLNx6-0008MK-5E; Wed, 24 Nov 2010 17:36:36 -0500 Date: Wed, 24 Nov 2010 23:36:35 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1034064166.20101124233635@w3.org> To: Chris Lilley CC: ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov , Philippe Le Hegaret Subject: Re: Registration of media typeimage/svg+xml In-Reply-To: <1912120148.20101118235236@w3.org> References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> 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: 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. -- 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 oAOMGM9w086878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 15:16:22 -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 oAOMGM7Z086877; Wed, 24 Nov 2010 15:16:22 -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 oAOMGKJf086860 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 24 Nov 2010 15:16:21 -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 1PLNdM-0006tn-Do; Wed, 24 Nov 2010 17:16:12 -0500 Date: Wed, 24 Nov 2010 23:16:12 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <701217612.20101124231612@w3.org> To: Larry Masinter CC: "=?iso-8859-1?Q?=22Martin_J._D=FCrst=22?=" , Alexey Melnikov , "ietf-types@iana.org" , "ietf-xml-mime@imc.org" , Henri Sivonen Subject: Re: [ietf-types] Registration of media typeimage/svg+xml In-Reply-To: References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> <4CE60C77.6000601@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 Wednesday, November 24, 2010, 9:14:12 PM, Larry wrote: LM> Martin, in a couple of places you complained that the SVG registration LM> template, contained in a W3C document, referred to "this specification", LM> and said: LM> # "this specification" doesn't work when the registration template is LM> # taken out of the SVG spec. Either say "the SVG specification" or LM> # explicitly reference a specific version of the specification. LM> However, I think it is common practice both in W3C and IETF, that LM> a registration template embedded within another document can LM> reasonably say "this specification" to mean the document in which LM> it is embedded, with the registry itself pointing to an LM> explicit version of the spec as well as the template within. Larry, your interjection is timely, as I was just about to edit the registration to address Martin's comment. Given that we already have Published specification: This media type registration is extracted from Appendix P of the SVG 1.1 specification. http://www.w3.org/TR/SVG/ I'm tempted to just s/this specification/the published specification/ LM> There are plenty of examples... perhaps those comments don't apply? LM> (This comment applies to all registries, not just of media types.) LM> Larry -- 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 oAJBVFZj028248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2010 04:31:15 -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 oAJBVF9R028247; Fri, 19 Nov 2010 04:31:15 -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 scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAJBVDBu028238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Nov 2010 04:31:14 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id oAJBVB1Z030288 for ; Fri, 19 Nov 2010 20:31:12 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 39d8_5311_82b2f944_f3d0_11df_826e_001d096c566a; Fri, 19 Nov 2010 20:31:11 +0900 Received: from [IPv6:::1] ([133.2.210.1]:38923) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 19 Nov 2010 20:31:12 +0900 Message-ID: <4CE65FED.4030003@it.aoyama.ac.jp> Date: Fri, 19 Nov 2010 20:30:53 +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: Julian Reschke CC: Yves Lafon , ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov Subject: Re: [ietf-types] Registration of media typeimage/svg+xml References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> <4CE65718.3090000@gmx.de> In-Reply-To: <4CE65718.3090000@gmx.de> 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: Yes, and the same for the Macintosh file type code(s). (sorry I missed this in my last mail) Regards, Martin. On 2010/11/19 19:53, Julian Reschke wrote: > On 19.11.2010 10:57, Yves Lafon wrote: >> On Thu, 18 Nov 2010, Chris Lilley wrote: >> >>> Additional information: >>> >>> Magic number(s): >>> File extension(s): >>> svg, svgz (if gzip-compressed) >> >> Wouldn't it be better to say: >> >> File extension(s): >> svg >> Note that 'svgz' is used as an alias for 'svg.gz' [RFC1952] > > "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." > > (this emphasizes that it stops being image/xvg+xml) > > Best regards, Julian > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types > > -- #-# 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 oAJArO49026282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2010 03:53:24 -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 oAJArObo026281; Fri, 19 Nov 2010 03:53:24 -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 oAJArMF0026275 for ; Fri, 19 Nov 2010 03:53:23 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 19 Nov 2010 10:53:21 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp062) with SMTP; 19 Nov 2010 11:53:21 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/4hF4SNP74OHQztj/BhHUiHKd9jNeJ8wWp7PgWI3 qhuj7B7sWcZPs9 Message-ID: <4CE65718.3090000@gmx.de> Date: Fri, 19 Nov 2010 11:53:12 +0100 From: Julian Reschke 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: Yves Lafon CC: Chris Lilley , 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 19.11.2010 10:57, Yves Lafon wrote: > On Thu, 18 Nov 2010, Chris Lilley wrote: > >> Additional information: >> >> Magic number(s): >> File extension(s): >> svg, svgz (if gzip-compressed) > > Wouldn't it be better to say: > > File extension(s): > svg > Note that 'svgz' is used as an alias for 'svg.gz' [RFC1952] "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." (this emphasizes that it stops being image/xvg+xml) Best regards, Julian Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAJABMf8024102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2010 03:11:23 -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 oAJABMAi024101; Fri, 19 Nov 2010 03:11:22 -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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAJABLPC024095 for ; Fri, 19 Nov 2010 03:11:22 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [188.28.96.205] (188.28.96.205.threembb.co.uk [188.28.96.205]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 19 Nov 2010 10:11:19 +0000 Message-ID: <4CE64D46.3060607@isode.com> Date: Fri, 19 Nov 2010 10:11:18 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Yves Lafon CC: Chris Lilley , 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> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yves Lafon wrote: > On Thu, 18 Nov 2010, Chris Lilley wrote: >> Additional information: >> >> Magic number(s): >> File extension(s): >> svg, svgz (if gzip-compressed) > Wouldn't it be better to say: > > File extension(s): > svg > Note that 'svgz' is used as an alias for 'svg.gz' [RFC1952] Yes. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAJ9gRqt021854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2010 02:42: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 oAJ9gRmq021853; Fri, 19 Nov 2010 02:42: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 mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by hoffman.proper.com (8.14.4/8.14.3) with SMTP id oAJ9gPvo021848 for ; Fri, 19 Nov 2010 02:42:26 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 19 Nov 2010 09:42:23 -0000 Received: from p508FD3F8.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.211.248] by mail.gmx.net (mp009) with SMTP; 19 Nov 2010 10:42:23 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+cVQxMqkOcDXmkFebiTN05qwKabaDt3GCfbeu+ze HRirKq+pyr/Mb5 Message-ID: <4CE64676.40002@gmx.de> Date: Fri, 19 Nov 2010 10:42:14 +0100 From: Julian Reschke 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: Chris Lilley CC: Ned Freed , ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov , Maciej Stachowiak Subject: Re: Registration of media typeimage/svg+xml References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <4CE57C38.4080307@gmx.de> <282747763.20101118210121@w3.org> <4CE58A74.2060503@gmx.de> <01NUEK09JNWC007FL5@mauve.mrochek.com> <784237972.20101118232249@w3.org> In-Reply-To: <784237972.20101118232249@w3.org> 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: List-ID: List-Unsubscribe: On 18.11.2010 23:22, Chris Lilley wrote: > ... > In that case I can remove the section. > ... Thanks for that! > ... > Julian, does that satisfy your concern as well? > ... Partly. As Björn already said, the svgz file extension still is mentioned in a way that could be understood to say that the gzipped variant *is* the same mime type. I think we have now agree that it is not, right? One way to address this would be to mention it elsewhere, stating this is just a convention, and how it needs to be handled. I do believe that the registration template is not the best place for it, though (maybe a WG Note that establishes the filename convention and shows how to serve that stuff over HTTP?). Of course an alternative is to make it a *separate* media type. I believe that Maciej Stachowiak said at the Lyon TPAC that Safari on MacOS internally uses media types, and that they actually had to add a workaround so that they could map both *.svg and *.svgz to the same (hopefully I got that right; cc'ing him). That's exactly the kind of problem I'm hoping to avoid. Best regards, Julian Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAJ5ZBES009864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 22:35:11 -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 oAJ5ZBkf009863; Thu, 18 Nov 2010 22:35:11 -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 oAJ5Z8sj009857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Nov 2010 22:35:10 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id oAJ5Z6ci012593 for ; Fri, 19 Nov 2010 14:35:07 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 39d7_2910_c3e74fbe_f39e_11df_826e_001d096c566a; Fri, 19 Nov 2010 14:35:06 +0900 Received: from [IPv6:::1] ([133.2.210.1]:53355) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 19 Nov 2010 14:35:06 +0900 Message-ID: <4CE60C77.6000601@it.aoyama.ac.jp> Date: Fri, 19 Nov 2010 14:34:47 +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, Henri Sivonen , Larry Masinter Subject: Re: [ietf-types] Registration of media typeimage/svg+xml References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> In-Reply-To: <1912120148.20101118235236@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, On 2010/11/19 7:52, Chris Lilley wrote: > This is an updated registration request, incorporating some feedback > from Ned Freed and Julian Reschke I agree with Ned and Julian. This registration now looks good to me, except for a little detail pointed out below. As for why I was very uneasy with mentioning .svgz in the Mime Media Type registration of image/svg+xml, please see the following excerpt from a conversation between Larry Masinter and Henri Sivonen (http://lists.w3.org/Archives/Public/www-tag/2010Nov/0053.html): >>>> > What were the problems with image/svg+xml, image/jp2 and/or video/mp4? The problem with image/svg+xml is that after a decade of deployment and W3C REC status, the type still isn't in the registry. Even if the IETF experts found something wrong with the type, it would be way too late to stop its deployment, so there's really no point in subjecting it to expert review at this point. >>>> >>>> > As for image/svg+xml not being used for 'XML' format. I think this is a 3023bis issue? Do you mean sending gzipped data as image/svg+xml without Content-Encoding: gzip? >>>> I concluded (I hope erroneously) that there was gzipped SVG content out there that was sent with a naked Content-Type: image/svg+xml, and that some people in the industry thought that that was just okay. It is very clear that it is not okay, and that the registry should not at all suggest that it would be okay. > Type name: > > image > > Subtype name: > > svg+xml > > Required parameters: > > None. > > Optional parameters: > > charset > > Same as application/xml media type, as specified in [RFC3023] or > it's successors. > > Encoding considerations: > > Same as for application/xml. See [RFC3023], section 3.2 or it's > 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 this specification, this content will be outside the "this specification" doesn't work when the registration template is taken out of the SVG spec. Either say "the SVG specification" or explicitly reference a specific version of the specification. > 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: > > This specification describes processing semantics that dictate Same problem here. > 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/ > > 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, svgz (if gzip-compressed) > Macintosh file type code(s): > "svg " (all lowercase, with a space character as the fourth > letter), "svgz" (all lowercase, if gzip-compressed). > 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. And same problem here again. Actually, in this case, I'm under the impression that "Change controller" refers to the change controller of the registration, not the specification (which would be the same, but would be written differently). But I might be wrong. Regards, Martin. -- #-# 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 oAIMr0rl092664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 15:53:00 -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 oAIMr0f4092663; Thu, 18 Nov 2010 15:53:00 -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 oAIMqxTY092657 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 18 Nov 2010 15:52:59 -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 1PJDLd-0003NJ-Kj; Thu, 18 Nov 2010 17:52:57 -0500 Date: Thu, 18 Nov 2010 23:52:36 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1912120148.20101118235236@w3.org> To: Chris Lilley CC: ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov Subject: Re: Registration of media typeimage/svg+xml In-Reply-To: <1715145489.20101118190255@w3.org> References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> 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: This is an updated registration request, incorporating some feedback from Ned Freed and Julian Reschke Type name: image Subtype name: svg+xml Required parameters: None. Optional parameters: charset Same as application/xml media type, as specified in [RFC3023] or it's successors. Encoding considerations: Same as for application/xml. See [RFC3023], section 3.2 or it's 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 this 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: This 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/ 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, svgz (if gzip-compressed) Macintosh file type code(s): "svg " (all lowercase, with a space character as the fourth letter), "svgz" (all lowercase, if gzip-compressed). 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. -- 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 oAIMOOoK091449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 15:24:24 -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 oAIMOOJ3091448; Thu, 18 Nov 2010 15:24:24 -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 oAIMON00091443 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 18 Nov 2010 15:24:23 -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 1PJCtk-0001ii-Cv; Thu, 18 Nov 2010 17:24:08 -0500 Date: Thu, 18 Nov 2010 23:22:49 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <784237972.20101118232249@w3.org> To: Ned Freed CC: Julian Reschke , ietf-types@iana.org, , Alexey Melnikov Subject: Re: Registration of media typeimage/svg+xml In-Reply-To: <01NUEK09JNWC007FL5@mauve.mrochek.com> References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <4CE57C38.4080307@gmx.de> <282747763.20101118210121@w3.org> <4CE58A74.2060503@gmx.de> <01NUEK09JNWC007FL5@mauve.mrochek.com> 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 18, 2010, 10:26:51 PM, Ned wrote: >> On 18.11.2010 21:01, Chris Lilley wrote: read BCP 13, RFC 4288 section 4.6 "Security requirements" where you will find >> > >> > A media type that employs compression may provide an opportunity >> > for sending a small amount of data that, when received and >> > evaluated, expands enormously to consume all of the recipient's >> > resources. All media types SHOULD state whether or not they >> > employ compression, and if they do they should discuss >> > what steps need to be taken to avoid such attacks. NF> Read the section again. It is clearly talking about media types that employ NF> compression *internally*, not compression done at other layers. NF> Any media type can, and often is, compressed at other layers. Discussion NF> of such actions has no business being in any particular media type NF> registration. OK. NF> If, however, the answer is never - and I'm pretty sure it is - then all mention NF> of compression needs to be dropped from this registration, as it is doing NF> nothing useful and is just making things unclear. At most you might want a note NF> about it in the encoding consideration sections saying external compression is NF> often used with this type. Again, lots of media types are compressed at other NF> layers; this has nothing to do with the image/svg+xml media type specifically. In that case I can remove the section. Julian, does that satisfy your concern as well? -- 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 oAILojUG090168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 14:50:45 -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 oAILojRZ090167; Thu, 18 Nov 2010 14:50:45 -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 oAILogWJ090160 for ; Thu, 18 Nov 2010 14:50:44 -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 <01NUEK0CIU4G00AUIU@mauve.mrochek.com> for ietf-xml-mime@imc.org; Thu, 18 Nov 2010 13:50:39 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NUEFTLYONK007FL5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Thu, 18 Nov 2010 13:50:31 -0800 (PST) From: ned+xml-mime@mrochek.com Cc: Chris Lilley , ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov Message-id: <01NUEK09JNWC007FL5@mauve.mrochek.com> Date: Thu, 18 Nov 2010 13:26:51 -0800 (PST) Subject: Re: Registration of media typeimage/svg+xml In-reply-to: "Your message dated Thu, 18 Nov 2010 21:20:04 +0100" <4CE58A74.2060503@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <4CE57C38.4080307@gmx.de> <282747763.20101118210121@w3.org> <4CE58A74.2060503@gmx.de> To: Julian Reschke DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1290114408; bh=asRhbvshYgAY9m20ZjmT6iKehhKoXebqljeR+yIsG8g=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=A+zI0UY1kWhAYmX3zSBWzd/g0fb8nD6TJXHnUnmrjkpLstp36T7Urt7eo2xOGsq7g attIgN5nJK5530sGG+judBow+ypsZ80IuICPbOk46SAoLryDoUXYvCno+TOFk+fGdZ AiTSS7NWqS1Ujqpzz16jqkj0swv9h/y5AQLHDAqU= Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On 18.11.2010 21:01, Chris Lilley wrote: > > On Thursday, November 18, 2010, 8:19:20 PM, Julian wrote: > > > > JR> On 18.11.2010 19:02, Chris Lilley wrote: > >>> ... > >>> Security considerations: > >>> ... > >>> SVG documents may be transmitted in compressed form using gzip > >>> compression. For systems which employ MIME-like mechanisms, such > >>> as HTTP, this is indicated by the Content-Encoding or > >>> Transfer-Encoding header, as appropriate; for systems which do > >>> not, such as direct filesystem access, this is indicated by the > >>> filename extension and by the Macintosh File Type Codes. In > >>> addition, gzip compressed content is readily recognised by the > >>> initial byte sequence as described in [RFC1952] section 2.3.1. > >>> ... > > > > JR> 1) What does this have to do with "Security Considerations"? > > > > Please read BCP 13, RFC 4288 section 4.6 "Security requirements" where you will find > > > > A media type that employs compression may provide an opportunity > > for sending a small amount of data that, when received and > > evaluated, expands enormously to consume all of the recipient's > > resources. All media types SHOULD state whether or not they > > employ compression, and if they do they should discuss > > what steps need to be taken to avoid such attacks. Read the section again. It is clearly talking about media types that employ compression *internally*, not compression done at other layers. Any media type can, and often is, compressed at other layers. Discussion of such actions has no business being in any particular media type registration. > Agreed. > But then it would need to be clearly stated, that, you know, the content > can be gzipped and still be image/svg+xml. > Can it? This is indeed the question: If I have a static object of type image/svg+xml, is it inside a gzip container or not? If the answer to this question is yes, then: (a) The security consideration section is appropriate, but needs to be clarified to state specifically that the media type employs compression internally, and (b) The +xml on the type name MUST be removed, because the type cannot simply be processed directly as XML, which is what +xml means. The same actions apply if the answer is "sometimes". If, however, the answer is never - and I'm pretty sure it is - then all mention of compression needs to be dropped from this registration, as it is doing nothing useful and is just making things unclear. At most you might want a note about it in the encoding consideration sections saying external compression is often used with this type. Again, lots of media types are compressed at other layers; this has nothing to do with the image/svg+xml media type specifically. > Because otherwise if you're talking about compression on the transport > layer, this doesn't need to be stated here. It confuses layers. Exactly. > > JR> 2) I find the whole paragraph misleading; I'd like to see a clear > > JR> statement about whether the stream of octets resulting from gzipping SVG > > JR> can be labeled as "image/svg+xml" or not > > > > Not by itself, no. In a MIME context, it must be labelled as Content-type: > > image/svg+xml **AND** Transfer-Encoding: gzip. Please note the AND. Sorry, you cannot make that a requirement of a media type. At most you can suggest that a compressed encoding may be helpful. But general purpose media types like this travel over all sorts of different transports all the time - including ones that lack support for particular compression mechanisms - so the notion that they're constrained to a particular transport is simply a fantasy. > So why we do have the paragraph above in the first place? Exactly. > *Any* media type can be used with Content-Encoding: gzip over HTTP. > > This is not the same thing as Content-type: application/octet-stream and Transfer-Encoding: gzip - because that conveys the encoding, but omits the content type. > Nobody said that. > > In other words the encoding label ADDS TO the media type; it does not > remove the type. > "The Content-Encoding entity-header field is used as a modifier to the > media-type. When present, its value indicates what additional content > codings have been applied to the entity-body, and thus what decoding > mechanisms must be applied in order to obtain the media-type referenced > by the Content-Type header field. Content-Encoding is primarily used to > allow a document to be compressed without losing the identity of its > underlying media type." -- > > So once you apply the Content-Encoding you have to undo it to get back > the payload specified by the Content-Type. It's orthogonal. It doesn't > make the payload an instance of the media type *until* you undo the > encoding. Correct. > > Indeed, this is why separate labelling of encoding was added. Back in the early days people would use gzipped VRML or gzipped PostScript, and attempted to register application/gzip; but since they were using the Media Type to hold the encoding information they had lost important information, so VRML viewers were sent PostScript and so on. Some people said this was okay, unzip and then look at the filename extension. But a much better way was to add the encoding headers. > > > > JR> (please consider transports > > JR> other than HTTP, such as a file system that actually supports typing by > > JR> Internet media types). > > > > Please feel free to file a bug report for the BeOS filesystem saying that > > it should support labelling of encodings in addition to media types. How a particular OS elects to label files, and the restrictions it imposes through it's choice of labelling, are 100% irrlevant to the matter at hand. > > Speaking as a former BeOS user myself, I still consider modern SVG > > implementations (of which there are many) to be a rather more numerous and > > relevant consideration than a promising, but obsolete and abandoned, operating > > system from 15 years ago. Frankly, it would not matter if you were talking about all versions of Windows here. Many if not most operating systems have botched media type handling in some way or other; the solution to this problem isn't to break existing media type semantics. > I really honestly (!) have no idea what you're referring to. > For the media type registration what's relevant is what kind of octet > sequences you can label with the type you register. > So, I hear you saying: "it can be gzipped when used in a MIME context if > and only if you label it with "content-encoding: gzip". > That's true, and nobody disagrees with it. It's true for *any* media > type. It doesn't require any additional statements. Quite right. > > JR> If yes, that's a violation of "+xml" (and the last sentence points into > > JR> this direction). If not, please remove the paragraph above. > > > > JR> 3) If the intent is to say that "svgz" acts as file extension for > > JR> gzipped SVG, and *that* content can be served over HTTP as-is with > > > > JR> Content-Type: image/svg+xml > > JR> Content-Encoding: gzip > > > > That is exactly what it says, yes > > > > JR> than this is obviously ok > > > > I'm glad its obviously OK. > But the way it's stated is totally misleading. > Please keep in mind that I only joined this discussion after other > people complained (I stumbled into it during a conversation at the IETF > meeting in Maastricht). > > JR> because it follows from RFC 2616, and has > > JR> *nothing* to do with the media type (except for the extension > > JR> recommendation). > > > > So you oppose reminding people how to detect such gzipped content? > > > > Why would you want to do that? > Because it makes it sound like detecting gzipped content by inspecting > the header is an acceptable way to handle this media type. That's exactly what it does, and that along with the other confusion really is not OK. Ned Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAIKKHO7086350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 13:20:18 -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 oAIKKHox086349; Thu, 18 Nov 2010 13:20:17 -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 oAIKKFtm086341 for ; Thu, 18 Nov 2010 13:20:16 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 18 Nov 2010 20:20:13 -0000 Received: from p508FCC1A.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.204.26] by mail.gmx.net (mp070) with SMTP; 18 Nov 2010 21:20:13 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18LrsF5QN4LtqW/rCxPRHJNPHE5krXgHO2ocZv9zn tZ1Zef/g1MV+vm Message-ID: <4CE58A74.2060503@gmx.de> Date: Thu, 18 Nov 2010 21:20:04 +0100 From: Julian Reschke 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: Chris Lilley CC: ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov Subject: Re: Registration of media typeimage/svg+xml References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <4CE57C38.4080307@gmx.de> <282747763.20101118210121@w3.org> In-Reply-To: <282747763.20101118210121@w3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 18.11.2010 21:01, Chris Lilley wrote: > On Thursday, November 18, 2010, 8:19:20 PM, Julian wrote: > > JR> On 18.11.2010 19:02, Chris Lilley wrote: >>> ... >>> Security considerations: >>> ... >>> SVG documents may be transmitted in compressed form using gzip >>> compression. For systems which employ MIME-like mechanisms, such >>> as HTTP, this is indicated by the Content-Encoding or >>> Transfer-Encoding header, as appropriate; for systems which do >>> not, such as direct filesystem access, this is indicated by the >>> filename extension and by the Macintosh File Type Codes. In >>> addition, gzip compressed content is readily recognised by the >>> initial byte sequence as described in [RFC1952] section 2.3.1. >>> ... > > JR> 1) What does this have to do with "Security Considerations"? > > Please read BCP 13, RFC 4288 section 4.6 "Security requirements" where you will find > > A media type that employs compression may provide an opportunity > for sending a small amount of data that, when received and > evaluated, expands enormously to consume all of the recipient's > resources. All media types SHOULD state whether or not they > employ compression, and if they do they should discuss > what steps need to be taken to avoid such attacks. Agreed. But then it would need to be clearly stated, that, you know, the content can be gzipped and still be image/svg+xml. Can it? Because otherwise if you're talking about compression on the transport layer, this doesn't need to be stated here. It confuses layers. > JR> 2) I find the whole paragraph misleading; I'd like to see a clear > JR> statement about whether the stream of octets resulting from gzipping SVG > JR> can be labeled as "image/svg+xml" or not > > Not by itself, no. In a MIME context, it must be labelled as Content-type: image/svg+xml **AND** Transfer-Encoding: gzip. Please note the AND. So why we do have the paragraph above in the first place? *Any* media type can be used with Content-Encoding: gzip over HTTP. > This is not the same thing as Content-type: application/octet-stream and Transfer-Encoding: gzip - because that conveys the encoding, but omits the content type. Nobody said that. > In other words the encoding label ADDS TO the media type; it does not remove the type. "The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type." -- So once you apply the Content-Encoding you have to undo it to get back the payload specified by the Content-Type. It's orthogonal. It doesn't make the payload an instance of the media type *until* you undo the encoding. > Indeed, this is why separate labelling of encoding was added. Back in the early days people would use gzipped VRML or gzipped PostScript, and attempted to register application/gzip; but since they were using the Media Type to hold the encoding information they had lost important information, so VRML viewers were sent PostScript and so on. Some people said this was okay, unzip and then look at the filename extension. But a much better way was to add the encoding headers. > > JR> (please consider transports > JR> other than HTTP, such as a file system that actually supports typing by > JR> Internet media types). > > Please feel free to file a bug report for the BeOS filesystem saying that it should support labelling of encodings in addition to media types. > > Speaking as a former BeOS user myself, I still consider modern SVG implementations (of which there are many) to be a rather more numerous and relevant consideration than a promising, but obsolete and abandoned, operating system from 15 years ago. I really honestly (!) have no idea what you're referring to. For the media type registration what's relevant is what kind of octet sequences you can label with the type you register. So, I hear you saying: "it can be gzipped when used in a MIME context if and only if you label it with "content-encoding: gzip". That's true, and nobody disagrees with it. It's true for *any* media type. It doesn't require any additional statements. > JR> If yes, that's a violation of "+xml" (and the last sentence points into > JR> this direction). If not, please remove the paragraph above. > > JR> 3) If the intent is to say that "svgz" acts as file extension for > JR> gzipped SVG, and *that* content can be served over HTTP as-is with > > JR> Content-Type: image/svg+xml > JR> Content-Encoding: gzip > > That is exactly what it says, yes > > JR> than this is obviously ok > > I'm glad its obviously OK. But the way it's stated is totally misleading. Please keep in mind that I only joined this discussion after other people complained (I stumbled into it during a conversation at the IETF meeting in Maastricht). > JR> because it follows from RFC 2616, and has > JR> *nothing* to do with the media type (except for the extension > JR> recommendation). > > So you oppose reminding people how to detect such gzipped content? > > Why would you want to do that? Because it makes it sound like detecting gzipped content by inspecting the header is an acceptable way to handle this media type. Best regards, Julian Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAIK21vZ085515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 13:02:01 -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 oAIK21R2085514; Thu, 18 Nov 2010 13:02:01 -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 oAIK20VT085509 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 18 Nov 2010 13:02:01 -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 1PJAg8-000248-Ty; Thu, 18 Nov 2010 15:01:57 -0500 Date: Thu, 18 Nov 2010 21:01:21 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <282747763.20101118210121@w3.org> To: Julian Reschke CC: ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov Subject: Re: Registration of media typeimage/svg+xml In-Reply-To: <4CE57C38.4080307@gmx.de> References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <4CE57C38.4080307@gmx.de> 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 18, 2010, 8:19:20 PM, Julian wrote: JR> On 18.11.2010 19:02, Chris Lilley wrote: >> ... >> Security considerations: >> ... >> SVG documents may be transmitted in compressed form using gzip >> compression. For systems which employ MIME-like mechanisms, such >> as HTTP, this is indicated by the Content-Encoding or >> Transfer-Encoding header, as appropriate; for systems which do >> not, such as direct filesystem access, this is indicated by the >> filename extension and by the Macintosh File Type Codes. In >> addition, gzip compressed content is readily recognised by the >> initial byte sequence as described in [RFC1952] section 2.3.1. >> ... JR> 1) What does this have to do with "Security Considerations"? Please read BCP 13, RFC 4288 section 4.6 "Security requirements" where you will find A media type that employs compression may provide an opportunity for sending a small amount of data that, when received and evaluated, expands enormously to consume all of the recipient's resources. All media types SHOULD state whether or not they employ compression, and if they do they should discuss what steps need to be taken to avoid such attacks. JR> 2) I find the whole paragraph misleading; I'd like to see a clear JR> statement about whether the stream of octets resulting from gzipping SVG JR> can be labeled as "image/svg+xml" or not Not by itself, no. In a MIME context, it must be labelled as Content-type: image/svg+xml **AND** Transfer-Encoding: gzip. Please note the AND. This is not the same thing as Content-type: application/octet-stream and Transfer-Encoding: gzip - because that conveys the encoding, but omits the content type. In other words the encoding label ADDS TO the media type; it does not remove the type. Indeed, this is why separate labelling of encoding was added. Back in the early days people would use gzipped VRML or gzipped PostScript, and attempted to register application/gzip; but since they were using the Media Type to hold the encoding information they had lost important information, so VRML viewers were sent PostScript and so on. Some people said this was okay, unzip and then look at the filename extension. But a much better way was to add the encoding headers. JR> (please consider transports JR> other than HTTP, such as a file system that actually supports typing by JR> Internet media types). Please feel free to file a bug report for the BeOS filesystem saying that it should support labelling of encodings in addition to media types. Speaking as a former BeOS user myself, I still consider modern SVG implementations (of which there are many) to be a rather more numerous and relevant consideration than a promising, but obsolete and abandoned, operating system from 15 years ago. JR> If yes, that's a violation of "+xml" (and the last sentence points into JR> this direction). If not, please remove the paragraph above. JR> 3) If the intent is to say that "svgz" acts as file extension for JR> gzipped SVG, and *that* content can be served over HTTP as-is with JR> Content-Type: image/svg+xml JR> Content-Encoding: gzip That is exactly what it says, yes JR> than this is obviously ok I'm glad its obviously OK. JR> because it follows from RFC 2616, and has JR> *nothing* to do with the media type (except for the extension JR> recommendation). So you oppose reminding people how to detect such gzipped content? Why would you want to do that? -- 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 oAIJJZY9083419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 12:19:35 -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 oAIJJZ2g083418; Thu, 18 Nov 2010 12:19:35 -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.23]) by hoffman.proper.com (8.14.4/8.14.3) with SMTP id oAIJJWRA083411 for ; Thu, 18 Nov 2010 12:19:33 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 18 Nov 2010 19:19:30 -0000 Received: from p508FCC1A.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.204.26] by mail.gmx.net (mp003) with SMTP; 18 Nov 2010 20:19:30 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+//OFpiXq/OPDqmKc8sJ+FLwmY5IRZVg90JjHZG6 opXEx5Z8TGk5sQ Message-ID: <4CE57C38.4080307@gmx.de> Date: Thu, 18 Nov 2010 20:19:20 +0100 From: Julian Reschke 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: Chris Lilley CC: ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov Subject: Re: Registration of media typeimage/svg+xml References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> In-Reply-To: <1715145489.20101118190255@w3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 18.11.2010 19:02, Chris Lilley wrote: > ... > Security considerations: > ... > SVG documents may be transmitted in compressed form using gzip > compression. For systems which employ MIME-like mechanisms, such > as HTTP, this is indicated by the Content-Encoding or > Transfer-Encoding header, as appropriate; for systems which do > not, such as direct filesystem access, this is indicated by the > filename extension and by the Macintosh File Type Codes. In > addition, gzip compressed content is readily recognised by the > initial byte sequence as described in [RFC1952] section 2.3.1. > ... 1) What does this have to do with "Security Considerations"? 2) I find the whole paragraph misleading; I'd like to see a clear statement about whether the stream of octets resulting from gzipping SVG can be labeled as "image/svg+xml" or not (please consider transports other than HTTP, such as a file system that actually supports typing by Internet media types). If yes, that's a violation of "+xml" (and the last sentence points into this direction). If not, please remove the paragraph above. 3) If the intent is to say that "svgz" acts as file extension for gzipped SVG, and *that* content can be served over HTTP as-is with Content-Type: image/svg+xml Content-Encoding: gzip than this is obviously ok because it follows from RFC 2616, and has *nothing* to do with the media type (except for the extension recommendation). Best regards, Julian Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAII3YgO079556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 11:03:34 -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 oAII3YTf079555; Thu, 18 Nov 2010 11:03:34 -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 oAII3XZE079548 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 18 Nov 2010 11:03:34 -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 1PJ8pW-0002hT-TY; Thu, 18 Nov 2010 13:03:31 -0500 Date: Thu, 18 Nov 2010 19:02:55 +0100 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1715145489.20101118190255@w3.org> To: Chris Lilley CC: ietf-types@iana.org, ietf-xml-mime@imc.org, Alexey Melnikov Subject: Re: Registration of media typeimage/svg+xml In-Reply-To: <1364503167.20100617162624@w3.org> References: <1364503167.20100617162624@w3.org> 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: This is an updated registration request, incorporating some feedback from Paul Libbrecht , Mark Baker , Henry S. Thompson and Alexey Melnikov . Type name: image Subtype name: svg+xml Required parameters: None. Optional parameters: charset Same as application/xml media type, as specified in [RFC3023] or it's successors. Encoding considerations: Same as for application/xml. See [RFC3023], section 3.2 or it's 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. SVG documents may be transmitted in compressed form using gzip compression. For systems which employ MIME-like mechanisms, such as HTTP, this is indicated by the Content-Encoding or Transfer-Encoding header, as appropriate; for systems which do not, such as direct filesystem access, this is indicated by the filename extension and by the Macintosh File Type Codes. In addition, gzip compressed content is readily recognised by the initial byte sequence as described in [RFC1952] section 2.3.1. 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 this 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: This 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/ 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, svgz (if gzip-compressed) Macintosh file type code(s): "svg " (all lowercase, with a space character as the fourth letter), "svgz" (all lowercase, if gzip-compressed). 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. -- Chris Lilley Technical Director, Interaction Domain W3C Graphics Activity Lead, Fonts Activity Lead Co-Chair, W3C Hypertext CG Member, CSS, WebFonts, SVG Working Groups