June 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

Request to review Media type registration in draft-ietf-avt-rtp-ac3-07.txt
by Magnus Westerlund 29 Jun '05

29 Jun '05

Hi, Please review the media type registration for the AC-3 RTP payload format before 20th of July. http://ietf.levkowetz.com/drafts/avt/rtp-ac3/draft-ietf-avt-rtp-ac3-07.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

1 0

Input Needed: Media Type Registry Structure
by Scott Hollenbeck 24 Jun '05

24 Jun '05

Community input needed: During IESG evaluation of draft-hoehrmann-script-types, one of the General Area reviewers provided this comment: "IANA seems to have figured out that the types to be registered are MIME media types but probably should be told how to indicate that the two text/ registrations are obsolete, or at least that it is important to mark these registrations as obsolete in the registry (unless the OBSOLETE intended usage field in the registration suffices, but marking the registry entry will be more effective)." Follow-up discussion within the IESG has prompted this query. The templates in draft-hoehrmann-script-types use the "Intended Usage" field in the templates to note that two of the types are obsolete. The reviewer is suggesting that this status be displayed more obviously at a higher level within the registry. This isn't exactly an issue for the document being reviewed, but it might be an issue for the structure of the registry. Should the registry structure be changed to display the status of obsolete (or any other) types more prominently? If so, we might need a new document or a revision to draft-freed-media-type-reg to describe whatever changes are needed. -Scott-

6 6

Fwd: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed-text-15.txt
by Colin Perkins 14 Jun '05

14 Jun '05

The AVT working group requests a media types review for the updated 3GPP timed text draft. There was much recent discussion on this subject, and this draft is intended to address the concerns expressed. Colin (AVT co-chair) Begin forwarded message: > From: "Jose Rey" <Jose.Rey(a)eu.panasonic.com> > Date: 14 June 2005 08:33:16 BDT > To: <avt(a)ietf.org> > Subject: FW: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed- > text-15.txt > > Hi all, > > A new version is out. This update includes some very minor > editorial changes as well as those changes agreed during the Media > Type discussions (below.) > > Looking forward to WGLC! > > José > > ---------------------------------------------------------------------- > ----- > > - Section 2.1, p.4: remove paragraph that causes confusion > > REMOVED: > > The scope of the 3GPP PSS specification (in the following > referred to > as PSS) includes both downloading and streaming of multimedia > content > over 3G packet-switched networks. PSS adopts multimedia codecs > such > as MPEG-4 Visual [22], AMR wide-band [23] or MPEG-4 AAC [24] for > encoding content. Other protocols like RTSP [15] for session > set-up > and control, or SMIL [9] for handling presentation layouts. For > transport, HTTP over TCP is used for downloading and RTP for > streaming. > > > - Section 8: > OLD: > The media subtype for the 3GPP Timed Text codec is allocated > from the > IETF tree. The top-level media type under which this payload > format > is registered is 'text'. > > The receiver MUST ignore any unrecognized parameter. > > Media type: text > > NEW: > The media subtype for the 3GPP Timed Text codec is allocated > from the > standards tree. The top-level media type under which this payload > format is registered is 'video'. This registration is done > using the > template defined in [31] and following RFC 3555 [30]. > > The receiver MUST ignore any unrecognized parameter. > > Media type: video > > > OLD: > Encoding considerations: > > RTP payloads complying with this payload format contain > binary > data. > > Note that this type is incompatible with the use of text > media > types in other protocols, e.g. text/html. This is because in > order to extract and decode any of the timed text media it is > necessary understand the (binary) payload headers defined in > RFCXXXX. > > Restrictions on usage: > > This type is only defined for transfer via RTP. > > > NEW: > Encoding considerations: > > This media type is framed (see section 4.8 in [31]) and > partially contains binary data. > > Restrictions on usage: > > This media type depends on RTP framing, and hence is only > defined for > transfer via RTP [RFC 3550]. Transport within other > framing protocols > is not defined at this time. > > OLD: > Interoperability considerations: > > The 3GPP Timed Text media format and its storage is > specified in > Release 6 of 3GPP TS 26.245 "Transparent end-to-end packet > switched streaming service (PSS); Timed Text Format (Release > 6)". The 3GPP file format (3GP) and the SMIL language > profile > used can be found in Release 5 of 3GPP TS 26.234 and in the > corresponding specifications for later Releases. Note > also that > 3GPP may in future Releases specify extensions or updates > to the > timed text media format in a backwards-compatible way, > e.g. new > modifier boxes or extensions to the sample descriptions. The > payload format defined in RFCXXXX allows for such extensions. > For future 3GPP Releases of the Timed Text Format, the > parameter > "sver" is used to identify the exact specification used. > > NEW: > Interoperability considerations: > > The 3GPP Timed Text media format and its file storage is > specified in Release 6 of 3GPP TS 26.245 "Transparent end- > to-end > packet switched streaming service (PSS); Timed Text Format > (Release 6)". Note also that 3GPP may in future Releases > specify extensions or updates to the timed text media > format in > a backwards-compatible way, e.g. new modifier boxes or > extensions to the sample descriptions. The payload format > defined in RFCXXXX allows for such extensions. For future > 3GPP > Releases of the Timed Text Format, the parameter "sver" is > used > to identify the exact specification used. > > The defined storage format for 3GPP Timed Text format is > the 3GPP File > Format (3GP) [32]. 3GP files may be transferred using the > media type > video/3gpp as registered by RFC 3839 [33]. The 3GPP File > Format is a container > file that may contain, e.g., audio and video which may be > synchronized with the > 3GPP Timed Text. > > > - Section 12.2: New informative references > > REMOVED: > > References 22, 23 and 24 > > NEW: > > [30] Casner, S. and P. Hoschka, "MIME Type Registration of RTP > Payload Formats", RFC 3555, July 2003. > > [31] Freed, N. and J. Klensin, "Media Type Specifications and > Registration Procedures", draft-freed-media-type-reg-04, > April 2005. > > [32] Transparent end-to-end packet switched streaming service > (PSS); > 3GPP file format (3GP) (Release 6), TS 26.244 V6.3. March > 2005. > > [33] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd > Generation Partnership Project (3GPP) Multimedia files", > RFC 3839, July 2004. > > -- >> -----Original Message----- >> From: avt-bounces(a)ietf.org [mailto:avt-bounces@ietf.org] On >> Behalf Of Internet-Drafts(a)ietf.org >> Sent: Monday, June 13, 2005 9:37 PM >> To: i-d-announce(a)ietf.org >> Cc: avt(a)ietf.org >> Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed-text-15.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Audio/Video Transport >> Working Group of the IETF. >> >> Title : RTP Payload Format for 3GPP Timed Text >> Author(s) : J. Rey, Y. Matsui >> Filename : draft-ietf-avt-rtp-3gpp-timed-text-15.txt >> Pages : 59 >> Date : 2005-6-13 >> >> This document specifies an RTP payload format for the transmission of >> 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed >> text is a time-lined decorated text media format with >> defined storage >> in a 3GP file. Timed Text can be synchronized with audio/video >> contents and used in application such as captioning, titling and >> multimedia presentations. In the following sections the >> problems of >> streaming timed text are addressed and a payload format >> for streaming >> 3GPP timed text over RTP is specified. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed- >> text-15.txt >

1 0

Registration of MIME media type application/rnc
by MURATA Makoto 11 Jun '05

11 Jun '05

This is a request for registration in the standard tree. The compact syntax for RELAX NG (a schema language for XML) will be published as a Final Draft Amendment (FDAM) of ISO/IEC 19757-4 soon. The FDAM will contain this registation information. If this FDAM passes a two-month FDAM ballot, it will become an Amendment of ISO/IEC 197575-4. Since this FDAM ballot does not allow any technical comments and many member bodies of ISO/IEC JTC1 simply say yes, the FDAM is extremely likely to pass the ballot. The compact syntax was first published as an OASIS committee specification. MIME media type name: application MIME subtype name: rnc Required parameters: none Optional parameters: none Encoding considerations: UTF-8 or UTF-16 shall be used for this media type. Security considerations: When the RELAX NG validator retrieves a schema in the RELAX NG compact syntax, it may further retrieve external schemas that are referenced from the schema directly or indirectly. Although the RELAX NG validator is required not to retrieve an infinite number of schemas, a large number of external schemas may be retrieved, thus wasting the network, disk, and CPU power. Interoperability considerations: RELAX NG has been widely used as an XML schema language. A notable example is the Open Document specification of OASIS. Published specification: ISO/IEC 19757-2, Document Schema Definition Language (DSDL) Part 2 - Regular-grammar-based validation -- RELAX NG, Amendment 1: Compact Syntax OASIS Committee Specification, RELAX NG Compact Syntax 21 November 2002 Applications which use this media type: validators, schema authoring tools, and so forth Additional information: Magic number(s): none File extension(s): rnc Macintosh File Type Code(s): "TEXT" Person & email address to contact for further information: MURATA Makoto (FAMILY Given), International University of Japan, eb2m-mrt(a)asahi-net.or.jp Intended usage: COMMON Author/Change controller: ISO/IEC JTC1/SC34 -- MURATA Makoto <murata(a)hokkaido.email.ne.jp>

5 18

Re: [AVT] Re: Request to review media type in AVT working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Magnus Westerlund 05 Jun '05

05 Jun '05

Hi Tom, Tom Taylor wrote: > Simple question: do you expect a given session to consist of just one > character encoding (UTF-8 or UTF-16) or do you want the possibility for > it to contain a mixture? If the encoding is a per-session attribute it > makes more sense for it to be negotiated out-of-band, as a parameter of > the MIME type (and hence as an SDP "a=fmtp" parameter). > To my understanding a session may contain a mixture of UTF-8 and UTF-16. Note also, that removing the bit wouldn't result in any byte savings. So I see it as necessary to have the U bit. Duplicating the information is mostly a recipe for confusion when it doesn't agree. Thus, I propose to leave it out. Cheers 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 2

RE: [AVT] Re: Request to review media type in AVT working grouplastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Jose Rey 03 Jun '05

03 Jun '05

[sorry for delay.. I am travelling] Ned, Tom, > > > Hi Tom, > > > Tom Taylor wrote: > > > Simple question: do you expect a given session to consist of just > > > one character encoding (UTF-8 or UTF-16) or do you want the > > > possibility for it to contain a mixture? If the encoding is a > > > per-session attribute it makes more sense for it to be negotiated > > > out-of-band, as a parameter of the MIME type (and hence > as an SDP "a=fmtp" parameter). > > > > > > To my understanding a session may contain a mixture of > UTF-8 and UTF-16. This is correct. > > That implies that the bit isn't aligned with where media > types appear. And that in turn makes it inappropriate to map > to a media type parameter, irrespective of whether or not it > is used for negotiation. > Yes. Since all is fine now, I will make the changes and send a new draft in the next days. José

1 0

Re: [AVT] Re: Request to review media type in AVT working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Ned Freed 03 Jun '05

03 Jun '05

> Simple question: do you expect a given session to consist of just one > character encoding (UTF-8 or UTF-16) or do you want the possibility for > it to contain a mixture? If the encoding is a per-session attribute it > makes more sense for it to be negotiated out-of-band, as a parameter of > the MIME type (and hence as an SDP "a=fmtp" parameter). Yes, this is what I was trying to get at when I asked if the bit appears in the same context as the media type or not. Ned

1 0

RE: [AVT] Re: Request to review media type in AVT working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Jose Rey 02 Jun '05

02 Jun '05

Ned, > -----Original Message----- > From: avt-bounces(a)ietf.org [mailto:avt-bounces@ietf.org] On > Behalf Of Ned Freed > Sent: Thursday, June 02, 2005 7:50 PM > To: Magnus Westerlund > Cc: Ned Freed; IETF AVT WG; Allison Mankin; Bruce Lilly; > Colin Perkins; ietf-types(a)alvestrand.no > Subject: Re: [AVT] Re: Request to review media type in AVT > working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt > > > Ned Freed wrote: > > > > > > Then why do you need the U bit? > > > From TS 26.245, section 5.1: > > > Text strings for display and font names are uniformly coded > in UTF-8, > > or start with a UTF-16 BYTE ORDER MARK (\uFEFF) and by that > indicate > > that the string which starts with the byte order mark is in UTF-16. > > Terminals shall recognise the byte-order mark in this byte > order; they > > are not required to recognise byte-reversed UTF-16, indicated by a > > byte-reversed byte-order mark. > > > However this payload format removes the Byte Order Mark and > requires a > > specific byte order. Thus to be able to provide the same > information > > that a string is encoded in UTF-8 or UTF-16, it is explicitly > > indicated using the U bit. > > Does the U bit appear in the same context as the media type > itself or is it part of the payload or some other aspect of > the protocol? I don't know what exactly is meant by the latter, but the former is not the case. Besides, apart from complicating session negotiation (O/A, as Magnus mentions) it is really not necessary because both charsets are required by the TT media format. > It seems appropriate to define a mapping to a > parameter if it appears alongside the media type, but not if > it doesn't. [snip] > I'm not suggesting defining additional parameters. I'm only > asking if it makes sense to map and existing session > parameter to a media type parameter. > It doesn't make sense, it is not a negotiable thing. Cheers, José

1 0

Re: [AVT] Re: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
by Ned Freed 02 Jun '05

02 Jun '05

> I'd like to push back gently on the change from 'text' to 'video', > just to test the waters. > The media types 'video' and 'audio' express what you *get* if you > decode the stream, not how it is *encoded*. They're not call 'float' > or 'integer' or 'huffman', for example. Yet for some reason we want > to reserve the media type 'text' for those that express their > encoding in printable text, without regard for what they are > expressing; this seems inconsistent. No, that's not it at all. The restrictions on the text type have to do with the nature of the underlying data, not with how it is encoded. For example, there's plenty of use of text types, including text/plain, that requires binary encoding and cannot be accomodated by either 7bit or 8bit encodings. There are, however, more restrictions on text that then are on other top-level types. The fact that there are more restrictions may seem inconsistent, but that's how this stuff was defined long ago and it is way too late to change it. > I don't believe that > everything expressed in say XML ought to be considered a 'text' media > type, for example. It's more likely that *nothing* expressed in XML would be considered to be a text media type. Ned

7 9