- Ietf-types - example.com

Intending to register a new vendor type
by Michael Dixon 02 Apr '07

02 Apr '07

Hello, I am intending to register the MIME type application/vnd.fcsexpress.launchfile, and would appreciate any suggestions or comments on the following draft. Thank you for your time. Michael Dixon ----- Name : Michael Dixon Email : michael.dixon(a)denovosoftware.com MIME media type name : Application MIME subtype name : Vendor Tree - vnd.fcsexpress.launchfile Required parameters : N/A Optional parameters : N/A Encoding considerations : binary This media type may require encoding on transports not capable of handling binary. The current implementation is in fact XML, but as this may change in later versions, binary is being used for compatibility. Security considerations : The FCS Express Launchfile contains information used by FCS Express to connect to a server and download a data file. Since the server code is proprietary, and the data file is proprietary and contains no executable code, it is unlikely that a false server could be set up with hacked files that could cause any problems. Interoperability considerations : Microsoft Windows 98/2000/NT/XP/Vista. Published specification : N/A Applications which use this media : FCS Express. Additional information : 1. Magic number(s) : N/A 2. File extension(s) : .fe_launch 3. Macintosh file type code : N/A 4. Object Identifiers: N/A Person to contact for further information : 1. Name : Michael Dixon 2. Email : michael.dixon(a)denovosoftware.com Intended usage : Limited Use This is a proprietary file format only used by FCS Express. Author/Change controller : Michael Dixon

1 0

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

Request for review update of media types audio/3gpp and video/3gpp
by Magnus Westerlund 29 Mar '07

29 Mar '07

Hi, The two media types audio/3gpp and video/3gpp was defined in RFC 3839: ftp://ftp.rfc-editor.org/in-notes/rfc3839.txt With the publication of the codecs parameters in RFC 4281 (ftp://ftp.rfc-editor.org/in-notes/rfc4281.txt) these two media types should be updated to include this parameter. This 3GPP defined file format has also got a few more features, one include the capability of embedding other binary objects to be used in scene presentations created by SMIL or SVG to achieve self contained units. Due to this the RFC authors and 3GPP document editor has also proposed to add another parameter similar to codecs that identifies the type of binary objects embedded in the file. When performing this update it is also intended to move the Media Type definitions from the RFC into the file format specification document in 3GPP. The current file format specification is 3GPP TS 26.244: http://www.3gpp.org/ftp/Specs/archive/26_series/26.244/26244-700.zip So please review the following document containing the proposed Media Types. http://www.denstore.se/IETF/3GP-mime-reg.pdf We appreciate comments by Monday the 8th of January. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 1

Request to review Media Type */rtp-enc-aescm128 for 3GPP
by Magnus Westerlund 29 Mar '07

29 Mar '07

Hi, The following Media Type was discussed on the list at the end of 2004. Time to finally register it. I intend to request IESG to approve registration following the SDO rules on the 6th of October. So if someone has strong objections against this speak up before then. The filled in registration template is from 3GPP TS 26.234 V.6.8.0: http://www.3gpp.org/ftp/Specs/archive/26_series/26.234/26234-680.zip K.1.4.1 MIME type definition 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 -- 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

2 5

Registration of MIME media type application/pkcs8 (possible resubmit)
by Dean Willis 12 Mar '07

12 Mar '07

It's possible that this has been previously brought to this list -- if so, please slap me around appropriately and point me at the review. I was unable to locate it in the mailing list archives. I'm working through a PROTO writeup on: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-03.txt which contains the following MIME type registration. --------- Subject: Registration of MIME media type application/pkcs8 MIME media type name: application MIME subtype name: pkcs8 Required parameters: None Optional parameters: None Encoding considerations: The PKCS#8 object inside this MIME type MUST be DER-encoded. This MIME type was designed for use with protocols which can carry binary-encoded data. Protocols which do not carry binary data (which have line length or character-set restrictions for example) MUST use a reversible transfer encoding (such as base64) to carry this MIME type. Protocols that carry binary data SHOULD use a transfer encoding of "binary". Security considerations: Carries a cryptographic private key Interoperability considerations: None Published specification: RSA Laboratories, "Private-Key Information Syntax Standard, Version 1.2", PKCS 8, November 1993. Applications which use this media type: Any MIME-compliant transport Additional information: Magic number(s): None File extension(s): .p8 Macintosh File Type Code(s): none Person & email address to contact for further information: Cullen Jennings <fluffy(a)cisco.com> Intended usage: COMMON Author/Change controller: the IESG -- Dean Willis

2 1

news-message-ID review request
by Frank Ellermann 19 Feb '07

19 Feb '07

Hi, the following is probably (I'm new to this list) unusual, it will be published in the "IANA considerations" of I-D.ellermann-news-nntp-uri-05, see <http://purl.net/xyzzy/home/test/draft-ellermann-news-nntp-uri-05.txt> ~~~ cut ~~~ 8.3. 'news-message-ID' access type The MIME 'news-message-ID' access type was erroneously listed as subtype. IANA should remove 'news-message-ID' from the application subtype registry, and add it to the access type registry defined in [RFC4289]: <http://www.iana.org/assignments/access-types>. [RFC4289] requires an RFC for the access types registry. Because [son-of-1036] was never published as RFC the following paragraph quotes the relevant definition: NOTE: In the specific case where it is desired to essentially make another article PART of the current one, e.g. for annotation of the other article, MIME's "message/external-body" convention can be used to do so without actual inclusion. "news-message-ID" was registered as a standard external-body access method, with a mandatory NAME parameter giving the message ID and an optional SITE parameter suggesting an NNTP site that might have the article available (if it is not available locally), by IANA 22 June 1993. Please note that 'news' URLs offer a very similar and (today) more common way to access articles by their Message-ID, compare [RFC2017]. ~~~ end ~~~ Is that good enough to fix this (very old, 1993) mess ? Frank

2 2

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

Last call for review comments for audio/sp-midi
by timo.kosonen＠nokia.com 10 Jan '07

10 Jan '07

Please, review http://www.ietf.org/internet-drafts/draft-kosonen-sp-midi-mediatype-02.t xt. It is the third version of the draft. This is the final call. Please provide any review comments for the internet draft above at the latest by the 16th of January 2007. The differences between draft-kosonen-sp-midi-mediatype-01.txt and draft-kosonen-sp-midi-mediatype-02.txt are: -Dates have been updated. -Normative references and Informative references became sections instead of subsections. -Copyright notice was updated. Best Regards, Timo Kosonen

2 3

Request for comments on Media Type section of "Web Services Policy 1.5 - Framework" W3C Working Draft
by Felix Sasaki 19 Dec '06

19 Dec '06

Hello, this is a request for comments on the Media Type section of the "Web Services Policy 1.5 - Framework" W3C Last Call Working Draft. The section is at http://www.w3.org/TR/2006/WD-ws-policy-20061117/#media-type and as plain text below. Thank you very much. Regards, Felix Sasaki A. The application/wspolicy+xml Media Type This appendix defines the "application/wspolicy+xml" media type which can be used to describe Web Services Policy documents serialized as XML. Either wsp:Policy or wsp:PolicyAttachment could be the root element of such a document. A.1 Registration MIME media type name: application MIME subtype name: wspolicy+xml Required parameters: none Optional parameters: charset This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in RFC 3023. Encoding considerations: Identical to those of "application/xml" as described in RFC 3023, section 3.2, as applied to the Web Services Policy document Infoset. Security considerations: See section 5. Security Considerations in this document, and the Security Consideration section in Web Services Policy Attachment. Interoperability considerations: There are no known interoperability issues. Published specifications: This document and Web Services Policy Attachment. Applications which use this media type: This new media type is being registered to allow for deployment of Web Services Policy and references to Web Services Policy on the World Wide Web. Additional information: File extension: wspolicy Fragment identifiers: A syntax identical to that of "application/xml" as described in RFC 3023. Base URI: As specified in RFC 3023, section 6. Macintosh File Type code: WSPOLICY Person and email address to contact for further information: World Wide Web Consortium <web-human(a)w3.org> Intended usage: COMMON Author/Change controller: The Web Services Policy 1.5 specification set is a work product of the World Wide Web Consortium's Web Service Policy Working Group. The W3C has change control over these specifications.

2 3

Request for review of "application/pidf-diff+xml" media type
by Jari Urpalainen 20 Nov '06

20 Nov '06

Hi ! This is to request comments on media type "application/pidf-diff+xml" registration, the i-d in question is <http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-0…> 5. IANA Considerations This memo calls for IANA to: o register a new XML namespace URN per [6]. o register a new content type 'application/pidf-diff+xml' per RFC2048 [12]. o register a new XML Schema URN per [6]. 5.1. Content-type registration for 'application/pidf-diff+xml' Type name: application Subtype name: pidf-diff+xml Required parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [10], section 3.2. Security considerations: This content type is designed to carry presence data, which may be considered private information. Appropriate precautions should be adopted to limit disclosure of this information. Please refer to [[[RFCXXXX]]] security considerations section for more information. Interoperability considerations: none Published specification: [[[RFCXXXX]]] Applications which use this media type: SIP-based presence systems Additional information: Magic Number: None File Extension: .xml Macintosh file type code: "TEXT" Personal and email address for further information: Jari Urpalainen, jari.urpalainen(a)nokia.com Intended usage: LIMITED USE Restrictions on usage: Presence [3] based systems. Author: This specification is a work item of the IETF SIMPLE working group, with mailing list address <simple(a)ietf.org>. Change controller: IETF. thanks, Jari

1 0