Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5OE6q2f064625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jun 2010 07:06:52 -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 o5OE6q2F064624; Thu, 24 Jun 2010 07:06:52 -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 treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5OE6oXV064617 for ; Thu, 24 Jun 2010 07:06:51 -0700 (MST) (envelope-from ht@inf.ed.ac.uk) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id o5OE6d95028359; Thu, 24 Jun 2010 15:06:41 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id o5OE6eV9032010; Thu, 24 Jun 2010 15:06:41 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id o5OE6e1k002583; Thu, 24 Jun 2010 15:06:40 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.13.8/8.13.8/Submit) id o5OE6dfU002582; Thu, 24 Jun 2010 15:06:39 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: ietf-xml-mime@imc.org Cc: public-xml-processing-model-wg@w3.org, public-xml-core-wg@w3.org, www-tag@w3.org, Richard Tobin Subject: XML fragment identifier interpretation From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 24 Jun 2010 15:06:18 +0100 Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o5OE6qXV064619 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Consider the following URI: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.xml#element-key In Firefox 3.6pre, IE8, Chrome 5 and Opera 10, it just works. But there is _no_ justification for this, in 3023 or 3023bis. Why? Because there is no ID with value 'element-key' in the XML document identified by the above URI. It exists _only_ in the output of the XSLT stylesheet named in an xml-stylesheet processing instruction which appears therein. Or so it seems to me. I think we need to add this to the use cases on the table as we consider the TAG's request [1] to think again about generic processing and frag-ids. I'm tempted to say that we need to find a way to allow application-specific frag-id semantics to co-exist with generic semantics. One subsidiary question -- is this or is this not a "same-document reference" [2]? Or, to put it another way, where if anywhere do we find a definitive answer to the question of what the base URI is of the _output_ of an XSLT stylesheet applied in these circumstances? ht [1] http://lists.w3.org/Archives/Public/www-tag/2010Jun/0125.html [2] http://www.apps.ietf.org/rfc/rfc3986.html#sec-4.4 - -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFMI2ZvkjnJixAXWBoRAl2PAJ9idoD6tdM1NYnFmFh9m5re4WySSgCbBn2A KnLZSKkCbdKkd9ELoR1dYPQ= =OOr/ -----END PGP SIGNATURE----- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5IKYT90019646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jun 2010 13:34:29 -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 o5IKYTak019645; Fri, 18 Jun 2010 13:34:29 -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 o5IKYSbw019640 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 18 Jun 2010 13:34:28 -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 1OPiGa-0004Th-Ca; Fri, 18 Jun 2010 16:34:20 -0400 Date: Fri, 18 Jun 2010 19:40:20 +0200 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1687477797.20100618194020@w3.org> To: ht@inf.ed.ac.uk (Henry S. Thompson) CC: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: Registration of media typeimage/svg+xml In-Reply-To: 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: On Friday, June 18, 2010, 5:50:56 PM, Henry wrote: HST> Fragment Identifiers Good point, fragment identifiers. HST> For documents labeled as application/svg+xml, the fragment identifier HST> notation is exactly that for application/xml, as specified in [RFC HST> 3023] or its successors. Except that isn't correct. There is also the SVG view syntax, described at http://dev.w3.org/SVG/profiles/1.1F2/publish/linking.html#LinksIntoSVG -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5IFsRiN001978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jun 2010 08:54: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 o5IFsRSF001977; Fri, 18 Jun 2010 08:54: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 treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5IFsODB001969 for ; Fri, 18 Jun 2010 08:54:26 -0700 (MST) (envelope-from ht@inf.ed.ac.uk) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id o5IFowOe010360; Fri, 18 Jun 2010 16:51:03 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id o5IFovkt006449; Fri, 18 Jun 2010 16:50:57 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id o5IFovn8025309; Fri, 18 Jun 2010 16:50:57 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.13.8/8.13.8/Submit) id o5IFouRo025308; Fri, 18 Jun 2010 16:50:56 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Chris Lilley Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: Registration of media typeimage/svg+xml References: <1364503167.20100617162624@w3.org> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 18 Jun 2010 16:50:56 +0100 In-Reply-To: <1364503167.20100617162624@w3.org> (Chris Lilley's message of "Thu, 17 Jun 2010 16:26:24 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id o5IFsQDB001973 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Suggest you add Fragment Identifiers For documents labeled as application/svg+xml, the fragment identifier notation is exactly that for application/xml, as specified in [RFC 3023] or its successors. ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFMG5XgkjnJixAXWBoRAl1DAJ0XuF73olTb8xL70BtgY8JrPhWwYQCfXe6k zMPNiByMtbaCpm1wJukNvYA= =V9xc -----END PGP SIGNATURE----- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5ICH6pO084364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jun 2010 05:17:06 -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 o5ICH61q084363; Fri, 18 Jun 2010 05:17:06 -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 smtp.dfki.de (lnv-106.sb.dfki.de [134.96.191.147]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5ICH45b084357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Jun 2010 05:17:05 -0700 (MST) (envelope-from paul@activemath.org) Received: from smtp.dfki.de (localhost [127.0.0.1]) by imss.7 (Postfix) with ESMTP id DE5E43181E; Fri, 18 Jun 2010 14:17:03 +0200 (CEST) Received: from mail.dfki.de (lnv-104.sb.dfki.de [134.96.191.146]) by smtp.dfki.de (Postfix) with ESMTP id D009331805; Fri, 18 Jun 2010 14:17:03 +0200 (CEST) Received: from [172.16.19.76] (unknown [172.16.19.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.dfki.de (Postfix) with ESMTPSA id C3BD631161; Fri, 18 Jun 2010 14:17:03 +0200 (CEST) Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Message-Id: From: Paul Libbrecht To: Chris Lilley In-Reply-To: <367626573.20100618125507@w3.org> Content-Type: multipart/signed; boundary=Apple-Mail-7-55996643; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Registration of media typeimage/svg+xml X-Priority: 3 (Normal) Date: Fri, 18 Jun 2010 14:17:03 +0200 References: <1364503167.20100617162624@w3.org> <18AD89DC-6060-4E19-B946-B3CB1B02152F@activemath.org> <367626573.20100618125507@w3.org> X-Mailer: Apple Mail (2.936) Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-7-55996643 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Le 18-juin-10 =E0 12:55, Chris Lilley a =E9crit : > PL> Could I suggest to add in this registration clipboard format =20 > names as > PL> part of the additional information so that applications use them > PL> consistently? > Happy do do so - could you point to documentation on this so I can =20 > read up? There's no official place that I know of. For UTIs, URLs have been a bit changing at Apple, the Wikipedia page =20 seems the most faithful: http://en.wikipedia.org/wiki/Uniform_Type_Identifier and a page at Apple is: = http://developer.apple.com/mac/library/documentation/FileManagement/Concep= tual/understanding_utis/understand_utis_intro/understand_utis_intro.html For Windows the only pages I know of are: .NET: = http://msdn2.microsoft.com/en-us/library/system.windows.dataformats.aspx C++ = http://msdn2.microsoft.com/en-us/library/ms632538.aspx I've been vaguely trying to list these at my page: = http://eds.activemath.org/en/node/161 > Do they require separate registration with some other authority, or =20= > is it sufficient to note them here? =46rom the discussion within the W3C Math Working Group members, it =20 appears that there's no registration methods anymore (people from =20 MicroSoft, Design Science, and MapleSoft among others). One thing I learned the hard way (there was a draft with that error) =20 is that dashes (the minus sign "-") is not allowed in MS clipboard =20 flavor names. Another is that lack of specification gives a broad =20 amount of fancy attempts by just about any implementor. The pages of the platform makers describe how applications register =20 their clipboard types when running or in the application descriptors. As far as I know there's no other thing to do than write this in a =20 spec expected to be read by implementors. > PL> I would suggest the following for uncompressed svg as a first > PL> approximation, but maybe there are existing attempts already? > > PL> - Windows: "SVG Image" > PL> - MacOSX Uniform Type Identifier: org.w3c.svg conforms to =20 > public.image > PL> and to public.xml > > PL> I am doubting that the 4-letter codes are still in use but I may =20= > be > PL> wrong. > > Yes, the old MacOS 4-letter codes are mainly historical at this =20 > point, but Apple did allocate them for us (back in 1998) and RFC =20 > 4288 (from Dec 2005) seems to ask for them if they exist, so they =20 > were included. Perfect then. paul= --Apple-Mail-7-55996643 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDDzCCAwsw ggJ0oAMCAQICECfgYPDm3JFN4mPGdyWyyVgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUyNjA3MzIzNloXDTEwMDUyNjA3MzIz NlowcDEaMBgGA1UEBBMRTGliYnJlY2h0IEdvdXJkZXQxDTALBgNVBCoTBFBhdWwxHzAdBgNVBAMT FlBhdWwgTGliYnJlY2h0IEdvdXJkZXQxIjAgBgkqhkiG9w0BCQEWE3BhdWxAYWN0aXZlbWF0aC5v cmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDeZiQTdNavFBrVY7WMNWscajCzBRZF cWhrkQyh2V0CCrwx7ElHEM0asrD/FbmK+eor0aeav4u/3RKj3qOsV/HV8VRiM2zHaaErrp+/boPw FapmxhPk0TXLceFJAgL5ZA1RsfpcIxGzE/AQ5ic+MqZXp2tZkH6RNeOwoUTURZb2bOZWX5fA1G+L G+IVs20vAN6i/Kdud3JUe9ElfHWfJTl2eO42Hea5MVLnk2IkmCqzxC3CcEchOgOzIrnEjaj/JLPB ZZkDv6sTyEouG4qQHr4trSZCe5anTM2HoPVtmAoaz+Acyt2+0cwIUIPGDjk1K0mvrnCbVIOUNlUe FVJu0svnAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3BhdWxAYWN0aXZlbWF0aC5vcmcwDAYDVR0TAQH/ BAIwADANBgkqhkiG9w0BAQUFAAOBgQDC0P6qlhvM4E2XepLgrDWLj7yp9obwKr2tZBvM3lXGCIyx edzPOMRQABPH3eBbvhKyMb64AoCttJ0vt+QcBLLtc9TkBxPyHyaRHmi4NUMlJJyy1z6pLNc0Ipec U+qv5ck7Cl2SUs7ZQps9ZSW++s4LKKrcdsEs9HD4myt1YusWKTGCAxAwggMMAgEBMHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAn4GDw5tyRTeJjxnclsslYMAkG BSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEw MDYxODEyMTcwNFowIwYJKoZIhvcNAQkEMRYEFLrzEdsJH3kgZ/h0QDXTId2dAf4vMIGFBgkrBgEE AYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQJ+Bg 8ObckU3iY8Z3JbLJWDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQJ+Bg8ObckU3iY8Z3JbLJWDANBgkqhkiG9w0BAQEFAASCAQBV SPU8zpYJQ5WQ+GS7HNv8zkq7E+rQVA6cIh2Z5e4s0GqTNNg5NCRY2oW+eyqIIlzTjcIvLR0Q9L/b ae/E6g6ufwdC7gtoTZtW3s1jidlBWnQ1zVMNE2qvIh7FEbLLCZWliVD7blkd6I/f+bQ5497fdaBw NcmybdM8kUTYZdE/UnkkVmgDW0gQyT55mZ29TREqWEC0qIO06TRSy8t1fhj+Igj0HqpRZ7vbGazp m+wZKFU5f/vIJzMxovhfjCIf8p7V/wg/RMVlGSoROtcEJ7HFvJ6XhtbMUGdwRxPxUb4ltkAV5LKC V8cs5g2P5jTsXXD3PhMfeyjmFCSukqlmniPMAAAAAAAA --Apple-Mail-7-55996643-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5IBkbM1081487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jun 2010 04:46:37 -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 o5IBkbEZ081486; Fri, 18 Jun 2010 04:46:37 -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 o5IBkZL2081476 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 18 Jun 2010 04:46:36 -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 1OPa1n-0003QU-Ub; Fri, 18 Jun 2010 07:46:32 -0400 Date: Fri, 18 Jun 2010 13:46:29 +0200 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1193225174.20100618134629@w3.org> To: Mark Baker CC: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: re: Registration of media type image/svg+xml MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello Mark, I have just sent a registration request for image/svg+xml to ietf-types http://www.alvestrand.no/pipermail/ietf-types/2010-June/002360.html Looking back in the archives I see an old message from you (2005!) which I don't recall answering. http://www.alvestrand.no/pipermail/ietf-types/2005-December/000903.html Some of the points no longer apply to the new registration, some are addressed. I wanted to close the loop with you on that anyway, so that if any of the items you mentioned in 2005 are not addressed to your satisfaction in the new registration, we can get them fixed. > On 12/7/05, Chris Lilley wrote: >> >> Optional parameters: >> None >> >> The encoding of an SVG document shall be determined by the >> XML encoding declaration. This has identical semantics to the >> application/xml media type in the case where the charset >> parameter is omitted, as specified in RFC3023 sections >> 8.9, 8.10 and 8.11. > > Can I assume this section above was supposed to be a replacement for > the encoding section below? For the new registration, that text no longer appears. To answer your question though: no, its one of those unfortunate terminology issues where different terms are used by different communities. What XML calls the 'encoding' or 'character encoding' is what IETF calls the 'charset'. So the section was in the right place and was explaining the lack of a charset parameter. However, the new registration has the optional charset parameter so no longer needs the explanatory prose. >> 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-Transfer-Encoding header; 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. > > I don't see how that's a security issue. Seems more an encoding one to me. I agree it could be described either way, but there have been concerns in the past about triggering compression libraries and potential security concerns due to fixed-length zlib buffers so on balance, we decided to leave that text in there. A secondary reason to mention it was that a few implementations accept uncompressed svg, but fail with compressed svg, or only allow compressed svg when served over http and not from local disk. So it seemed worth mentioning the various ways that compressed svg might be labelled or detected. If you strongly disagree though, and no-one else speaks up in favour of this being worth mentioning in the security section, we are happy to take it out or move it to the encoding section. Should the initial byte sequence of gzipped svg be mentioned under magic numbers? It only shows that the content is gzipped, not that it is svg, so we did not add it there. > On the topic of compression though, I had heard a while ago (back in > the "image/svg-xml" days) that compressed SVG is sometimes sent as > image/svg+xml. Is that still (assuming it was ever) the case? Yes, it is the case. The same media type is used for svg regardless of whether it is compressed or not. For HTTP, other labelling is used to indicate the compression. > The > spec seems to make it clear that SVG is compressed via HTTP > compression. Yes. >> Published specification: >> This media type registration is extracted from Appendix M of >> the SVG 1.2 Tiny specification. >> http://www.w3.org/TR/SVGMobile12 > > There was no "Applications which used this media type" section. I > think it would be useful to say that there are numerous > implementations which currently support this media type. This has been added to the current registration; please check that the language is satisfactory. > Also, you might want to mention - probably in "interoperability" - > that this same media type was also prescribed for use in the SVG 1.0 > and 1.1 specs. And if there are any backward compatibility issues > between 1.2 and those, you might want to say something about that. The current registration is in the context of SVG 1.1, while the old one was for SVG Tiny 1.2 SVG 1.1 obsoletes SVG 1.0 (but SVG 1.0 did use the same media type) The same media type is used for SVG Tiny 1.1, SVG Basic 1.1, and SVG Tiny 1.2. We would be happy to note this in the registration, although the defining specification covers the relationship in much more detail. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5IAwJLm077666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jun 2010 03:58:19 -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 o5IAwJRk077665; Fri, 18 Jun 2010 03:58:19 -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 o5IAwHBe077660 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 18 Jun 2010 03:58:18 -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 1OPZH2-0000kB-DX; Fri, 18 Jun 2010 06:58:12 -0400 Date: Fri, 18 Jun 2010 12:55:07 +0200 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <367626573.20100618125507@w3.org> To: Paul Libbrecht CC: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: Registration of media typeimage/svg+xml In-Reply-To: <18AD89DC-6060-4E19-B946-B3CB1B02152F@activemath.org> References: <1364503167.20100617162624@w3.org> <18AD89DC-6060-4E19-B946-B3CB1B02152F@activemath.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: On Thursday, June 17, 2010, 9:09:32 PM, Paul wrote: PL> Dear Chris, PL> Could I suggest to add in this registration clipboard format names as PL> part of the additional information so that applications use them PL> consistently? Happy do do so - could you point to documentation on this so I can read up? Do they require separate registration with some other authority, or is it sufficient to note them here? PL> I would suggest the following for uncompressed svg as a first PL> approximation, but maybe there are existing attempts already? PL> - Windows: "SVG Image" PL> - MacOSX Uniform Type Identifier: org.w3c.svg conforms to public.image PL> and to public.xml PL> I am doubting that the 4-letter codes are still in use but I may be PL> wrong. Yes, the old MacOS 4-letter codes are mainly historical at this point, but Apple did allocate them for us (back in 1998) and RFC 4288 (from Dec 2005) seems to ask for them if they exist, so they were included. PL> paul >> 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). -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5HJ9g7H029492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2010 12:09:42 -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 o5HJ9g1i029491; Thu, 17 Jun 2010 12:09:42 -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 smtp.dfki.de (lnv-106.sb.dfki.de [134.96.191.147]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5HJ9dwx029482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jun 2010 12:09:41 -0700 (MST) (envelope-from paul@activemath.org) Received: from smtp.dfki.de (localhost [127.0.0.1]) by imss.7 (Postfix) with ESMTP id D705A31A85; Thu, 17 Jun 2010 21:09:37 +0200 (CEST) Received: from mail.dfki.de (lnv-104.sb.dfki.de [134.96.191.146]) by smtp.dfki.de (Postfix) with ESMTP id 71E3831A8C; Thu, 17 Jun 2010 21:09:37 +0200 (CEST) Received: from [192.168.178.47] (srbk-4db7fd10.pool.mediaWays.net [77.183.253.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.dfki.de (Postfix) with ESMTPSA id CFE30310D1; Thu, 17 Jun 2010 21:09:36 +0200 (CEST) Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Message-Id: <18AD89DC-6060-4E19-B946-B3CB1B02152F@activemath.org> From: Paul Libbrecht To: Chris Lilley In-Reply-To: <1364503167.20100617162624@w3.org> Content-Type: multipart/signed; boundary=Apple-Mail-19--5651060; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Registration of media typeimage/svg+xml X-Priority: 3 (Normal) Date: Thu, 17 Jun 2010 21:09:32 +0200 References: <1364503167.20100617162624@w3.org> X-Mailer: Apple Mail (2.936) Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-19--5651060 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear Chris, Could I suggest to add in this registration clipboard format names as part of the additional information so that applications use them consistently? I would suggest the following for uncompressed svg as a first approximation, but maybe there are existing attempts already? - Windows: "SVG Image" - MacOSX Uniform Type Identifier: org.w3c.svg conforms to public.image and to public.xml I am doubting that the 4-letter codes are still in use but I may be wrong. paul > 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). > --Apple-Mail-19--5651060 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDDzCCAwsw ggJ0oAMCAQICECfgYPDm3JFN4mPGdyWyyVgwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUyNjA3MzIzNloXDTEwMDUyNjA3MzIz NlowcDEaMBgGA1UEBBMRTGliYnJlY2h0IEdvdXJkZXQxDTALBgNVBCoTBFBhdWwxHzAdBgNVBAMT FlBhdWwgTGliYnJlY2h0IEdvdXJkZXQxIjAgBgkqhkiG9w0BCQEWE3BhdWxAYWN0aXZlbWF0aC5v cmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDeZiQTdNavFBrVY7WMNWscajCzBRZF cWhrkQyh2V0CCrwx7ElHEM0asrD/FbmK+eor0aeav4u/3RKj3qOsV/HV8VRiM2zHaaErrp+/boPw FapmxhPk0TXLceFJAgL5ZA1RsfpcIxGzE/AQ5ic+MqZXp2tZkH6RNeOwoUTURZb2bOZWX5fA1G+L G+IVs20vAN6i/Kdud3JUe9ElfHWfJTl2eO42Hea5MVLnk2IkmCqzxC3CcEchOgOzIrnEjaj/JLPB ZZkDv6sTyEouG4qQHr4trSZCe5anTM2HoPVtmAoaz+Acyt2+0cwIUIPGDjk1K0mvrnCbVIOUNlUe FVJu0svnAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3BhdWxAYWN0aXZlbWF0aC5vcmcwDAYDVR0TAQH/ BAIwADANBgkqhkiG9w0BAQUFAAOBgQDC0P6qlhvM4E2XepLgrDWLj7yp9obwKr2tZBvM3lXGCIyx edzPOMRQABPH3eBbvhKyMb64AoCttJ0vt+QcBLLtc9TkBxPyHyaRHmi4NUMlJJyy1z6pLNc0Ipec U+qv5ck7Cl2SUs7ZQps9ZSW++s4LKKrcdsEs9HD4myt1YusWKTGCAxAwggMMAgEBMHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAn4GDw5tyRTeJjxnclsslYMAkG BSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEw MDYxNzE5MDkzMlowIwYJKoZIhvcNAQkEMRYEFJiNm8IDlUDS6X0LotNrd0oggfqxMIGFBgkrBgEE AYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQJ+Bg 8ObckU3iY8Z3JbLJWDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQJ+Bg8ObckU3iY8Z3JbLJWDANBgkqhkiG9w0BAQEFAASCAQAL 2x/w6e5JRzgFkM4I+/oUFtz7uSeFQ1lFOo3znSMJyfk18u9dLugA63meZ0riuo3UkPtOn038UfXx 5tlv3APoJONg2ZMB9qasruo8H5nmVCBg0c368MFYcs/2VyoWFOlWXvayVxWWg7JxtefbM2xXzI3G 7lh0sBck3ruVAZZtFggIHPA0fSOoqf8m01JbMnCwB7y/7shOHNltK6KMjAgn0Cpoq0uV8i0i6U0O M6iD2EKKDvuf56Sf/zwuLPK98VcZYLDWE3zMN5PX8ZYdxoMZigdpnuRSfKGkYhBJuaahbAZYJXW8 5hJjZ9NikICezjU/UqykbQAHDES+Nmlu6q8KAAAAAAAA --Apple-Mail-19--5651060-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5HERHGN010543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2010 07:27:17 -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 o5HERH3a010542; Thu, 17 Jun 2010 07:27: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 jay.w3.org (ssh.w3.org [128.30.52.60]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5HERFDY010537 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jun 2010 07:27:16 -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 1OPG3l-0006Lc-TF; Thu, 17 Jun 2010 10:27:14 -0400 Date: Thu, 17 Jun 2010 16:26:24 +0200 From: Chris Lilley X-Mailer: The Bat! (v3.95.6) Home Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1364503167.20100617162624@w3.org> To: ietf-types@iana.org CC: ietf-xml-mime@imc.org Subject: Registration of media typeimage/svg+xml MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 successor. Encoding considerations: Same as for application/xml. See RFC3023, section 3.2. 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-Transfer-Encoding header; 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 recognized 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://dev.w3.org/SVG/profiles/1.1F2/publish/mimereg.html http://dev.w3.org/SVG/profiles/1.1F2/publish/index.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, 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). 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 mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG