May 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

Request preliminary check of 8 personal media types
by Damian Dollahite 24 Sep '06

24 Sep '06

I would like to request a preliminary check of 8 media types collected in this document: http://purl.org/int-fiction/ifmi/documents/mediatypes/ This document is not a registration form or specification, rather it is a discussion of issues that need to be addressed so that these formats can be registered. It does include examples of how the registration forms might be filled out, however. Currently, these file formats are being transferred using "x-" prefixed types; I'm fairly certain that none of the controllers are aware that the prs. tree is open to everyone, or else they just assume that registration will involve too much paperwork to bother with. I plan to contact them and present them with this document, as well as volunteering to handle the paperwork for them. Once I've discussed these types with the format controllers, I'll submit them for another review before proceeding with registration; at this point all I need is a quick look-over to make sure I won't be giving the format controllers bad advice. The thing that especially concerns me is my use of a "+blorb" suffix on some of the types. I realize "+" suffixes are discouraged, but something of that nature is needed to allow correct dispatch of Blorb files. If "+blorb" is simply not appropriate, I'd appreciate suggestions on how else to solve the problem; I do not believe a "." or "-" facet is semantically correct here. Thank you, M.D. Dollahite

2 2

Request for review: application/cellml+xml
by Andrew Miller 25 May '06

25 May '06

Hi all, A revised Internet draft, http://www.ietf.org/internet-drafts/draft-miller-media-type-cellml-03.txt, has been published to replace draft-miller-media-type-cellml-02.txt. This draft changes the recommended file extension from .xml to .cellml, and recommends the use of .cellml when saving somewhere where file extensions matter. This extension has now been endorsed by the CellML team as the official CellML file extension. Best regards, Andrew Miller

2 1

[spam] The best pils f0r men health by l0wer prices!
by Miriam 23 May '06

23 May '06

1 0

Request for reviewing audio, vidoe, text/rtp-enc-aescm128
by Magnus Westerlund 23 May '06

23 May '06

This is a request to review the media types: audio/rtp-enc-aescm128 video/rtp-enc-aescm128 text/rtp-enc-aescm128 These have been requested by 3GPP SA4 to be registered in the standards tree by the IESG following the SDO rules in RFC 4288. The type registration is present in Technical Specification 26.234 in section K.1.4.1: http://www.3gpp.org/ftp/Specs/archive/26_series/26.234/26234-670.zip It is reproduced below for your information. The full media format is specified in Annex K of above specification. The registration template has been present in the document for a while and follows the template in RFC 2048. If that is a problem it can be fixed, however it will take some months. I therefore would also like to receive any further comments in that case. MIME media type name: audio, video, text MIME subtype name: rtp-enc-aescm128 Required parameters: opt: The payload type number of the payload type contained in the encrypted payload. An integer value between 0-127. rate: The timestamp rate of this payload type, which shall be the same as that of the original payload type. This is an integer value between 1 and 2^32. ContentID: The OMA DRM content ID [75] used to identify the content when establishing a crypto context. The value is an RFC 2396 [60] URI, which shall be quoted using <">. RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The value is an URI in accordance with RFC 2396 [60], which shall be quoted using <">. IVnonce: The value of this parameter is the nonce that forms the IV as specified by the crypto transform, encoded using Base 64 [69]. Optional parameters: SelectiveEncryption: Indicates if this stream is selectively encrypted. Allowed values are 0 (false) and 1 (true). If not present, selective encryption shall not be used. Please note that unless this indicator is integrity protected, it fulfills no purpose. Encoding considerations: This type is only defined for transfer via RTP (RFC 3550). Security considerations: See considerations raised in RTP RFC 3550 [9] and any applicable profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS 26.234, Release 6, Annex K for comments on security issues. The main issues that exists are: - This RTP payload format only confidentiality protects the RTP payload, thus header information is leaked, similarly to SRTP. - The use of stream ciphers as AES CM and no integrity protection allows an attacker to purposefully attack the content of the encrypted RTP payload by switching individual bits. - The usage of selective encryption without integrity protection allows for an attacker to perform any replacements of complete RTP payloads and packets it desires. - The payload format makes the receiver vulnerable to denial of service attacks that inserts RTP packets into the stream, that the receiver then interprets as being encrypted thus wasting computational resources. To prevent this attack, authentication needs to be used. Interoperability considerations: Published specification: 3GPP TS 26.234, Release 6. Open Mobile Alliance DRM Content Format V2.0 Applications which use this media type: Third Generation Partnership Project (3GPP) Packet-switched Streaming Service (PSS) clients and servers, which supports the Open Mobile Alliance's specification of Digital Rights Management version 2.0. Additional information: Magic number(s): N/A File extension(s): N/A Macintosh File Type Code(s): N/A Person & email address to contact for further information: magnus.westerlund(a)ericsson.com Intended usage: Common Author/Change controller: 3GPP TSG SA --- 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

4 4

Registration of media type "application/oebps-package+xml"
by Nick Bogaty 16 May '06

16 May '06

To whom it may concern, Apologies for not including the template for community review of the mime type "application/oebps-package+xml". It is as follows: Type name: application Subtype name: oebps-package+xml Required parameters: none Optional parameters: none Encoding considerations: UTF-8 or UTF-16 (XML) Security considerations: none Interoperability considerations: none Published specification: http://www.idpf.org/oebps/oebps1.2/download/oeb12-xhtml.htm Applications that use this media type: 1) eBook Technologies, Inc. eBook reading system. 2) Microsoft Reader. 3) OSoft reader.4) Content Reserve Publishing System 5) IDPF (container WG) 6) PC Reader.com 7) MobiPocket reader Additional information: Magic number(s): none File extension(s): .opf Macintosh file type code(s): none Person & email address to contact for further information: Nick Bogaty (nbogaty(a)idpf.org) Intended usage: COMMON (One of COMMON, LIMITED USE or OBSOLETE.) Restrictions on usage: none (Any restrictions on where the media type can be used go here.) Author: International Digital Publishing Forum (www.idpf.org <http://www.idpf.org/> ) Change controller: International Digital Publishing Forum (www.idpf.org <http://www.idpf.org/> ) (Any other information that the author deems interesting may be added below this line.) Some discussion of Macintosh file type codes and their purpose can be found in [MacOSFileTypes]. Additionally, please refrain from writing "none" or anything similar when no file extension or Macintosh file type is specified, lest "none" be confused with an actual code value. -----Original Message----- From: Nick Bogaty [mailto:nbogaty@idpf.org] Sent: Friday, April 28, 2006 1:29 PM To: 'iesg(a)ietf.org'; 'ietf-types(a)iana.org' Cc: 'Garth Conboy'; 'John Rivlin'; 'Jon Ferraiolo' Subject: Community Review & IESG Approval of Media Type for OEBPS package standard To whom it may concern, As per the instructions for registering MIME types in the Standards tree with the IETG/IANA ( <ftp://ftp.rfc-editor.org/in-notes/rfc4288.txt> ftp://ftp.rfc-editor.org/in-notes/rfc4288.txt) I am submitting the following potential media type registration for preliminary community review with the aim of IESG approval before submission to the IANA. I am the Executive Director of a small standards organization devoted to digital texts and electronic books called the International Digital Publishing Forum (www.idpf.org) We created and maintain a standard widely used by the publishing industry to create electronic books called the Open eBook Publication Structure (OEBPS). That specification can be found at http://www.idpf.org/oebps/oebps1.2/index.htm. The OEBPS specification states that there must be something called an OEBPS package file which specifies OEBPS documents, images, and other objects that make up an entire OEBPS publication. What we are looking to do is to formally register a MIME Type for this package file in the standards tree. Specifically, we are seeking to register the following MIME Type for the OEBPS package: "application/oebps-package+xml". If this submission requires additional information for community review and IESG approval, please let me know. Best, Nick Bogaty -- Nick Bogaty Executive Director International Digital Publishing Forum (IDPF) nbogaty(a)idpf.org www.idpf.org (212) 924-9081 direct (212) 208-0978 fax

3 2

Re: Request for reviewing audio, vidoe, text/rtp-enc-aescm128
by Magnus Westerlund 16 May '06

16 May '06

Russ Housley wrote: > Magnus: > > The security considerations clearly indicate the problems with AES > Counter Mode. There are alternatives that provide efficient integrity > protection. Why would we want to permit this fragile encryption mode > when robut alternatives are available? At a minimum, the registration > should tell us. > > Russ >> >> Security considerations: >> >> See considerations raised in RTP RFC 3550 [9] and any applicable >> profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS >> 26.234, Release 6, Annex K for comments on security issues. The main >> issues that exists are: >> >> - This RTP payload format only confidentiality protects the RTP >> payload, thus header information is leaked, similarly to SRTP. >> >> - The use of stream ciphers as AES CM and no integrity protection >> allows an attacker to purposefully attack the content of the encrypted >> RTP payload by switching individual bits. >> >> - The usage of selective encryption without integrity protection >> allows for an attacker to perform any replacements of complete RTP >> payloads and packets it desires. >> >> - The payload format makes the receiver vulnerable to denial of >> service attacks that inserts RTP packets into the stream, that the >> receiver then interprets as being encrypted thus wasting computational >> resources. To prevent this attack, authentication needs to be used. >> Okay, there is a integrity and authentication available for the transport using SRTP as part of the solution described in section K of TS 26.234. I can't remember why counter mode was chosen, I will try to refresh my mind by talking to some people. 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

1 0

Re: [cellml-discussion] Review solicited for application/cellml+xml
by Matt Halstead 10 May '06

10 May '06

There is nothing stopping anyone from storing the file with any extension, so my vote is ideally to have no extension at all since all we are doing is serving these files across a system that supports mime-types. I would prefer mounting a webdav folder than a local folder so that mime-type is available. People should be free to call it what they want. If they have more advanced file systems then various metadata frameworks can be employed automatically to determine file types and application installers can add their signatures to these local systems. A useful summary of some concepts is here : http://en.wikipedia.org/ wiki/File_type Lets just drop file extension altogether. They look ugly in RDF metadata URIs anyway :-) cheers Matt On 10/05/2006, at 5:55 PM, Alan Garny wrote: > Dear all, > > Please find my 2 cents worth of comments regarding Andrew's > Internet draft. > >> We have several reasons for not encouraging anything other >> than .xml as the file >> extension: >> 1) We have used .cml (which conflicted with other markup >> languages, like Chemical Markup Language) in the past, and >> changed to .xml. Having a history of too many file extensions >> makes it hard to encourage software vendors to stick with a >> particular one. > > Just for accuracy, I believe to be the one who started using .cml > in my > software (http://cor.physiol.ox.ac.uk/) Are there others who do so > too now? > > You mention that .cml conflicts with other markup languages, but I > would > argue that .xml conflicts with even more markup languages. > Personally, .cml > is not used on my system by anything else but for CellML files, so > I don't > have that conflict you mention, while it wouldn't be the case if my > CellML > files were to have the .xml extension. > > As for a history of file extensions, again, as far I can recall > (please > correct me if I am wrong), .xml has been the extension chosen for > CellML > files from day one. It's just me who has been some kind of a > dissident for > going for .cml from day one too (more on the reasons below). > >> 2) There is currently repository software which uses .xml, >> and changing this will likely create problems for (some) >> client software using the repositories. > > You will always have problems of some sort or another. To go from > CellML 1.0 > to 1.1 is not a trivial thing either, be it for the software > developer or > modeller. To change the file extension from .xml to whatever surely > is a > very trivial problem, at least of the kind that I would be glad to > deal with > on a daily basis, if they were to be the only problems I had to have! > >> 3) Many users of CellML like to edit their models as XML in a >> text editor. Using the XML extension allows this to work on >> systems which know nothing about CellML. > > Many CellML users like to edit their models as XML in a text > editor? Is that > really true? I certainly don't want to start an argument here, but > I somehow > think that my users would feel very strongly about having to modify > CellML > files using a simple text editor. I am, personally, very glad that > I don't > have to use a text editor, nothing worse than modifying a CellML > file than > using such an editor (very much error prone!). Allow me another > quick plug > in: have a look at COR and you might change your mind and never use > a text > editor in the future (though you might still want to do that once > in a while > for whatever reason). > > Also, it is very simple, on any operating system, to associate a > particular > extension to a particular problem. > >> 4) Using a specific extension encourages software vendors to >> rely on this file extension. Although all software developed >> at the Bioengineering Institute does not rely on a specific >> file extension, there is software developed elsewhere that >> will not open files which do not have a .cml file extension >> (even when the user specifically tries to open that file in >> the program), and I have heard that this is creating problems >> for users. > > I believe that it would have to be my software indeed... I have had > several > email exchanges with David Nickerson about this over the last few > years. In > a nutshell, the main reason I am rather reluctant about the idea of > using > .xml for CellML files is that by having using .cml, I can associate > that > extension to COR, while the same cannot really be done with .xml. > > My point is that COR has been designed from the beginning to be as > user > friendly as possible. It is something that is very high on our > agenda and > that has surely been very much appreciated by our users (from what I > know/understand, there is no way they would use a text editor to > edit CellML > files for instance). > > To make COR user friendly involved associating .cml files to COR, > because > all the users have to do to open a CellML file is, for instance, to > double > click on it rather than opening a program, then opening a CellML > file. It > may not be too much to do the latter, but why not make the user's life > easier if all that takes is associate an extension to a particular > program? > >> By having only a more generic file extension, we >> encourage software developers not to use the file extension >> to determine whether they should open a certain file, and >> instead look at the MIME type (where available) and/or the >> XML namespace. > > Yes, that could easily be done, but... :) > > Best regards, Alan. > > -- > University of Oxford, Department of Physiology, Anatomy and Genetics > Sherrington Building, Parks Road, Oxford, OX1 3PT, England > http://noble.physiol.ox.ac.uk/people/agarny/ > > _______________________________________________ > cellml-discussion mailing list > cellml-discussion(a)cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion

2 2