From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4281.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc4281.txt (limited to 'doc/rfc/rfc4281.txt') diff --git a/doc/rfc/rfc4281.txt b/doc/rfc/rfc4281.txt new file mode 100644 index 0000000..97ae375 --- /dev/null +++ b/doc/rfc/rfc4281.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group R. Gellens +Request for Comments: 4281 Qualcomm +Category: Standards Track D. Singer + Apple + P. Frojdh + Ericsson + November 2005 + + + The Codecs Parameter for "Bucket" Media Types + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Several MIME type/subtype combinations exist that 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. + + This document adds a new parameter, "codecs", to various type/subtype + combinations to allow for unambiguous specification of the codecs + indicated by the media formats contained within. + + By labeling content with the specific codecs indicated 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, further inspection to determine if it + will be sufficient to support a subset of the indicated codecs, etc.) + + + + + + + +Gellens, et al. Standards Track [Page 1] + +RFC 4281 The Codecs Parameter November 2005 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions Used in This Document ...............................4 + 3. The Codecs Parameter ............................................4 + 3.1. Generic Syntax .............................................5 + 3.2. ISO File Format Name Space .................................7 + 3.3. ISO Syntax .................................................8 + 4. Use in Additional Media Types ...................................8 + 5. Examples ........................................................9 + 6. Additional Media Feature Details ................................9 + 7. IANA Considerations .............................................9 + 8. Security Considerations .........................................9 + 9. Acknowledgements ...............................................10 + 10. Normative References ..........................................10 + 11. Informative References ........................................10 + +1. 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 indicated in order to render the + content. + + There are several media type/subtypes (either currently registered or + deployed with registration pending) that 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 + Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or any + of the audio formats Adaptive Multi Rate (AMR), Adaptive Multi Rate - + WideBand (AMR-WB), Extended AMR-WB, Advanced Audio Coding (AAC), or + Enhanced aacPlus, as specified in [3GPP-Formats]. + + 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 such a server determine if the content requires transcoding or + specialized handling prior to being transmitted to the handset. + + + + +Gellens, et al. Standards Track [Page 2] + +RFC 4281 The Codecs Parameter November 2005 + + + 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. + + Current ambiguity: + + o audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or + Enhanced aacPlus contents as specified in [3GPP-Formats]. + o audio/3gpp2 can contain AMR, AAC, 13K (as per [13k]), Enhanced + Variable Rate Codec (EVRC), Selectable Mode Vocoder (SMV), + or VMR-WB, as specified in [3GPP2-Formats]. + o video/3gpp can contain H.263 Profile 0, H.263 Profile 3, H.264, + MPEG-4 Simple Profile, and/or AMR, AMR-WB, Extended AMR-WB, AAC, + or Enhanced aacPlus, as specified in [3GPP-Formats]. + o video/3gpp2 can contain H.263 Profile 0, H.263 Profile 3, H.264, + MPEG-4 Simple Profile, and/or AMR, AAC, 13K (as per [13k]), + EVRC, SMV, or VMR-WB, as specified in [3GPP2-Formats]. + + Note that there are additional media types that are ambiguous, but + are outside the scope of this document, including: + + o video/mpeg4-generic, which can contain anything allowed by the + MPEG-4 specification, or any 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 labeled + video/3gpp or video/3gpp2 contains video; it might be audio only, + audio and video, or video only. + + A solution that 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. + + + + + + + + + + + +Gellens, et al. Standards Track [Page 3] + +RFC 4281 The Codecs Parameter November 2005 + + +2. 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]. + + The syntax in this document uses the BNF rules specified in + [MIME-Format] and [MIME-Coding]. + +3. The Codecs Parameter + + This document adds a parameter to allow unambiguous specification of + all codecs indicated to render the content in the MIME part. This + parameter is optional in all current types to which it is added. + Future types that contain ambiguity are strongly encouraged to + include this parameter. + + Media types: + audio/3gpp, + audio/3gpp2, + video/3gpp, + video/3gpp2, + + Parameter name: + Codecs + + Parameter value: A single value, or a comma-separated list of values + identifying the codec(s) indicated 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. + + Note that, per [MIME-Format], some characters (including the + comma used to separate multiple values) require that the entire + parameter value be enclosed in quotes. + + An element MAY include an octet that must be encoded in order to + comply with [MIME-Format]. In this case, [MIME-Coding] is used: + an asterisk ("*") is placed at the end of the parameter name + (becoming "codecs*" instead of "codecs"), the parameter value + usually starts with two single quote ("'") characters + (indicating that neither character set nor language is + specified), and each octet that requires encoding is represented + as a percent sign ("%") followed by two hexadecimal digits. + Note that, when the [MIME-Coding] form is used, the percent + + + +Gellens, et al. Standards Track [Page 4] + +RFC 4281 The Codecs Parameter November 2005 + + + sign, asterisk, and single quote characters have special meaning + and so must themselves be encoded. + + Examples of Generic Syntax: + codecs=a.bb.ccc.d + codecs="a.bb.ccc.d, e.fff" + codecs*=''fo%2e + codecs*="''%25%20xz, gork" + + When the Codecs parameter is used, it MUST contain all codecs + indicated by the content present in the body part. The Codecs + parameter MUST NOT include any codecs that are not indicated by any + media elements in the body part. + + In some cases, not all indicated codecs are absolutely required in + order to render the content. Therefore, when a receiver does not + support all listed codecs, special handling MAY be required. For + example, the media element(s) MAY need to be examined in order to + determine if an unsupported codec is actually required (e.g., there + may be alternative tracks (such as English and Spanish audio), there + may be timed text that can be dropped, etc.) + + NOTE: Although the parameter value MUST be complete and accurate in + 'breadth' (that is, it MUST report all four-character codes used in + all tracks for ISO-family files, for example) systems MUST NOT rely + on it being complete in 'depth'. If the hierarchical rules for a + given code (e.g., 'qvxy') were written after a server was + implemented, for example, that server will not know what elements to + place after 'qvxy'. + + If a receiver encounters a body part whose Codecs parameter contains + codecs that are not indicated by any media elements, then the + receiver SHOULD process the body part by discarding the information + in the Codecs parameter. + + If a receiver encounters a body part whose Codecs parameter does not + contain all codecs indicated by the media elements, then the receiver + MAY process the body part by discarding the information in the Codecs + parameter. + +3.1. Generic Syntax + + The Codecs parameter takes either of two forms. The first form is + used when the value does not contain any octets that require + encoding. The second form uses [MIME-Coding] to allow arbitrary + octets to be encoded. With either form, quotes allow for commas and + other characters in (quotes MAY be used even when not + required). + + + +Gellens, et al. Standards Track [Page 5] + +RFC 4281 The Codecs Parameter November 2005 + + + This BNF uses the rules specified in [MIME-Format] and [MIME-Coding]. + + Implementations MUST NOT add CFWS between the tokens except after + ",". + + codecs := cod-simple / cod-fancy + + cod-simple := "codecs" "=" unencodedv + + unencodedv := id-simple / simp-list + + simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE + + id-simple := element + ; "." reserved as hierarchy delimiter + + element := 1*octet-sim + + octet-sim := + ; defined in [MIME-Format] + ; + ; Within a Codecs parameter value, "." is reserved + ; as a hierarchy delimiter + + cod-fancy := "codecs*" ":=" encodedv + + encodedv := fancy-sing / fancy-list + + fancy-sing := [charset] "'" [language] "'" id-encoded + ; Parsers MAY ignore + ; Parsers MAY support only US-ASCII and UTF-8 + + fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE + ; Parsers MAY ignore + ; Parsers MAY support only US-ASCII and UTF-8 + + id-list := id-encoded *( "," id-encoded ) + + id-encoded := encoded-elm *( "." encoded-elm ) + ; "." reserved as hierarchy delimiter + + encoded-elm := 1*octet-fancy + + octet-fancy := ext-octet / attribute-char + ; and defined in + ; [MIME-Coding] + + DQUOTE := %x22 ; " (double quote) + + + +Gellens, et al. Standards Track [Page 6] + +RFC 4281 The Codecs Parameter November 2005 + + + Initial name space: This document only defines values for files in + the ISO Base Media File Format family. Other file formats may also + define codec naming. + +3.2. ISO File Format Name Space + + For the ISO Base Media File Format, the first element of a Codecs + parameter value is a sample description entry four-character code as + registered by the MP4 Registration Authority [MP4-Reg]. Values are + case sensitive. + + Note that there are potentially multiple tracks in a file, each + potentially carrying multiple sample entries (some but not all uses + of the ISO File Format restrict the number of sample entries in a + track to one). + + When the first element of a value is 'mp4a' (indicating some kind of + MPEG-4 audio) or 'mp4v' (indicating some kind of MPEG-4 part-2 + video), the second element is the hexadecimal representation of the + MP4 Registration Authority ObjectTypeIndication (OTI), as specified + in [MP4-Reg] and [MP41] (including amendments). Note that [MP4-Reg] + uses a leading "0x" with these values, which is omitted here and + hence implied. + + One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio). + For this value, the third element identifies the audio + ObjectTypeIndication (OTI) as defined in [MP4A] (including + amendments), expressed as a decimal number. + + For example, AAC low complexity has the value 2, so a complete + string for AAC-LC would be "mp4a.40.2". + + One of the OTI values for 'mp4v' is 20 (identifying MPEG-4 part-2 + video). For this value, the third element identifies the video + ProfileLevelIndication as defined in [MP4V] (including amendments), + expressed as a decimal number. + + For example, MPEG-4 Visual Simple Profile Level 0 has the value 9, + so a complete string for MPEG-4 Visual Simple Profile Level 0 would + be "mp4v.20.9". + + + + + + + + + + + +Gellens, et al. Standards Track [Page 7] + +RFC 4281 The Codecs Parameter November 2005 + + +3.3. ISO Syntax + + id-simple :=/ id-iso + + id-encoded :=/ id-iso + + id-iso := iso-gen / iso-mpega / iso-mpegv + + iso-gen := cpid *( element / encoded-elm ) + ; used with + ; used with + ; + ; Note that the BNF permits "." within + ; and but "." is reserved as the + ; hierarchy delimiter + + iso-mpega := mp4a "." oti [ "." aud-oti ] + iso-mpegv := mp4v "." oti [ "." vid-pli ] + + cpid := 4(octet-simple / octet-fancy) + ; used with + ; used with + + mp4a := %x6d.70.34.61 ; 'mp4a' + + oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + ; leading "0x" omitted + + aud-oti := 1*DIGIT + + mp4v := %x6d.70.34.76 ; 'mp4v' + vid-pli := 1*DIGIT + +4. Use in Additional Media Types + + This parameter MAY be specified for use with additional MIME media + types. + + For ISO file formats where the name space as defined here is + sufficient, all that needs to be done is to update the media type + registration to specify the Codecs parameter with a reference to this + document. For existing media types, it is generally advisable for + the parameter to be optional; for new media types, the parameter MAY + be optional or required, as appropriate. + + For ISO file formats where the name space as defined here needs to be + expanded, a new document MAY update this one by specifying the + additional detail. + + + +Gellens, et al. Standards Track [Page 8] + +RFC 4281 The Codecs Parameter November 2005 + + + For non-ISO formats, a new document MAY update this one by specifying + the name space for the media type(s). + +5. Examples + + Content-Type: video/3gpp2; codecs="sevc, s263" + (EVRC audio plus H.263 video) + Content-Type: audio/3gpp; codecs=samr + (AMR audio) + Content-Type: video/3gpp; codecs="s263, samr" + (H.263 video plus AMR audio) + Content-Type: audio/3gpp2; codecs=mp4a.E1 + (13k audio) + Content-Type: video/3gpp2; codecs="mp4v.20.9, mp4a.E1" + (MPEG-4 Visual Simple Profile Level 0 plus 13K voice) + + Note: OTI value 20 ("0x20" in [MP4-Reg]) says "Includes + associated Amendment(s) and Corrigendum(a). The actual object + types are defined in [MP4V] and are conveyed in the + DecoderSpecificInfo as specified in [MP4V], Annex K." + (references adjusted). + +6. Additional Media Feature Details + + 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" or "media + characteristics". + + When such additional features are included, the [Content-Features] + header provides a handy way to do so. + +7. IANA Considerations + + The IANA has added "codecs" as an optional parameter to the media + types listed in Section 3, with a reference to this document. + +8. Security Considerations + + The Codecs parameter itself does not alter the security + considerations of any of the media types with which it is used. Each + audio and video media type has its own set of security considerations + that 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 that is not capable of rendering it, or might + cause media content to not be sent to a device that is capable of + + + +Gellens, et al. Standards Track [Page 9] + +RFC 4281 The Codecs Parameter November 2005 + + + 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. + +9. Acknowledgements + + Harinath Garudadri provided a great deal of help, which is very much + appreciated. Mary Barnes and Bruce Lilly provided detailed and + helpful comments. Reviews and comments by Sam Hartman, Russ Housley, + and Bert Wijnen were much appreciated. Chris Newman carefully + reviewed and improved the BNF. + +10. Normative References + + [Content-Features] Klyne, G., "Indicating Media Features for MIME + Content", RFC 2912, September 2000. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [MIME-Coding] Freed, N. and K. Moore, "MIME Parameter Value and + Encoded Word Extensions: Character Sets, + Languages, and Continuations", RFC 2231, November + 1997. + + [MIME-Format] Freed, N. and N. Borenstein, "Multipurpose + Internet Mail Extensions (MIME) Part One: Format + of Internet Message Bodies", RFC 2045, November + 1996. + + [Media-Features] Holtman, K., Mutz, A., and T. Hardie, "Media + Feature Tag Registration Procedure", BCP 31, RFC + 2506, March 1999. + + [MP4-Reg] MP4REG, The MPEG-4 Registration Authority, URL: + . + +11. Informative References + + [13k] Gellens, R. and H. Garudadri, "The QCP File Format + and Media Types for Speech Data", RFC 3625, + September 2003. + + + + + +Gellens, et al. Standards Track [Page 10] + +RFC 4281 The Codecs Parameter November 2005 + + + [3GPP-Formats] TS 26.244, Third Generation Partnership Project + (3GPP), "Transparent End-to-End Packet Switched + Streaming Service; 3GPP file format (3GP)", URL: + . + + [3GPP2-Formats] Third Generation Partnership Project 2, "3GPP2 + File Formats for Multimedia Service", URL: + . + + [MP41] ISO/IEC 14496-1:2004, "Information technology-- + Coding of audio-visual objects--Part 1: Systems". + + [MP4A] ISO/IEC 14496-3:2001, "Information technology-- + Coding of audio-visual objects--Part 3: Audio". + + [MP4V] ISO/IEC 14496-2:2004, "Information technology-- + Coding of audio-visual objects--Part 2: Visual". + +Authors' Addresses + + Randall Gellens + QUALCOMM Incorporated + 5775 Morehouse Drive + San Diego, CA 92121 + USA + + EMail: randy@qualcomm.com + + + David Singer + Apple Computer, Inc. + One Infinite Loop, MS:302-3MT + Cupertino CA 95014 + USA + + EMail: singer@apple.com + Phone: +1 408 974 3162 + + + Per Frojdh + Ericsson Research + Multimedia Technologies + SE-164 80 Stockholm, SWEDEN + + EMail: Per.Frojdh@ericsson.com + Phone: +46 8 7190000 + + + +Gellens, et al. Standards Track [Page 11] + +RFC 4281 The Codecs Parameter November 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + 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. + + 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Gellens, et al. Standards Track [Page 12] + -- cgit v1.2.3