April 2005 - Ietf-types

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

Re: regarding your comments on proposed media type text/troff' to Informational RFC
by Keith Moore 02 May '05

02 May '05

[cc'ed to ietf-types list, which per RFC 2048 is where this document should be reviewed.] Bruce, I raise this concern both because this was something that was discussed extensively in the ietf-822 working group that created MIME, and also because we've seen far too many security holes result from giving the sender a way to choose what program to run on the recipient's system (usually by ignoring the content-type parameter and paying attention to the application-specific filename suffix). Even if we don't think troff will be used much, it sets a bad precedent to allow a new content-type to specify something that we have ample experience to indicate it's harmful. RFC 2046 (section 4.5.1) even includes the following language, which also appeared in RFCs 1341 and 1521: > To reduce the danger of transmitting rogue programs, it is strongly > recommended that implementations NOT implement a path-search > mechanism whereby an arbitrary program named in the Content-Type > parameter (e.g., an "interpreter=" parameter) is found and executed > using the message body as input. now this is in a section related to the application/octet-stream content-type, but the principle is the same - if you let the sender choose what programs should be used to process the input, the content-type label is effectively ignored. And the only difference between an "interpreter" parameter and a "process" parameter is that you're not only letting the sender specify the interpreter, you're letting him specify the entire command line! I don't think it matters much if you say "don't directly execute the process parameter" because the very purpose of the process parameter is to tell the sender exactly what to type, and to allow the sender to specify arbitrary preprocessing programs and arbitrary parameters to those programs. Maybe recipients should know better than type arbitrary commands specified by the sender, but there's ample experience to suggest that most recipients don't have that kind of expertise. Nor am I persuaded by the "sender must specify the order of preprocessing" argument, as groff has options to specify which of several preprocessors to use, and it seems to work fine. The Version 7 UNIX versions of these tools (circa 1979) described in the "CSTR 49" document you cite had several limitations (many related to having to run in 64k of code space on a pdp 11/70), that don't apply to modern troff implementations. -Keith On Apr 14, 2005, at 9:45 AM, Bruce Lilly wrote: >> From: Keith Moore [mailto:moore@cs.utk.edu] >> Sent: Tuesday, April 12, 2005 4:14 PM >> To: iesg(a)ietf.org >> Cc: moore(a)cs.utk.edu >> Subject: Re: Last Call: 'Media subtype registration for media type >> text/troff' to Informational RFC > > Keith, > > Thanks for taking the time to review and comment on the draft. > > Before addressing your comments in detail, I would like to make some > observations about troff source, text formatting, and MIME mechanisms: > > o some documents might be text only, others might include equations, > tables, graphs, line drawings, etc. Complex documents might include > equations within tables (CSTR 49), equations within line drawings > (CSTR 114), and/or equations within graphs (CSTR 116), to name but a > few possible combinations. Preprocessor order is dependent on such > document structure (as noted in CSTR 49); it is insufficient to know > which preprocessors to use, the order is critically important. > > o many preprocessors take command line arguments; one needs to know > not only which preprocessors to use, and in which order, but also > which command line arguments to supply to each preprocessor, and > in some cases the order of arguments matters. > > o troff provides a comment mechanism (as do most preprocessors); that > could be used (as noted in the draft) to convey human-readable > document processing instructions. > > o MIME provides for packaging related content (multipart/related > composite media type), so separate processing instructions (e.g. > in a Makefile) could be packaged with document source. > >> I recommend against publication of this document as an RFC, >> unless and until it is revised to fix the following problem: >> >> section 4: >> >> the process parameter appears to be a security hole, as it would >> allow the sender to specify commands to be executed on the recipient's >> system. while this is documented in the security considerations >> section, >> it is unnecessary, and long experience with implementations that >> provide >> similar capability (e.g. the ability to launch an arbitrary >> application >> based on the file name suffix) indicates that significant harm can >> come >> from allowing the sender of a message to specify actions to be taken >> by the recipient's MUA. > > The intent of the "process" parameter is to provide a uniform mechanism > (vs. ad-hoc source comments or packaging of separate instructions) for > communicating formatting instructions from the human author to a human > recipient. Automated execution is strongly recommended against (I > could > of course make that a "MUST NOT", but I am skeptical of the value of > RFC > 2119 language in an Informational RFC and I am uncertain of the > implications for non-MIME contexts (N.B. the registration procedure is > being separated from MIME)). Publication as a Standards Track RFC > rather > than Informational might address the RFC 2119 language issue (I'm > uncertain of what the procedural implications would be at this point). > >> furthermore the process parameter is unlikely to be used by the >> recipient >> _unless_ its handling is automated, because most MUAs do not make it >> easy >> to see the content-type parameters associated with an attachment. so >> the parameter as defined is more likely to do harm than good, and >> it would set a bad precedent for other content-type definitions. > > Handling should rarely, if ever, be fully automatic. In this specific > case, handling could involve presentation of the recommended processing > command line to a user for review and modification, with execution of > the possibly-modified command line only upon user approval. That's > what I had in mind. I could add text to that effect as an example of > appropriate use of the parameter, but I am wary of delving too far into > implementation details, particularly as this is a media type > registration > and not a specification for particular types of human interfaces. > >> if anything I would make the process parameter a list of keywords: >> pic, eqn, tbl, etc. the keywords should not be treated as commands >> by the recipient's system (and certainly should not be looked up in >> the >> recipient's PATH), but rather as flags to be passed to a processor >> such >> as groff that knows where to find these programs and in what order >> they >> should be run. > > A mere list doesn't indicate ordering. Keywords alone don't provide > indication of (preprocessor/formatter) arguments. Groff (specifically > "grog"): > a) isn't universally available > b) guesses wrong. Example on the source for the draft under discussion: > marty:/data/information/RFCs/text-troff # grog dr*2.df > groff -p -ms draft-lilly-text-troff-02.df > That indicates pic but not dformat, and indicates the ms macro > package, which is incorrect. > The author presumably knows the necessary processing steps; an expert > recipient might be able to figure out processing steps. A standard > mechanism for conveying knowledge from the author to recipient avoids > trial-and-error guesswork, and that's the intent of the optional > "process" parameter. Because the parameter is optional, a sender > always has the option of omitting it. > >> there is also a need to specify what macro package is used: e.g. >> -ms, -me, etc. > > I chose command-line syntax for the process parameter as it is capable > of concisely and unambiguously indicating the necessary information: > > o preprocessors, formatters, and postprocessors required > > o preprocessor, formatter, and postprocessor arguments > > o order of preprocessor invocation > >> actually the varied handling of troff (and TeX) documents is probably >> the reason we never defined a content-type for either of these. > > Yes, the richness of the type is unique; I know of no other media types > that are as flexible, and that poses some challenges for specification. > >> we >> certainly considered doing so at the time the MIME documents were >> being >> written, and we used these file formats as examples of content which, >> when interpreted on a recipient's system, could cause security >> breaches. > > Almost all media types (including plain text, as noted in the draft > w.r.t. > control characters) have security issues. I think the issues with > troff > source have been reasonably addressed in the draft; compare for example > to the approved registration for type application/msword. > >> Keith > > Would clarification of the recommendation against automated processing > and an example of appropriate handling of the "process" parameter > (either with or w/o "MUST NOT") address your objections? > > Best regards, > Bruce Lilly

4 21

MIME media types in RFC 4047
by Steve Allen 30 Apr '05

30 Apr '05

We have been informed that RFC 4047 is published. RFC 4047 defines two new top-level MIME media types: image/fits application/fits The IANA web pages http://www.iana.org/assignments/media-types/application/ http://www.iana.org/assignments/media-types/image/ have not been updated to indicate that publication has occurred. Do the authors of the RFC need to make any further explicit request to the IANA, or should we simply await the next update? -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla(a)ucolick.org Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93

2 1

Request for comments regarding draft-mccobb-xplusv-media-type-01
by Gerald McCobb 21 Apr '05

21 Apr '05

This is a request for comments regarding the internet draft draft-mccobb-xplusv-media-type-01 for media type "application/xhtml+voice+xml". This media type is for XHTML+Voice documents. The XHTML+Voice specification is located at http://www.voicexml.org/specs/multimodal/x+v/12/ . Network Working Group G. McCobb Internet-Draft IBM Corporation Expires: May 15, 2005 Nov. 15, 2004 XHTML+Voice - application/xhtml+voice+xml draft-mccobb-xplusv-media-type-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved Abstract This document describes the registration of the MIME sub-type application/xhtml+voice+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents. The XHTML+Voice 1.2 language specification is maintained by the VoiceXML Forum at <http://www.voicexml.org/specs/multimodal/x+v/12/>. 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [REQ]. Mccobb Expires May 15, 2005 [Page 1] Internet-Draft XHTML+Voice - application/xhtml+voice+xml Nov. 15, 2004 2. Introduction XHTML+VOice is a member of the XHTML family of document types, as specified by XHTML Modularization. XHTML+Voice extends XHTML 1.1 [XHTML11] with a modularized subset of VoiceXML 2.0 [VXML20], XML Events [XMLEVNTS], and a few extensions to both XHTML and VoiceXML 2.0. XHTML 1.1, VoiceXML 2.0 and XML Events are W3C Recommendations. The language integration defined by XHTML+Voice supports all modules defined by XHTML Modularization, and adds voice interaction to XHTML elements to enable multimodal applications. The defined document type for XHTML+VOice is XHTML Host language document type conformant. XHTML+Voice 1.2 [XPLUSV12] is maintained by the VoiceXML Forum, at URI location <http://www.voicexml.org/specs/multimodal/x+v/12/>. 2.1 application/xhtml+voice+xml Usage The application/xhtml+voice+xml media type is intended to be a media descriptor for XHTML+Voice documents. This media type registration is not intended for email usage. 3. IANA Registration To: ietf-types(a)iana.org Subject: Registration of Standard MIME media type application/xhtml+voice+xml MIME media type name: application MIME subtype name: xhtml+voice+xml Required parameters: none Optional parameters: version: refers to the XHTML+Voice language version in the document. Acceptable values are 1.0, 1.1, and 1.2 (default). charset: has the same meaning as the text/html media type. See section 2 of [RFC 2854]. Encoding considerations: 7bit. See section 4 of [RFC 2854]. Security considerations: XHTML+Voice is an extension of XHTML and has the same security issues as XHTML. These include interpreting anchors and forms in HTML Mccobb Expires May 15, 2005 [Page 2] Internet-Draft XHTML+Voice - application/xhtml+voice+xml Nov. 15, 2004 documents, and scripting languages and other dynamic interactive capabilities. See section 7 of [RFC 2854]. Interoperability considerations : Because XHTML+Voice is built upon W3C standard recommendations, it is designed to be interoperable across a wide range of platforms and client devices. Because the extensions to XHTML are identified by their namespaces, all browsers that have namespace support can run an XHTML+Voice document as an XHTML document without voice interaction. Published specification: The latest published version of XHTML+Voice is [XPLUSV12]. Applications which use this media type: XHTML+Voice documents are intended to be deployed on the World Wide Web and rendered by multimodal browsers that support the visual and voice modes of interaction. See section 2 of [RFC 2854]. Additional information: Magic number(s): There is no single string that is always present. File extension(s): html, htm, mxml, xvml Macintosh File Type Code(s): TEXT Person & email address to contact for further information: Gerald M. McCobb mccobb(a)us.ibm.com Intended usage: COMMON Author/Change controller: Gerald McCobb Further information: 4. Fragment Identifiers See section 3 of [RFC 2854]. 5. Recognizing XHTML+Voice files Because XHTML+Voice is XML, an XHTML+Voice document [optionally] starts with an XML declaration which begins with "<?xml" and has a DOCTYPE declaration "<!DOCTYPE html". XHTML+Voice 1.2 has the Mccobb Expires May 15, 2005 [Page 3] Internet-Draft XHTML+Voice - application/xhtml+voice+xml Nov. 15, 2004 following DOCTYPE declaration: <!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN" "http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd"> Because XHTML+Voice is in the XHTML family of languages, the root element of an XHTML+Voice document is 'html' and '<html' can be found near the top of the document. 6. Security Considerations Security considerations for this media type are discussed in the MIME type registration that appears in section 4. 7. References [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [DOM2EV] "Document Object Model Level 2 Events Specification," Tom Pixley, 2000. W3C Recommendation, http://www.w3.org/TR/DOM-Level-2-Events/. [HTML401] Raggett, D., et al., "HTML 4.01 Specification", W3C Recommendation, December 1999. Available at <http://www.w3.org/TR/html401>. [MIME4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [RFC 2854] RFC 2854: The 'text/html' Media Type, Connolly and Masinter, June 2000, http://www.ietf.org/rfc/rfc2854.txt. [XHTMLMOD] "Modularization of XHTML," 10 April, 2001, Murray Altheim, Frank Boumphrey, Sam Dooley, et al, W3C Recommendation, http://www.w3.org/TR/xhtml-modularization/ [XHTML1] "XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", W3C Recommendation, January 2000. Available at <http://www.w3.org/TR/xhtml1>. [XHTML11] "XHTML 1.1 - Module-based XHTML," 31 May 2001, Murray Altheim, Shane McCarron, W3C Recommendation, http://www.w3.org/TR/xhtml11/. [XMLEVNTS] "XML Events - An events syntax for XML", Steven Pemberton, T. V. Raman, and Shane McCarron, 2002. W3C Recommendation, http://www.w3.org/TR/xml-events/. Mccobb Expires May 15, 2005 [Page 4] Internet-Draft XHTML+Voice - application/xhtml+voice+xml Nov. 15, 2004 [XPLUSV12] "XHTML+Voice Profile 1.2," 16 March 2004, J. Axelsson, et al, http://www.voicexml.org/specs/multimodal/x+v/12/ [VXML20] "Voice Extensible Markup Language (VoiceXML)," 16 March 2004, Scott McGlashan et al, W3C Recommendation, http://www.w3.org/TR/voicexml20/. 8. Authors' Address Gerald M. McCobb IBM Corporation 8051 Congress Avenue, Office 2019 Boca Raton, Florida 33487 USA Phone: +1-561-862-2109 Fax: +1-561-862-3922 EMail: mccobb(a)us.ibm.com 9. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use Mccobb Expires May 15, 2005 [Page 5] Internet-Draft XHTML+Voice - application/xhtml+voice+xml Nov. 15, 2004 of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr(a)ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mccobb Expires May 15, 2005 [Page 6] Regards, Gerald McCobb IBM 8051 Congress Avenue Boca Raton, FL 33487 Tel. # 561-862-2109 T/L 975-2109

2 3

Transport Area requests Media Type review for application/conference-info+xml
by Allison Mankin 21 Apr '05

21 Apr '05

The Transport Area requests a Media Type review for the proposed new type application/conference-info+xml, intended for the IETF tree, as a Proposed Standard, specified in draft-ietf-sipping-conference-package-10.txt Please provide any comments by 4 May 2005. Thanks, Allison

1 0

For review: application/atom+xml
by Mark Nottingham 20 Apr '05

20 Apr '05

One of the deliverables of the ATOMPUB WG is an xml-based format for Web syndication. Please review the proposed "application/atom+xml" media type therein; the registration template can be found below, and the complete draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt Regards, ---8<---- An Atom Document, when serialized as XML 1.0, can be identified with the following media type: MIME media type name: application MIME subtype name: atom+xml Mandatory parameters: None. Optional parameters: "charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], section 3.2. Security considerations: As defined in this specification. [[anchor59: update upon publication]] In addition, 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. [[anchor60: update upon publication]] Applications that 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: .atom Fragment identifiers: As specified for "application/xml" in [RFC3023], section 5. Base URI: As specified in [RFC3023], section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Mark Nottingham <mnot(a)pobox.com> Intended usage: COMMON Author/Change controller: This specification's author(s). [[anchor61: update upon publication]] --->8--- -- Mark Nottingham http://www.mnot.net/

3 4

Transport Area requests Media Type review for audio/BV16 and audio/BV32
by Allison Mankin 06 Apr '05

06 Apr '05

The Transport Area requests a Media Type review for the proposed new types audio/BV16 and audio/BV32, intended for the IETF tree, for Proposed Standard, specified in http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-04.txt. We know of the following needed change: The reference RFC for maxptime is RFC 3267, not 2327. Please provide any comments before 21 April 2005. Thanks, Allison

1 0

Type 'text/csv', draft-04
by Yakov Shafranovich 05 Apr '05

05 Apr '05

I posted a new version (-04) correcting the ABNF grammar in response to IESG comments, adding a few clarifications and adding a new optional "header" parameter to indicate the absence or presence of a header line. Copies of the draft can be found below and the draft should post to the IETF ID repository sometime Monday: http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime… http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime… HTML and text diff of changes: http://www.shaftek.org/publications/drafts/mime-csv/rfcdiff-03-to-04.html http://www.shaftek.org/publications/drafts/mime-csv/diff-03-to-04.txt Yakov

1 1

please review draft-froumentin-voice-mediatypes-00
by Max Froumentin 04 Apr '05

04 Apr '05

draft-froumentin-voice-mediatypes-00 contains the registration of the 6 media types of the W3C Speech Interface Framework (including the following specifications: SSML, SRGS, CCXML, PLS and VoiceXML) Draft available at http://www.ietf.org/internet-drafts/draft-froumentin-voice-mediatypes-00.txt and copied below. Max Froumentin, W3C Network Working Group M. Froumentin Internet-Draft W3C Expires: September 2, 2005 March 2005 The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml and application/pls+xml draft-froumentin-voice-mediatypes-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines the media type for the languages of the W3C Speech Interface Framework: VoiceXML, SSML, SRGS, CCXML and PLS. Froumentin Expires September 2, 2005 [Page 1] Internet-Draft W3C Speech Interface Framework Media Types March 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Registration of application/voicexml+xml, application/ssml+xml, application/srgs+xml, application/ccxml+xml and application/pls+xml . . . . . . . . 4 2.1 Encoding considerations . . . . . . . . . . . . . . . . . 4 2.2 Interoperability considerations . . . . . . . . . . . . . 4 2.3 Published specifications . . . . . . . . . . . . . . . . . 4 2.4 Applications which use these media types . . . . . . . . . 4 2.5 Security Considerations . . . . . . . . . . . . . . . . . 4 2.6 Additional Information . . . . . . . . . . . . . . . . . . 5 2.6.1 Magic numbers . . . . . . . . . . . . . . . . . . . . 5 2.6.2 File extensions . . . . . . . . . . . . . . . . . . . 5 2.6.3 Fragment identifiers . . . . . . . . . . . . . . . . . 5 2.6.4 Macintosh File Type Code . . . . . . . . . . . . . . . 5 2.6.5 Person & email address to contact for further information . . . . . . . . . . . . . . . . . . . . . 5 2.6.6 Intended usage . . . . . . . . . . . . . . . . . . . . 5 2.6.7 Change Controller . . . . . . . . . . . . . . . . . . 5 3. Registration of application/srgs . . . . . . . . . . . . . . . 7 3.1 Encoding considerations . . . . . . . . . . . . . . . . . 7 3.2 Interoperability considerations . . . . . . . . . . . . . 7 3.3 Published specifications . . . . . . . . . . . . . . . . . 7 3.4 Applications which use this media types . . . . . . . . . 7 3.5 Security Considerations . . . . . . . . . . . . . . . . . 7 3.6 Additional Information . . . . . . . . . . . . . . . . . . 7 3.6.1 Magic numbers . . . . . . . . . . . . . . . . . . . . 7 3.6.2 File extensions . . . . . . . . . . . . . . . . . . . 8 3.6.3 Macintosh File Type Code . . . . . . . . . . . . . . . 8 3.6.4 Person & email address to contact for further information . . . . . . . . . . . . . . . . . . . . . 8 3.6.5 Intended usage . . . . . . . . . . . . . . . . . . . . 8 3.6.6 Change Controller . . . . . . . . . . . . . . . . . . 8 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Froumentin Expires September 2, 2005 [Page 2] Internet-Draft W3C Speech Interface Framework Media Types March 2005 1. Introduction This specification defines the media types of the VoiceXML, SSML, SRGS, CCXML and PLS, the specifications of the W3C Speech Interface Platform VoiceXML is an XML language designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed initiative conversations. The associated media type defined in this document is "application/voicexml+xml". The Speech Synthesis Markup Language Specification (SSML) defines an XML-based markup language for assisting the generation of synthetic speech in Web and other applications. The essential role of SSML is to provide authors of synthesizable content a standard way to control aspects of speech such as pronunciation, volume, pitch, rate, etc. across different synthesis-capable platforms. The asociated media type defined in this document is "application/ssml+xml". The Speech Recognition Grammar Specification (SRGS) defines syntax for representing grammars for use in speech recognition so that developers can specify the words and patterns of words to be listened for by a speech recognizer. The syntax of the grammar format exists in two forms, an Augmented BNF Form and an XML Form. The respective media types defined in this document are "application/srgs" and "application/srgs+xml". The Call Control eXtensible Markup Language (CCXML) is an XML language designed to provide telephony call control support for dialog systems, such as VoiceXML. The associated media type defined in this document is "application/ccxml+xml". The Pronunciation Lexicon Specification (PLS) defines an XML syntax for specifying pronunciation lexicons to be used by speech recognition and speech synthesis engines in voice browser applications. The associated media type defined in this document is "application/pls+xml". Froumentin Expires September 2, 2005 [Page 3] Internet-Draft W3C Speech Interface Framework Media Types March 2005 2. Registration of application/voicexml+xml, application/ssml+xml, application/srgs+xml, application/ccxml+xml and application/pls+xml MIME media type name: application MIME subtype names: voicexml+xml, ssml+xml, srgs+xml, ccxml+xml, pls+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 RFC 3023 [RFC3023]. 2.1 Encoding considerations Identical to those of "application/xml" as described in RFC 3023 [RFC3023], section 3.2 2.2 Interoperability considerations There are no known interoperability issues. 2.3 Published specifications Voice Extensible Markup Language 2.0 [VoiceXML2.0] Voice Extensible Markup Language 2.1 [VoiceXML2.1] Speech Synthesis Markup Language (SSML) Version 1.0 [SSML] Speech Recognition Grammar Specification Version 1.0 [SRGS] Voice Browser Call Control: CCXML Version 1.0 [CCXML] Pronunciation Lexicon Specification (PLS) Version 1.0 [PLS] 2.4 Applications which use these media types Various W3C Speech Interface Platform implementations use these media types 2.5 Security Considerations Several instructions in the cited specifications may cause arbitrary URIs to be dereferenced. In this case, the security issues of [RFC2396], section 7, should be considered. In addition, because of the extensibility features of those specifications, it is possible that the registered media types may describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of the specifications, 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 Froumentin Expires September 2, 2005 [Page 4] Internet-Draft W3C Speech Interface Framework Media Types March 2005 dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. 2.6 Additional Information 2.6.1 Magic numbers Although no byte sequences can be counted on to always be present, XML MIME entities in ASCII-compatible charsets (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D 00 6C or FF FE 3C 00 3F 00 78 00 6D 00 6C 00 (the Byte Order Mark (BOM) followed by "<?xml"). For more information, see Appendix F of [XML]. 2.6.2 File extensions VoiceXML files: .vxml SSML files: .ssml SRGS files (XML syntax): .grxml CCXML files: .ccxml PLS files: .pls 2.6.3 Fragment identifiers Identical to that of "application/xml" as described in RFC 3023 [RFC3023], section 5. 2.6.4 Macintosh File Type Code "TEXT" 2.6.5 Person & email address to contact for further information World Wide Web Consortium <web-human(a)w3.org> 2.6.6 Intended usage COMMON 2.6.7 Change Controller The Speech Interface Framework specifications set is a work product of the World Wide Web Consortium's Voice Browser Working Group. The Froumentin Expires September 2, 2005 [Page 5] Internet-Draft W3C Speech Interface Framework Media Types March 2005 W3C has change control over these specifications. Froumentin Expires September 2, 2005 [Page 6] Internet-Draft W3C Speech Interface Framework Media Types March 2005 3. Registration of application/srgs MIME media type name: application MIME subtype names: srgs Required parameters: none Optional parameters: none 3.1 Encoding considerations The ABNF Form of SRGS follows the character encoding handling defined for XML: an ABNF grammar processor must accept both the UTF-8 and UTF-16 encodings of ISO/IEC 10646 and may support other character encodings. 3.2 Interoperability considerations There are no known interoperability issues. 3.3 Published specifications Speech Recognition Grammar Specification Version 1.0 [SRGS] 3.4 Applications which use this media types Various SRGS implementations use this media type. 3.5 Security Considerations Several instructions in SRGS may cause arbitrary URIs to be dereferenced. In this case, the security issues of [RFC2396], section 7, should be considered. In addition, because of the extensibility features of SRGS, it is possible that the registered media types may describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of the specifications, 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 potentially arise. And in that case, they would fall outside the domain of this registration document. 3.6 Additional Information 3.6.1 Magic numbers The ABNF self-identifying header must be present in any legal Froumentin Expires September 2, 2005 [Page 7] Internet-Draft W3C Speech Interface Framework Media Types March 2005 stand-alone ABNF Form grammar document. The first character of an ABNF document must be the "#" symbol (x23) unless preceded by an optional XML 1.0 byte order mark [XML ú4.3.3]. The ABNF byte order mark follows the XML definition and requirements. For example, documents encoded in UTF-16 must begin with the byte order mark. The optional byte order mark and required "#" symbol must be followed immediately by the exact string "ABNF" (x41 x42 x4d x46) or the appropriate equivalent for the document's encoding (e.g. for UTF-16 little-endian: x23 x00 x41 x00 x42 x00 x4d x00 x46 x00). If the byte order mark is absent on a grammar encoded in UTF-16 then the grammar processor should perform auto-detection of character encoding in a manner analogous to auto-detection of character encoding in XML [XML úF]. Next follows a single space character (x20) and the required version number which is "1.0" for this specification (x31 x2e x30). 3.6.2 File extensions .gram 3.6.3 Macintosh File Type Code "TEXT" 3.6.4 Person & email address to contact for further information World Wide Web Consortium <web-human(a)w3.org> 3.6.5 Intended usage COMMON 3.6.6 Change Controller The SRGS specification is a work product of the World Wide Web Consortium's Voice Browser Working Group. The W3C has change control over the SRGS specification. 4. References [CCXML] Auburn, RJ., Ed., "Voice Browser Call Control: CCXML Version 1.0, W3C Working Draft", January 2005, <http://www.w3.org/TR/2005/WD-ccxml-20050111/>. [PLS] Baggia, P., Ed., "Pronunciation Lexicon Specification (PLS) Version 1.0, W3C Working Draft", February 2005, <http://www.w3.org/TR/2005/WD-pronunciation-lexicon-200502 14/>. Froumentin Expires September 2, 2005 [Page 8] Internet-Draft W3C Speech Interface Framework Media Types March 2005 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396", August 1998, <http://www.ietf.org/rfc/rfc2396.txt>. [RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", January 2001, <http://www.ietf.org/rfc/rfc3023.txt>. [SRGS] Hunt, A., Ed. and S. McGlashan, Ed., "Speech Recognition Grammar Specification Version 1.0, W3C Recommendation", March 2004, <http://www.w3.org/TR/2004/REC-speech-grammar-20040316/>. [SSML] Burnett, D., Ed., Walker, M., Ed. and A. Hunt, Ed., "Speech Synthesis Markup Language (SSML) Version 1.0, W3C Recomendation", September 2004, <http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/> . [VoiceXML2.0] McGlashan, S., Ed., "Voice Extensible Markup Language (VoiceXML) Version 2.0, W3C Recommendation", March 2004, <http://www.w3.org/TR/2004/REC-voicexml20-20040316/>. [VoiceXML2.1] Oshry, M., Ed., "Voice Extensible Markup Language (VoiceXML) Version 2.1, W3C Working Draft", July 2004, <http://www.w3.org/TR/2004/WD-voicexml21-20040728/>. Author's Address Max Froumentin World Wide Web Consortium Froumentin Expires September 2, 2005 [Page 9] Internet-Draft W3C Speech Interface Framework Media Types March 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr(a)ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Froumentin Expires September 2, 2005 [Page 10]

1 0

RE: Media Type "text/csv": new draft (-02) and Last Call
by clyde.ingram＠edl.uk.eds.com 03 Apr '05

03 Apr '05

Yakov, That draft wording sounds excellent. Now, if you were to ALSO mandate the presence of the header record, that would mitigate my concern that computer applications should be able to exchange CSV files without worrying about same field order (simply because the header conveys the field names, rather than needing an out-of-band, bilateral agreement). And, of course, presence of a header record lets a computer application determine immediately whether the supplied fields are likely to be what it expects. All good aids for careful validation. Thank-you, Clyde -----Original Message----- From: Yakov Shafranovich [mailto:research@solidmatrix.com] Sent: Wednesday, March 30, 2005 8:08 PM To: clyde.ingram(a)edl.uk.eds.com Cc: GK-lists(a)ninebynine.org; ietf-types(a)alvestrand.no Subject: Re: Media Type "text/csv": new draft (-02) and Last Call clyde.ingram(a)edl.uk.eds.com wrote: > > But the same cannot be said of automated computer-based applications, > where maintaining a strict count of generated and expected > Comma-Separated-Values per record is not only easy, but also allows for > an extra level of data validation: namely that a received record is > corrupt if it has too few or too many fields. This is where > standardisation in the format of the CSV records becomes appropriate > material for an RFC. > The draft as it is written now (-03) does not mandate that the same number of fields need to appear on each line, mainly due to the fact that the draft is focusing on the MIME type registration. Would the following change to section 2, subsection 4 be sufficient to address your concerns: "Within the header and each record there may be one or more fields, separated by commas. Each line should contain the same number of fields throughout the file. The last field in the record may not be followed by a comma. For example:" Yakov

2 1