December 2005 - Ietf-types

Request for review of 9 MIME type for 3GPP SA4
by Magnus Westerlund 29 Mar '07

29 Mar '07

Hi, attached is a word document with a proposal for 9 MIME type that will go into the 3GPP Technical Specification 26.346 and when present in that be requested to registered. Most of these media types are for XML formats, although not all of them. Please review them, comments received within a week can be directly addressed at the 3GPP SA4 meeting. TS 26.346 can in its latest form be fetched here: http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-610.zip However some of the references in the chapter relate to text that are being specified and added. They are available in the following document: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050514.zip Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

3 8

W3C Last Call and Media Type request for comments: XQuery and XQueryX
by Liam Quin 18 Jan '07

18 Jan '07

[ Notes: (1) - I'm trying to follow a new procedure here. Becasue not everything is in place, the documents I refer to probably don't have perfect wording. The documentation on the process was released after the documents were frozen for Last Call, but we can make any needed changes for the next round of publication. I see that we failed to define the correct syntax for parameters, and would welcome comments on any other areas wheer we need to improve. (2) The following text will be inserted in the next published versions of the documents: This registration is for community review and will be (or has been) submitted to the IESG for review, approval, and registration with IANA. (3) We are using Bugzilla to track comments on these documents; comments on these MIME-related pats of the documents may be made on the ietf-types mailing list or in Bugzilla. See the individual documents and their respective "Status of this Document" sections for further information. - Liam ] In accordance with the draft Media Type Specifications and Registration Procedures [1], and on behalf of the W3C XML Query Working Group [2], I hereby give notice that W3C has published two specifications at the stage "Last Call Working Draft" which each incorporate definitions of a standards-tree MIME media type, as allowed for in section 3.1 of [1], and request comments on these definitions. The types and subtypes are application/xquery defined in "XQuery 1.0: An XML Query Language" [3] optional parameter: charset application/xquery+xml defined in "XML Syntax for XQuery 1.0 (XQueryX)" [4] optional parameter: charset **** Registration for application/xquery also at [3] I The application/xquery Media Type (Non-Normative) --------------------------------------------------- This Appendix specifies the media type for XQuery Version 1.0. XQuery is a language for querying over collections of data from XML data sources, as specified in the main body of this document. I.1 Introduction ---------------- This document, together with its normative references, defines the language XQuery Version 1.0. This Appendix provides information about the application/xquery media type, which is intended to be used for transmitting queries written in the XQuery language. This document was prepared by members of the W3C XML Query Working Group. Please send comments to public-qt-comments [at] w3.org, a public mailing list with archives at http://lists.w3.org/Archives/Public/public-qt-comments. I.2 Registration of MIME Media Type application/xquery ------------------------------------------------------ MIME media type name: application MIME subtype name: xquery Required parameters: none Optional parameters: charset The syntax of XQuery is expressed in Unicode but may be written with any Unicode-compatible character encoding, including UTF-8 or UTF-16, or transported as US-ASCII or Latin-1 with Unicode characters outside the range of the given encoding represented using an XML-style ෝ syntax. I.2.1 Interoperability Considerations None known. I.2.2 Applications Using this Media Type The public XQuery Web page lists more than two dozen implementations of the XQuery language, both proprietary and open source. This new media type is being registered to allow for deployment of XQuery on the World Wide Web. I.2.3 File Extensions The most common file extensions in use for XQuery are .xq and .xquery. The appropriate Macintosh file type code is TEXT. I.2.4 Intended Usage The intended usage of this media type is for interchange of XQuery expressions. I.2.5 Author/Change Controller XQuery was produced by, and is maintained by, the World Wide Web Consortium's XML Query Working Group. The W3C has change control over this specification. I.3 Encoding Considerations For use with transports that are not 8-bit clean, quoted-printable encoding is recommended since the XQuery syntax itself uses the US-ASCII-compatible subset of Unicode. An XQuery document may contain an encoding declaration as part of its version declaration: xquery version "1.0" encoding "utf-8"; If an XQuery document contains an encoding declaration, it overrides the default encoding specified by the MIME charset parameter. I.4 Recognizing XQuery Files An XQuery file may have the string xquery version "V.V" near the beginning of the document, where "V.V" is a version number. Currently the version number, if present, must be "1.0". I.5 Charset Default Rules XQuery documents use the Unicode character set and, by default, the UTF-8 encoding. I.6 Security Considerations Queries written in XQuery may cause arbitrary URIs to be dereferenced. Therefore, the security issues of [Uniform Resource Locators (URL)] Section 6 should be considered. In addition, the contents of file: URIs can in some cases be accessed, processed and returned as results. Furthermore, because the XQuery language permits extensions, it is possible that application/xquery may describe content that has security implications beyond those described here. The XML Query Working group is working on a facility to allow XQuery expressions to be used to create and update persistent data. Untrusted queries should not be given write access to data. **** Registration for application/xquery+xml also at [4] C The application/xquery+xml Media Type (Non-Normative) ------------------------------------------------------- This Appendix specifies the media type for XQueryX Version 1.0. XQueryX is the XML syntax of a language, XQuery, for querying over data from XML data sources, as specified in [XQuery 1.0: An XML Query Language]. C.1 Introduction ---------------- This document, together with its normative references, defines the XML syntax for the XML Query language XQuery Version 1.0. This Appendix specifies the application/xquery+xml media type, which is intended to be used for transmitting queries expressed in the XQueryX syntax. This document was prepared by members of the W3C XML Query Working Group. Please send comments to public-qt-comments [at] w3.org, a public mailing list with archives at http://lists.w3.org/Archives/Public/public-qt-comments. C.2 Registration of MIME Media Type application/xquery+xml MIME media type name: application MIME subtype name: xquery+xml Required parameters: none Optional parameters: charset This parameter has identical semantics to the charset parameter of the application/xml media type as specified in [RFC3023]. C.2.1 Encoding Considerations The considerations as specified in RFC 3023 [XMLMIME] also hold for 'application/xquery+xml'. C.2.2 Fragment Identifiers For documents labeled as 'application/xquery+xml', fragment identifiers are handled as specified in RFC 3023 [XMLMIME]. C.2.3 Restrictions on usage The intended usage of this media type is for interchange of XQueryX expressions. C.2.4 Security Considerations Queries written in XQueryX may cause arbitrary URIs to be dereferenced. Therefore, the security issues of [Uniform Resource Locators (URL)] Section 6 should be considered. In addition, the contents of file: URIs can in some cases be accessed, processed and returned as results. Furthermore, because the XQuery language (and thus the XQueryX language) permits extensions, it is possible that application/xquery+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 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 arise. The XML Query Working group is working on a facility to allow XQuery (and thus XQueryX) expressions to be used to create and update persistent data. Untrusted queries should not be given write access to data. C.2.5 Interoperability Considerations See Section 5 ConformanceXQ. C.2.6 Applications That Use This Media Type The public XQuery Web page lists more than two dozen implementations of the XQuery language, both proprietary and open source. Some of these are known to support XQueryX. This new media type is being registered to allow for deployment of XQueryX on the World Wide Web. There is no experimental, vendor specific, or personal tree predecessor to "application/xquery+xml", reflecting the fact that no applications currently recognize it. This new type is being registered in order to allow for the expected deployment of XQueryX 1.0 on the World Wide Web, as a first class XML application. C.2.7 Additional Information C.2.7.1 Recognizing XQuery Files ("Magic Numbers") Although no byte sequences can be counted on to consistently identify XQueryX, XQueryX documents will have the sequence "http://www.w3.org/yyyy/mm/XQueryX" to identify the XQueryX namespace (where "yyyy" is exactly four decimal digits and "mm" is exactly two decimal digits). This sequence will normally be found in a namespace attribute of the first element in the document. C.2.7.2 File Extensions The most common file extension in use for XQueryX is .xqx. C.2.7.3 Macintosh File Type Code(s) The appropriate Macintosh file type code is TEXT. C.2.8 Person and Email Address to Contact For Further Information Jim Melton, Oracle Corp., jim.melton [at] oracle.com C.2.9 Intended Usage COMMON C.2.10 Author/Change Controller XQuery was produced by, and is maintained by, the World Wide Web Consortium's XML Query Working Group. The W3C has change control over this specification. [1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-02.txt [2] http://www.w3.org/XML/Query [3] http://www.w3.org/TR/2005/WD-xquery-20050404/#id-mime-type [4] http://www.w3.org/TR/2005/WD-xqueryx-20050404/#xqueryx-id-mime-type -- Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/ http://www.holoweb.net/~liam/

8 16

Registration of media type application/sparql-query
by Eric Prud'hommeaux 09 Mar '06

09 Mar '06

see also http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/mime.txt Type name: application Subtype name: sparql-query Required parameters: None Optional parameters: None Encoding considerations: The syntax of the SPARQL Query Language is expressed over code points in Unicode[UNICODE 3.0]. The encoding is always UTF-8 [RFC3629]. Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] Security considerations: SPARQL queries using FROM, FROM NAMED, or GRAPH may cause the specified URI to be dereferenced. This may cause additional use of network, disk or CPU resources along with associated secondary issues such as denial of service. The security issues of Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7 should be considered. In addition, the contents of file: URIs can in some cases be accessed, processed and returned as results, providing unintended access to local resources. The SPARQL language permits extensions, which will have their own security implications. Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "o" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Users of SPARQL must take care to construct queries with IRIs that match the IRIs in the data. Further information about matching of similar characters can be found in Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8. Interoperability considerations: There are no known interoperability issues. Published specification: This specification. Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): A SPARQL query may have the string 'PREFIX' (case independent) near the beginning of the document. File extension(s): ".rq" Base URI: The SPARQL 'BASE <IRIref>' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: public-rdf-dawg-comments(a)w3.org Intended usage: COMMON Restrictions on usage: None Author/Change controller: The SPARQL specification is a work product of the World Wide Web Consortium's RDF Data Access Working Group. The W3C has change control over these specifications. Normative References [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3629] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [UNICODE3.0] "The Unicode Standard Version 3.0", Addison Wesley, Reading, MA, ISBN 0-201-61633-5, August 2000. http://www.unicode.org/unicode/standard/standard.html. [UNISEC] Mark Davis, Michel Suignard, "Unicode Security Considerations. http://www.unicode.org/reports/tr36/ -- -eric office: +81.466.49.1170 W3C, Keio Research Institute at SFC, Shonan Fujisawa Campus, Keio University, 5322 Endo, Fujisawa, Kanagawa 252-8520 JAPAN +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA cell: +81.90.6533.3882 (eric(a)w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.

1 1

Registration of media type application/sparql-results+xml
by Eric Prud'hommeaux 09 Mar '06

09 Mar '06

see also http://www.w3.org/2005/11/sparql-results%2Bxml.txt Type name: application Subtype name: sparql-results+xml Required parameters: None Optional parameters: "charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023], section 3.2. Encoding considerations: Identical to those of "application/xml" as specified in [RFC3023], section 3.2. Security considerations: SPARQL query results uses URIs. See Section 7 of [RFC3986]. SPARQL query results uses IRIs. See Section 8 of [RFC3987]. As this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], section 10. Interoperability considerations: There are no known interoperability issues. Published specification: This specification. Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): As specified for "application/xml" in [RFC3023], section 3.2. File extension(s): ".srx" Fragment identifiers: Identical to that of "application/xml" as described in RFC 3023 [RFC3023], section 5. Base URI: As specified in [RFC3023], section 6. Macintosh file type code(s): "TEXT" Person & email address to contact for further information: Eric Prud'hommeaux <public-rdf-dawg-comments(a)w3.org> Intended usage: COMMON Restrictions on usage: None Author/Change controller: The SPARQL specification is a work product of the World Wide Web Consortium's RDF Data Access Working Group. The W3C has change control over these specifications. References [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. -- -eric office: +81.466.49.1170 W3C, Keio Research Institute at SFC, Shonan Fujisawa Campus, Keio University, 5322 Endo, Fujisawa, Kanagawa 252-8520 JAPAN +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA cell: +81.90.6533.3882 (eric(a)w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.

1 1

video/vnd.avi and audio/vnd.wave media types
by Bjoern Hoehrmann 21 Dec '05

21 Dec '05

Hi, It seems http://www.iana.org/assignments/media-types/video/ and http://www.iana.org/assignments/media-types/audio/ lack the types for which RFC 2361 established the codec registry, video/vnd.avi and audio/vnd.wave. I think they should be added with reference to RFC 2361 (http://www.rfc-editor.org/rfc/rfc2361.txt) regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

1 0

Registration of media type image/svg+xml
by Chris Lilley 20 Dec '05

20 Dec '05

Hello ietf-types, The SVG WG requests feedback on its standards tree media type registration for image/svg+xml: http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/mimereg.html M.1 Introduction This appendix registers a new MIME media type, "image/svg+xml" in conformance with RegMedia and W3CRegMedia. http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt http://www.w3.org/2002/06/registering-mediatype.html M.2 Registration of Media Type image/svg+xml MIME media type name: image MIME subtype name: svg+xml Required parameters: None. 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. Encoding considerations: Same as for application/xml. See RFC3023, section 3.2. Restrictions on usage: None 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 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 M of the SVG 1.2 Tiny specification. http://www.w3.org/TR/SVGMobile12 Additional information: Person & email address to contact for further information: Dean Jackson, Chris Lilley (member-svg-media-type(a)w3.org) Intended usage: COMMON Author/Change controller: The SVG specification is a work product of the World Wide Web Consortium's SVG Working Group. The W3C has change control over these specifications. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

4 5

Review of DLS media type
by Magnus Westerlund 14 Dec '05

14 Dec '05

Hi, I would like to request review of the DLS media type documented in: http://www.ietf.org/internet-drafts/draft-westerlund-mime-dls-00.txt Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

2 2

Problem with IANA MIME media types registry
by Bruce Lilly 13 Dec '05

13 Dec '05

[CC'd to IETF discussion list and ietf-types discussion list] Hello, Recent changes to the page at http://www.iana.org/assignments/media-types/index.html accessed via the link from the IANA Assigned numbers page http://www.iana.org/numbers.html#M have rendered the registry of assigned media types useless. Prior to the recent change, the media types registry listed the assigned MIME top-level media types, viz. application, audio, image, message, model, multipart, text, and video. Since the change, only the application top-level type is listed (audio, image, message, model, multipart, text, and video have vanished without a trace) and superfluous repetition of the application subtypes listed in http://www.iana.org/assignments/media-types/application has appeared (these of course are not top-level media types). Could you please investigate what has gone awry and regenerate a page that provides top-level media types.

3 3

FW: [blilly@erols.com: Re: Problem with IANA MIME media types registry]
by Michelle Cotton 13 Dec '05

13 Dec '05

Bruce, This has been fixed. The index file was accidentally overwritten with the application media types page. Thank you for letting us know. Best regards, Michelle Cotton IANA ----- Forwarded message from Bruce Lilly <blilly(a)erols.com> ----- Date: Sun, 11 Dec 2005 10:42:22 -0500 Subject: Re: Problem with IANA MIME media types registry From: Bruce Lilly <blilly(a)erols.com> To: mankin(a)psg.com Cc: iana(a)iana.org, webmaster(a)iana.org, ietf(a)ietf.org, ietf-types(a)alvestrand.no On Sun December 11 2005 10:06, Allison Mankin wrote: > Bruce, > > FYI, the other top-level media types are still there on their > FTP site, so this looks like something went wrong with their web > generating approach, whatever that is... > > ftp://ftp.iana.org/assignments/media-types/ > > Allison > > P.S. I happened to have the FTP version on my radar. Thanks for the information -- the index.html file at the ftp site has a revision date of 23-Aug-2005, whereas the file served via HTTP is dated 30-November-2005. I would have expected the same file to be served by both protocols, with index.html being the default for HTTP. That that is evidently not happening is yet another cause for concern, as it means that different access methods yield different registration information. Possibly the IANA HTTP server is sending the application data (only) instead of index.html. I've taken the liberty of copying the lists and IANA to update the information regarding the registry. Best regards, Bruce Lilly _______________________________________________ Ietf mailing list Ietf(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf ----- End forwarded message ----- -- Kent Crispin kent(a)icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent(a)songbird.com SIP: 81202(a)fwd.pulver.com

1 0

Transport Area requests Media Type review of draft-ietf-avt-ulp-14.txt
by Allison Mankin 12 Dec '05

12 Dec '05

The Transport Area requests a Media Type review for the four proposed new media types, intended for the IETF tree, which are in the document, draft-ietf-avt-ulp-14.txt, intended for Proposed Standard. The types are audio/ulpfec, video/ulpfec, text/ulpfec and application/ulpfec This document takes as its normative base RFC 3555 and the now approved and operative updated Media Types Registration document, draft-freed-media-type-reg-05.txt Please provide any comments before 5 January 2006. Thanks, Allison

1 0