Internet Draft R. Gellens Document: draft-gellens-mime-bucket-01.txt Qualcomm Expires: April 2005 October 2004 The Codecs Parameter for "Bucket" Media Types Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed and any of which I become aware will be disclosed, in accordance with RFC 3668 (BCP 79). By submitting this Internet-Draft, I accept the provisions of Section 3 of RFC 3667 (BCP 78). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Several MIME type/subtype combinations exist which can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered. Gellens [Page 1] Expires April 2005 Internet Draft The Codecs Parameter October 2004 This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs required to support the media formats contained within. By labelling content with the specific codecs required to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, etc.) Gellens [Page 2] Expires April 2005 Internet Draft The Codecs Parameter October 2004 Table of Contents 1. Conventions Used in this Document . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Codecs Parameter . . . . . . . . . . . . . . . . . . . . 5 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Additional Media Feature Details . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 10. Informative References . . . . . . . . . . . . . . . . . . 9 11. Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property Statement . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Conventions Used in this Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 2. Introduction One of the original motivations for MIME is the ability to identify the specific media type of a message part. However, due to various factors, it is not always possible from looking at the MIME type and subtype to know which specific media formats are contained in the body part, or which codecs are required in order to display the content. There are several media type/subtypes (either currently registered or deployed with registration pending) which may contain codecs chosen from a set. It is currently necessary to examine each media element in order to determine the codecs required to render the content. For example, video/3gpp may contain any of the video formats H.263, H.263+, H.264, MPEG-4 SPL0, and/or any of the audio formats AMR, AMR-WB, or AAC, as specified in [3GPP-Formats]. Gellens [Page 3] Expires April 2005 Internet Draft The Codecs Parameter October 2004 In some cases, the specific codecs can be determined by examining the header information of the media content. While this isn't as bad as examining the entire content, it still requires specialized knowledge of each format and is resource consumptive. This ambiguity can be a problem for various clients and servers. It presents a significant burden to Multimedia Messaging (MMS) servers, which must examine the media sent in each message in order to determine which codecs are required to render the content. Only then can it determine if the content requires transcoding or specialized handling prior to being transmitted to the handset. Additionally, it presents a challenge to smart clients on devices with constrained memory, processing power, or transmission bandwidth (such as cellular telephones and PDAs). Such clients often need to determine in advance if they are currently capable of rendering the content contained in an MMS or email message. Specifically, o audio/3gpp can contain AMR or AAC contents as specified in [3GPP-Formats]. o audio/3gpp2 can contain AMR, AAC, 13K (as per [13k]), EVRC, or SMV, as specified in [3GPP2-Formats] (video/3gpp2 MIME registration pending). o video/3gpp can contain H.263, H.263+, H.264, MPEG-4 SPL0, and/or AMR, AMR-WB, or AAC, as specified in [3GPP-Formats]. o video/3gpp2 can contain H.263, H.263+, H.264, MPEG-4 SPL0, and/or AMR, AAC, 13K (as per [13k]), EVRC, or SMV, as specified in [3GPP2-Formats] (video/3gpp2 MIME registration pending). Note that there are additional media types which are ambiguous, but are outside the scope of this document, including: o video/mp4V-ES and video/mpeg4-generic which can contain anything allowed by the MPEG-4 specification, or any audio codec registered with the MP4 registration authority [MP4-Reg]. o video/quicktime which can contain anything for which there is a QuickTime codec component; since QuickTime is extensible, this is not limited to the codecs that are or have been shipped by Apple Computer. With each "bucket" type, a receiving agent only knows that it has a container format. It doesn't even know whether content labelled video/3GPP or video/3GPP2 contains video; it might be audio only, audio and video, or video only. Gellens [Page 4] Expires April 2005 Internet Draft The Codecs Parameter October 2004 A solution which permits a receiving agent to determine the specific codecs required to render media content would help provide efficient and scalable servers, especially for Multimedia Messaging (MMS), and aid the growth of multimedia services in wireless networks. 3. The Codecs Parameter This document adds a parameter to allow unambiguous specification of the codecs required to render the content in a media element. This parameter is optional in all current types to which it is added. Future types which contain ambiguity are strongly encouraged to include this parameter, as mandatory if possible, as optional otherwise. Media types: audio/3gpp, audio/3gpp2*, video/3gpp, video/3gpp2*, *registration pending Parameter name: Codecs Parameter value: A single value, or a comma-separated list of values (which must be enclosed in quotes to comply with MIME rules) which identifies the codec(s) required to render the content in the body part. Each value consists of one or more dot-separated elements. The name space for the first element is determined by the MIME type. The name space for each subsequent element is determined by the preceding element. Examples of Generic Syntax: a.bb.c.d "a.bb, c.dd" Initial name space: This document only defines values for files in the ISO File Format family. Other file formats may also define codec naming. Gellens [Page 5] Expires April 2005 Internet Draft The Codecs Parameter October 2004 For the ISO File format, the first element is a sample description entry four-character code as registered by the MP4 Registration Authority [MP4-Reg]. The values are case-sensitive. For the name 'mp4a', indicating some kind of MPEG-4 audio, the second element is the hexadecimal representation of the MP4 Registration Authority ObjectTypeIndication (OTI) [MP4-Reg] (e.g., the element "0x20"). Syntax: codecs = "Codecs" *SP "=" *SP value value = id / DQUOTE *SP id *(*SP "," *SP id) *SP DQUOTE id = id-ISO / id-gen id-gen = element *( "." element ) id-ISO = cpid [ "." oti ] cpid = 4 (idchar / idchar-spec) oti = "0x" 2HEXDIG element = 1*(idchar / idchar-spec) idchar = <any (US-ASCII) CHAR except SPACE, CTLs, "$", or tspecials> idchar-spec = "$" 2DIGIT tspecials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" Note that in some cases, the four-character ID registered in [MP4-Reg] may still be ambiguous, even when using the OTI. For example, all mpeg-4 audio codecs are under 'mp4a', including HVXC, CELP, GA (which can be AAC, twinVQ, or BSAC), SA, TTSI, HILN (see MP4A). However, since audio/3gpp2, video/3gpp2, audio/3gpp, and video/3gpp restrict the allowable ISO code points, there is no ambiguity in these four cases. Gellens [Page 6] Expires April 2005 Internet Draft The Codecs Parameter October 2004 When the Codecs parameter is used, it MUST contain all codecs required to render all content present in the body part. The Codecs parameter MUST NOT contain any codecs which are not present in the body part. 4. Examples Content-Type: Video/3GPP2; Codecs="sevc, s263" (EVRC audio plus H.263 video) Content-Type: Audio/3gp; Codecs=samr (AMR audio) Content-Type: video/3gpp; Codecs="s263, samr" (H.263 video plus AMR audio) Content-Type: audio/3gpp2; Codecs=mp4a.0xE1 (13k audio) Content-Type: video/3gpp2; Codecs="mp4v.0x20, mp4a.0xE1" (Visual ISO/IEC 14496-2 [MP4V] plus 13K voice) Note: 0x20 OTI value says "Includes associated Amendment(s) and Corrigendum(a). The actual object types are defined in ISO/IEC 14496-2 and are conveyed in the DecoderSpecificInfo as specified in ISO/IEC 14496-2, Annex K." 5. Additional Media Feature Details For the same reasons that the Codecs parameter is useful, it is sometimes helpful to provide additional details for a media element (e.g., the number of X and Y pixels, the color depth, etc.). These details are sometimes called "media features" and sometimes "media characteristics". When such additional features are included, the [Content-Features] header provides a handy way to do so. 6. IANA Considerations The hard-working IANA staff is kindly requested to add "Codecs" as an optional parameter to the media types listed in Section 3, with a reference to this document Gellens [Page 7] Expires April 2005 Internet Draft The Codecs Parameter October 2004 7. Security Considerations The codecs parameter itself does not alter the security considerations of any of the media types for which it is available. Each audio and video media type has its own set of security considerations which continue to apply, regardless of the use of the codecs parameter. An incorrect codecs parameter might cause media content to be received by a device which is not capable of rendering it, or might cause media content to not be sent to a device which is capable of receiving it. An incorrect codecs parameter is therefore capable of some types of denial of service attacks. However, this is most likely to arise by accident, as an attacker capable of altering media data in transit could cause more harm by altering the media format itself, or even the content type header, rather than just the codecs parameter of the content type header. 8. Acknowledgements David Singer and Harinath Garudadri provided significant help, which is very much appreciated. 9. Normative References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., November 1997. [Content-Features] Kline, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000. [MIME-Types] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [Media-Features] Holtman, K., A. Mutz and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, BCP 31, March 1999. Gellens [Page 8] Expires April 2005 Internet Draft The Codecs Parameter October 2004 [MP4-reg] MP4REG, The MPEG-4 Registration Authority, <url://www.mp4ra.org> 10. Informative References [13k] Gellens, R and H. Garudadri, "The QCP File Format and Media Types for Speech Data", RFC 3625, September 2003. [AMR] Sjoberg, J., M. Westerlund, A. Lakaniemi, Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002. [3GPP-Codecs] TS 26.234, Third Generation Partnership Project (3GPP), "Transparent end-to-end streaming service; Protocols and codecs", URL: <http://www.3gpp.org/ftp/Specs/html-info/26234.htm> [3GPP-Formats] TS 26.244, Third Generation Partnership Project (3GPP), "Transparent end-to-end streaming service; 3GPP file format (3GP)", URL: <http://www.3gpp.org/ftp/Specs/html-info/26244.htm> [3GPP2-Formats] Third Generation Partnership Project 2, "3GPP2 File Formats for Multimedia Service", URL: <http://www.3gpp2.org/Public_html/specs/C.S0050-0_v1.0_121503.pdf> [MP4A] ISO/IEC 14496-3:2001, "Information Technology--Coding of Audio/Visual Object--Part 3: Audio". [MP4V] ISO/IEC 14496-2:2001, "Information Technology--Coding of Audio/Visual Object--Part 2: Video". 11. Author's Address Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA randy@qualcomm.com Gellens [Page 9] Expires April 2005 Internet Draft The Codecs Parameter October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Gellens [Page 10] Expires April 2005
Datatracker
draft-gellens-mime-bucket-01
This is an older version of an Internet-Draft that was ultimately published as RFC 4281.
