Registration of media typeimage/svg+xml

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

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).

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

Le 18-juin-10 à 12:55, Chris Lilley a écrit :
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?
There's no official place that I know of. For UTIs, URLs have been a bit changing at Apple, the Wikipedia page 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/Conceptu... 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 is it sufficient to note them here?
From the discussion within the W3C Math Working Group members, it appears that there's no registration methods anymore (people from MicroSoft, Design Science, and MapleSoft among others). One thing I learned the hard way (there was a draft with that error) is that dashes (the minus sign "-") is not allowed in MS clipboard flavor names. Another is that lack of specification gives a broad amount of fancy attempts by just about any implementor. The pages of the platform makers describe how applications register 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 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 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.
Perfect then. paul

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? Paul, I have updated the registration template on the editors draft for SVG 1.1 second edition, incorporating your suggestion. http://dev.w3.org/SVG/profiles/1.1F2/publish/mimereg.html Please have a look and tell me if its ok. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

-----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-----
participants (3)
-
Chris Lilley
-
ht@inf.ed.ac.uk
-
Paul Libbrecht