March 2006 - Ietf-types

Preliminary Community Review: text/json
by Douglas Crockford 15 Apr '07

15 Apr '07

This is notice of a potential media type registration. The details may be found here: http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-02.txt

10 11

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

29 Mar '07

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

3 8

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

18 Jan '07

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

8 16

draft-taylor-example-media-types-01.xml
by Tom-PT Taylor 30 Mar '06

30 Mar '06

Since I have received no further comments on the example media type draft, I have added the following sentence to the introduction as I indicated I would do. When it appears, I will forward it to the IESG. "It is suggested that compilers of illustrative examples involving media types in trees other than the standards tree might also incorporate the string "example" into their hypothetical media types." Tom Taylor

1 0

Comments solicited on application/cellml+xml
by Andrew Miller 28 Mar '06

28 Mar '06

Dear all, I am proposing that the MIME media type application/cellml+xml be used for CellML documents. Please see the Internet draft draft-miller-media-type-cellml-00.txt, available at http://www.ietf.org/internet-drafts/draft-miller-media-type-cellml-00.txt, for the full registration. Any comments are welcome, please send them to ak.miller(a)auckland.ac.nz. If there are no objections, the document will be submitted to IESG for approval on the Wednesday the 12th of April, 2006. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 3

Review of draft-westerlund-mime-dls-01
by Tom-PT Taylor 27 Mar '06

27 Mar '06

The subject draft is a reasonable contribution to the are of Internet engineering which it covers. It has editorial issues which should be fixed before it is approved. The major issue is that, despite the presence of an acceptable Security Considerations section (section 2), the registration in section 3.1 points to the Security Considerations section of RFC XXXX. Section 4 is an RFC Editor's note requesting the substitution of the proper number for RFC XXXX. There is no RFC XXXX in the references. Undoubtedly this was the result of a change of plan. I had two minor editorial comments: In section 2, third paragraph, third line, the phrase "it is stressed" caused a momentary glitch in my mind: "Where is it stressed?". Perhaps the sentence might read better if it were phrased: "A key point is that conditional chunks are optional, that is to say a parser does not have to execute a conditional chunk." The other item is an extra "the" in the first line of "Interoperability Considerations" in section 3.1. Tom Taylor

3 2

RE: Charset mandatory in unix/linux
by Misha Wolf 27 Mar '06

27 Mar '06

[John Cowan has writtten this reply to Bruce's mail and has given me permission to forward it. Misha] > These typically (and specifically for tar and zip) do not include > media type information or charset or other type parameter information. > The information in the tar format, for example, carries time stamps, > permissions, and file type (where "type" means plain file vs. directory > vs. device, etc.). ZIP format, however, has the ability to store extended attributes, though this is normally only used on VMS and OS/2 systems. See http://www.info-zip.org/pub/infozip/doc/appnote-iz-latest.zip for the details. > The holy grail of a single unified character set that will supposedly > solve the problem sounds nice until one looks at the details. I think this line, and the rant which follows, is a serious exaggeration of the facts. > "Unicode" is itself a "vast array" (ever-increasing in number) of > character code sets. Saying "Unicode" doesn't tell me if that's > pre-"Korean mess" (see RFC 2279) "Unicode" or post-"Korean mess" > "Unicode". The pre-Korean-mess versions (1.0 and 1.1) do in fact have their own charsets: Unicode-1-1 and Unicode-1-1-UTF-8. However, no one has ever come forward with actual text encoded in anger that contains pre-mess Korean syllables, so it's almost entirely academic. > Or whether that's the "Unicode" that has among its design principles > a uniform code width of 16 bits and an encoding strictly of text > (specifically excluding musical notation), or the "Unicode" that has a > much wider code width and includes non-textual cruft such as (yes, you > guessed it) musical notation. Or whether it's one of the "Unicode"s > that has an attempt at encoding language information (versions 3.1 > and 3.2), or one of the "Unicode"s (earlier and later) that do not. > And so on. All this is about one thing and one thing only: what characters your implementation can handle. If you have an old 8-bit or 16-bit implementation trying to process text involving new characters, it won't know what to make of them, but it won't be seriously confused. New implementations can of course handle old text fine using their more advanced models, because everything is backward compatible. As for language tagging in plain text, it was demanded by an IETF WG, was in effect born deprecated, and is formally deprecated as of 4.0 but of course remains present and will forever. > as far as I know, it's not even possible to have multiple versions of > Unicode and to transcode between them on the same machine. It's not possible because (other than the Korean mess) it's not necessary either. > [S]uppose Jacob has received a text file in Korean and the issue of > labeling the charset and language is solved. If it is labeled as > "ISO-2022-KR", he can proceed to make sense of the file; conversely > if it is labeled as "utf-7" he cannot because he lacks information > to determine whether the result of the transformation to "Unicode" > should be interpreted as groups of 16 bits or some other code width, > as well as which code points represent various hangul characters. The former point is not relevant: you can interpret it as 16-bit or 21-bit codes without any difference in effect. The latter point I have already addressed. -- John Cowan cowan(a)ccil.org www.ccil.org/~cowan www.ap.org The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

2 1

Re: Charset mandatory in unix/linux
by Ned Freed 26 Mar '06

26 Mar '06

(cc'ing the ietf-types list since this doesn't seem like an appropriate topic for ietf-822) > The charset parameter is mandatory in the MIME content-type > attribute. Actually, I don't know of a single case where this is true. All media type pararameters are either type or subtype specific, so there is no general rule that applies to all charset parameters. Nevertheless, the charset parameters that attach to the text top-level type are optional, as is the charset parameter on application/xml. And making the parameter optional doesn't even imply that there's a default. For exmaple, In the case of XML the allowed charsets for unlabelled material are intentionally limited so they can be determined by inspection. > However, such a parameter is not mandatory in > Unix or Linux. I could say the same thing about media types. File extensions or type codes are commonly used to determine the media type. This is a huge problem that has led to serious security glitches as well as poor user experiences. > This is causing more and more problems, when > people have a mixture of files with different charsets, > which you easily get when you download files from the > Internet or receive them via e-mail. The reality is it is causing less and less problems as things gradually shift towards Unicode-based charsets and away from the vast array of less capable charsets. The security issues caused by non-use or misuse of media type labels are a far bigger problem, and worse, one that doesn't appear to be going away. > Would it be possible to get the people responsible for the > file systems in Unix and Linux to add a mandatory charset > attribute to all text files? Knowing the charset buys you very little without also knowing the media type. You seem to be focused on plain text here and hence you're ignoring the larger media type issue. Lots of media types have parameters and even when the media type can be determined - it frequently cannot be done reliably - it is often done in a way that doesn't allow additional parameters to be attached. Additionally, usage is shifting away from plain text and towards other, more sophisticated, formats - so much so that support for plain text has become a bit problematic in some places. This is one of the reasons given for moving away from plain text RFCs to some other format. > Best is probably to add a > generalized property list to files, so that also other > properties than charset can be added in the future. The ability to attach metadata to files is indeed a very useful feature, one that has been around for decades on some platforms at least. (I'm not going to bother with the history here.) And it is already available on Linux - at a minimum the ext2, ext3, and XFS file systems support it. (There are probably others but I'm too lazy to go look them up.) So in the sense of getting the filesystem to support this sort of tagging, your problem is already solved in many cases. But this is the easy part. You now have to get applications to agree on a specific use of metadata tags for charsets or media types or whatever. Good luck on getting that to happen. > The advantage would be that programs which transport files > across the Internet, such as e-mail, ftp and http, would > more often use the correct charset and not munge the files > by giving then an incorrect charset. The commonly occuring > problem with incorrect charset would be reduced. Also local > problems such as text editors would benefit from knowing > the charset of a file. First of all, email and http do not "transfer files" per se. They transfer data objects and each protocol defines the metadata it considers approproate to attach to data objects. The matchup of this metadata to file system metadata is imperfect at best, and there are plenty of issues in this space. (It is far from clear that adding additional type information will solve these problems, however.) Ftp does transfer files, but ftp is kinda old and doesn't understand file metadata too well if at all. This situation means that in situations where retention of file metadata is important some sort of additional container has to be used. A vast number of such container formats have been defined - tar files, zip files, AppleSingle/AppleDouble, etc. > (Mac OS earlier had a very good feature, you could add to > every file a property list called the "resource fork"). > This still works in Mac OS X, but is less and less often > used, since Unix, on which Mac OS X is based, does not have > this facility. In Mac OS X the resource fork is stored in a > separate file whose file name starts with ".", in the same > directory as the file described). Sigh. There are so many things wrong here it is difficult to know where to begin. I guess I'll start with resource forks. The HFS+ and HFSX file systems used by Mac OS X support resource forks natively. They are accessible through the Posix APIs not by prepending a dot to the file name (given how often adjunct files with this naming convention are created by UNIX facilites such a convention would cause all sorts of havoc) but rather by appending "/rsrc" - it's a sort of file-in-a-pseudo-subdirectory. And while it used to be true that most utilities on Mac OS X were unaware of resource forks, this has changed in recent versions - most of the UNIX-derived OS utilieis now handle resource forks correctly. However, resource forks are used to store file data, not metadata, so none of this is especially relevant to the metadata issue. Now, Apple apparently had some notion of extending the fork model to allow arbitrary named forks. Such a facility could in theory be used to store metadata, although using such a heavyweight mechanism to store metadata never seemed like a very good idea to me. (A fork is in effect a separate file as far as the on-disk structures are concerned, so even if you hide this from applications the overhead is still there.) Regardless, Apple has backed away from actually completing the implementation of this facility. My understanding is if you try to create forks with other names with the provided APIs you get an error. What Apple has done instead is implement full support for file metadata separate from forks. This IMO is the right approach. Apparently there's a separate B-tree for this somewhere in HFS+ - you don't even need to be running HFSX for it to work. It took Apple a while to get this done, but API routines to access this stuff now exist, and even better, they are apparently the same as the ones used on Linux. This support also works on other filesystems that lack built in metadata storage - the metadata is instead stored in a separate file with "._" prepended to the name. (I know there are ext2 and ext3 drivers for Mac OS X but I don't know if or how they handle the metadata issue - hopefully they store it in a way that's compatible with usage on Linux.) There's lots more to know about metadata on Mac OS X. This article describes the landscape pretty well: http://arstechnica.com/reviews/os/macosx-10.4.ars/6 So what's the bottom line? The bottom line is that you appear to be focusing on the wrong problem along several dimensions. First, charset information specifically isn't as interesting or essential as you claim, and the degree to which is it interesting is dropping for a variety of reasons. Second, you appear to have missed the larger and much more important problem of not having correct parameterized type information available. (And we haven't even discussed the many other sorts of metadata, like say language information, that is also useful to have.) Third, your focus on getting metadata support into filesystems is mostly misplaced - this is a solved problem in a lot of cases. And fifth, you don't seem to appreciate the difficulty of getting everyone to agree to actually use filesystem metadata to solve any of these problems. This last is a complete showstopper and I dispair of there ever being significant progress in this area because of it. Ned

4 3

[Fwd: I-D ACTION:draft-taylor-types-example-00.txt]
by Tom-PT Taylor 23 Mar '06

23 Mar '06

This is a draft implementing the idea of the example media type and subtype. Please look it over and see whether it is suitable for submission. I have had a comment suggesting that I add a bit of informative text suggesting the use of the string "example" in sample media descriptions involving types outside of the standards tree. This would go in the introduction. Tom Taylor

1 0

Request for review of audio/G729EV media type
by Colin Perkins 22 Mar '06

22 Mar '06

The AVT working group requests media type review for the audio/G729EV media type defined in section 6.1 of draft-ietf-avt-rtp-g729-scal-wb- ext-03.txt. This draft is currently in working group last call. We would be grateful if any comments could be made by 4th April 2006. Thanks, Colin (AVT co-chair)

1 0