February 2007 - 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

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

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