July 2005 - Ietf-types - alvestrand.no

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

application/xhtml-voice+xml vs. application/xhtml-vocie+xml
by Bruce Lilly 03 Aug '05

03 Aug '05

draft-mccobb-xplusv-media-type-04 provides a registration template for type application/xhtml-voice+xml. The IANA registry now has an entry for application/xhtml-vocie+xml (i and c transposed in voice). Can this be fixed, please. Hopefully, nobody else has noticed the ...vocie... type and it can be safely elided...

8 14

Re: Registration of media type application/xhtml-voice+xml
by Martin Duerst 20 Jul '05

20 Jul '05

At 01:33 05/07/14, Gerald McCobb wrote: >I asked the IESG to postpone the publication of the >application/xhtml-voice+xml media type as an informational RFC. The >registration is not correct. It should be application/xhtml+voice+xml. >The application/xhtml+voice+xml media type was the original submission. > >There is an issue with the original submission: > >One of the reviewers pointed out that "a certain class of error could be >avoided by renaming this application/xhtml-plus-voice+xml... I don't know >of any other "+xml" [see RFC3023] media types that have a "+" in the >name... a poorly-constructed regexp looking for +xml along the lines of >/\+(.*)$/ would miss this one." I agree with that reviewer that the type should not contain '+' characters except before 'xml'. All other subtypes have used '-' as a separator. The '+' separator was specifically introduced to express the fact that the '+xml' part is something more than a simple subtype. Although there is probably nothing in RFC 3023 explicitly disallowing the use of '+' for "arbitrary use", I think that the whole rationale for '+xml' in Appendix A of RFC 3023 (in particular http://www.ietf.org/rfc/rfc3023.txt, A.12) seem to indicate that it shouldn't be done. >I believe this argument is not strong enough to prevent approval of the >application/xhtml+voice+xml media type: >2. The argument for having "+" in the subtype is unconvincing, given that >the simplest method to determine if something is XML is also the safest, >that is, if the last four characters are "+xml" or "/xml" then the >document is XML, otherwise it is not. If that has to be done with regexps, >instead of just examining the last four bytes, that would be /[/+]xml$/. >If type and subtype were split already it would be /\+?xml$/ for the subtype. I think the regexp example is only the tip of the iceberg. Not using the plus will allow better future extensibility. Regards, Martin.

3 2

ConfirmSystem: iana@icann.org [[15e0cfeddcc0a7fe]]
by iana＠iana.org 12 Jul '05

12 Jul '05

Thank you for your message. The iana(a)iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL <http://confirm.icann.org/?s=15e0cfeddcc0a7fe&l=iana@icann.org> If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "application/xhtml-voice+xml vs. application/xhtml-vocie+xml" and it arrived at IANA approximately at Tue Jul 12 13:08:25 2005. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[15e0cfeddcc0a7fe]] 1

1 0

New internet-Drafts for an extensible Inernet Message Format
by Bruce Lilly 12 Jul '05

12 Jul '05

Four related new drafts have been submitted discussing an extensible Internet Message Format to address a number of existing issues: o clutter in the header of the current (2822) format as received, which has led to implementations suppressing important content as well as clutter o ability to protect (sign and/or encrypt) the end-to-end content including the originator-supplied header fields o extensibility for further internationalization of content and/or for experimentation with new message formats o ability to reliably detect multiple list expansions, including the order of list expansions o avoiding a problem with current message/partial fragmentation and reassembly whereby the originator's Date field is altered and/or the partial message header Date fields do not accurately convey the RFC 2822-specified semantics all while maintaining backward compatibility and reliability. The drafts are draft-lilly-extensible-internet-message-format-p01-00 and -p02-00, -p03-00, and -p04-00. It is expected that there may be additional related parts (repositories for UAs, MSAs, filters, message stores, etc. to record non-originator content). -p02 is intended for Standards Track, which is not clearly indicated due to a typo; the others indicate their respective intended status in the page one heading per ID-Checklist suggestions. -p01 and -p04 contain MIME media type registration templates and -p03 contains some registration guidelines for related media type registrations. -p01 is an introduction. All four drafts are in a very early stage of development, rushed somewhat to meet the pre-IETF publication deadline. General discussion should probably take place on the ietf-822 list (where replies are suggested by the Reply-To field of this message), whereas media registration specific discussions should probably take place on the ietf-types list. The author of the drafts reads both lists, so cross-posting to both lists should be reserved for issues likely to be of interest to both lists. The author is expected to be incommunicado from tomorrow through July 19, so don't expect immediate responses.

1 1

Re: Old application/atom+xml issues
by Bill de hÓra 11 Jul '05

11 Jul '05

Robert Sayre wrote: > I worry that any statement like Bill's suggested text will confer > legitimacy on Atom 0.3 as long as the RFC is available. *Every* > current implementor is aware of the issue, so the short term benefit > of such text is pretty much nil. Long term, the text will actually be > harmful. +1 to this sentiment - I take it this means we're saying no to the interop text in the spec?

1 0

Re: Old application/atom+xml issues
by Sam Ruby 11 Jul '05

11 Jul '05

Robert Sayre wrote: > > So, -1 to mentioning Atom 0.3 at all. I agree with Robert. Note how Atom 0.2 isn't a problem at all... we can (and will) do the same thing with Atom 0.3. - Sam Ruby

1 0

Re: Old application/atom+xml issues
by Mark Baker 11 Jul '05

11 Jul '05

On Mon, Jul 11, 2005 at 09:59:19AM -0400, Sam Ruby wrote: > The most we can do is to say that such things are invalid, and to work > with the producers to correct this. Sounds good to me. > The majority of the existing atom 0.3 feeds are produced by a relatively > few producers. I am confident that these producers will convert over > quickly. > > I am also committed to getting the word out quickly that atom 0.3 feeds > are not to be considered valid. In particular, I plan to update the > feedvalidator to note this as a problem (first as a warning, and later I > will change this to an error). Nice. Thanks for your vigilance, Sam. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com

3 2

Re: Old application/atom+xml issues
by Mark Baker 11 Jul '05

11 Jul '05

On Tue, Jul 05, 2005 at 10:33:00AM -0400, Robert Sayre wrote: > On 7/5/05, Mark Baker <distobj(a)acm.org> wrote: > > > > I wanted to point out that comments I've made on the > > application/atom+xml media type registration template have not yet been > > incorporated into the syntax draft, nor have I received any feedback > > about why they needn't be. > > See comments from Tim here: > http://www.imc.org/atom-syntax/mail-archive/msg14423.html > > Sorry you didn't get direct feedback. :/ Ah, I should have thought to check the archives, thanks. It should have gone to ietf-types though, since that's where public review of media type registrations happen and where my comments were sent. I've CCd ietf-types on this message. Tim writes; > He's got a point on the namespace being mentioned, which creates some > semi-circular dependencies, sigh. As to whether it's currently in use, > largely due to lobbying from us, recent releases of both Apache and > IIS tie the application/atom+xml media type to the .atom extension, so > if people are creating 0.3 files and calling them whatever.atom, this > could be right. Having said that, I think we should push back. Because > any such current usage is unlicensed by any spec, & because we plan to > aggressively deprecate Atom 0.3 once we get 1.0 out and since I > suspect that 90% of 0.3 feeds come from one place we should have some > success. IMO, it matters not that no spec prescribes the use of this media type for Atom 0.3 feeds. What matters is whether it's in use today, which we seem to agree is the case. This seems an important piece of information that implementors should know, which is my motivation for asking that it be called out in the "interoperability considerations" section of the template. Something like; Interoperability considerations: Some existing agents and feeds that support the Atom 0.3 specification, make use of this media type despite Atom 0.3 not being compatible with Atom 1.0. As for the magic number, to keep it simple I'd suggest that none be defined by removing the "magic number" section. Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com

3 2

Transport Area requests Media Type review for MPEG4 registration draft
by Allison Mankin 05 Jul '05

05 Jul '05

The Transport Area requests a Media Type review for for the registrations draft-lim-mpeg4-mime-03.txt, intended for the standards tree. The draft is submitted for Proposed Standard. Please provide any comments as soon as possible, and before July 20, 2005. Thanks, Allison Transport Area Director

1 0