diff options
Diffstat (limited to 'doc/rfc/rfc6381.txt')
| -rw-r--r-- | doc/rfc/rfc6381.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc6381.txt b/doc/rfc/rfc6381.txt new file mode 100644 index 0000000..78f850e --- /dev/null +++ b/doc/rfc/rfc6381.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Gellens +Request for Comments: 6381 QUALCOMM, Inc. +Obsoletes: 4281 D. Singer +Updates: 3839, 4337, 4393 Apple, Inc. +Category: Standards Track P. Frojdh +ISSN: 2070-1721 Ericsson AB + August 2011 + + + The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types + +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 is helpful to know from the Content- + Type alone if the content can be rendered. + + This document specifies two parameters, 'codecs' and 'profiles', that + are used with various MIME types or type/subtype combinations to + allow for unambiguous specification of the codecs employed by the + media formats contained within, or the profile(s) of the overall + container format. This document obsoletes RFC 4281; RFC 4281 defines + the 'codecs' parameter, which this document retains in a backwards + compatible manner with minor clarifications; the 'profiles' parameter + is added by this document. + + 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.). + + Similarly, the profiles can provide an overall indication, to the + receiver, of the specifications with which the content complies. + This is an indication of the compatibility of the container format + and its contents to some specification. The receiver may be able to + work out the extent to which it can handle and render the content by + examining to see which of the declared profiles it supports, and what + they mean. + + + + + +Gellens, et al. Standards Track [Page 1] + +RFC 6381 MIME Codecs and Profiles August 2011 + + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6381. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 2] + +RFC 6381 MIME Codecs and Profiles August 2011 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions Used in This Document ...............................5 + 3. The 'Codecs' Parameter ..........................................5 + 3.1. Introduction ...............................................5 + 3.2. Generic Syntax .............................................7 + 3.3. ISO Base Media File Format Name Space ......................8 + 3.4. ISO-Family Syntax .........................................11 + 3.5. Use in Additional Media Types .............................11 + 3.6. Examples ..................................................12 + 3.7. Additional Media Feature Details ..........................12 + 4. The 'Profiles' Parameter .......................................12 + 4.1. Introduction ..............................................12 + 4.2. Formal Declaration ........................................13 + 4.3. 'Profiles' Parameter Definition ...........................14 + 4.4. Profiles for Files Carrying MP4RA-Registered Brands .......14 + 4.5. 'Profiles' Parameter BNF Definition .......................15 + 5. IANA Considerations ............................................15 + 6. Registration ...................................................15 + 7. Security Considerations ........................................16 + 8. Differences from RFC 4281 ......................................16 + 9. Acknowledgements ...............................................17 + 10. References ....................................................17 + 10.1. Normative References .....................................17 + 10.2. Informative References ...................................18 + +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. In the absence of the parameters described here, it is + necessary to examine each media element in order to determine the + codecs or other features 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]. + + + + + +Gellens, et al. Standards Track [Page 3] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + 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. For + example, 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. + + 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. + + 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 [RFC3625]), Enhanced + Variable Rate Codec (EVRC), Selectable Mode Vocoder (SMV), or + Variable Multi Rate WideBand (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 [RFC3625]), + EVRC, SMV, or VMR-WB, as specified in [3GPP2-Formats]. + + o audio/mp4 can include any codec defined in MPEG-1, MPEG-2, MPEG-4 + or registered at the MP4 registration authority [MP4RA]. + + o video/mp4 has the same issues as audio/mp4, and in addition many + video codecs, and especially the MPEG codecs, have a variety of + profiles and levels, not all of which are supported by every + implementation. + + + + + + + +Gellens, et al. Standards Track [Page 4] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + 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 [MP4RA]; + + With each "bucket" type, a receiving agent only knows that it has a + container format. It doesn't even know whether content that is + 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 or profiles 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. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in "Key words for use in + RFCs to Indicate Requirement Levels" [RFC2119] . + + The syntax in this document uses the BNF rules specified in [RFC2045] + and [RFC2231]. + +3. The 'Codecs' Parameter + +3.1. Introduction + + This section 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. + + This parameter applies to: + + 1. Files in the family based on the ISO Base Media File Format + [ISO14496-12] called "ISO family files" in this specification. + + 2. The QuickTime file format, owned by Apple, Inc. + + This includes the media types: + + 1. audio/3gpp, video/3gpp [RFC3839] + + + +Gellens, et al. Standards Track [Page 5] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + 2. audio/3gpp2, video/3gpp2 [RFC4393] + + 3. audio/mp4, video/mp4, application/mp4 [RFC4337] + + 4. video/quicktime + + 5. application/mp21 (see note below) + + Note that MPEG-21 files under the type application/mp21 may, but are + not required to, contain a top-level 'moov' atom providing a timed, + coded, resource. The 'codecs' parameter SHOULD only be used for + MPEG-21 files when this timed material is also present in the file. + + 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. The precise syntax is given below in the Generic Syntax + (Section 3.2). + + Note that, per [RFC2045], 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 [RFC2045] requires encoding. In + this case, [RFC2231] 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 + [RFC2231] form is used, the percent sign, asterisk, and single quote + characters have special meaning and so MUST themselves be percent + encoded. + + Examples of Generic Syntax: + codecs=a.bb.ccc.d + codecs="a.bb.ccc.d, e.fff" + codecs*=''fo%2e + codecs*="''%25%20xz, gork" + + + + + + +Gellens, et al. Standards Track [Page 6] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + 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 might be required. For + example, the media element(s) could 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.). + + Although the encoder MUST create parameter values that are complete + and accurate in 'breadth' (that is, the encoder MUST report all four- + character codes used in all tracks for ISO family files, for example) + receivers MUST NOT rely on the parameter values 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 + would not know what elements to place after 'qvxy'). + + Although a mismatch is not permitted by this specification, the body + part is definitive of the actual codecs needed; the parameter + supplied here is informative. 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.2. 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 [RFC2231] to allow arbitrary octets + to be encoded. With either form, quotes allow for commas and other + characters in <tspecials> (quotes MAY be used even when not + required). + + This BNF uses the rules specified in [RFC2045] and [RFC2231]. + + While [RFC2231] allows specification of character set and language, + this parameter does not contain items intended for human consumption, + and hence makes no use of language. The language element SHOULD be + + + + +Gellens, et al. Standards Track [Page 7] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + omitted; the character set SHOULD also be omitted. A receiver MAY + ignore language and MAY choose to support only US-ASCII [RFC1345] and + UTF-8 [RFC3629]. + + Implementations MUST NOT add comments and/or folding white space + (CFWS) between the tokens except after ",". TOKEN is defined in + [RFC2045], and <ext-octet> and <attribute-char> are defined in + [RFC2231]. + + The BNF syntax is as follows: + + 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 := <any TOKEN character> + + ; 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 <language> + ; Parsers MAY support only US-ASCII and UTF-8 + fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE + ; Parsers MAY ignore <language> + ; 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 + + DQUOTE := %x22 ; " (double quote) + + Initial name space: This document only defines values for files in + the ISO Base Media File Format and QuickTime families. Other file + formats may also define codec naming. + +3.3. ISO Base Media File Format Name Space + + For the ISO Base Media File Format, and the QuickTime movie 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 [MP4RA]. Values are case sensitive. + + + +Gellens, et al. Standards Track [Page 8] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + Note that there are potentially multiple tracks in a file, each + potentially carrying multiple sample entries (some but not all uses + of the ISO Base Media 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), or 'mp4s' (indicating some kind of MPEG-4 Systems streams + such as MPEG-4 BInary Format for Scenes (BIFS)), the second element + is the hexadecimal representation of the MP4 Registration Authority + ObjectTypeIndication (OTI), as specified in [MP4RA] and [MP41] + (including amendments). Note that [MP4RA] 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 (AAC-LC) 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". + + When the first element of a value is a code indicating a codec from + the Advanced Video Coding specification [AVC], specifically one of + the sample entries defined in [AVC-Formats] (such as 'avc1', 'avc2', + 'svc1', 'mvc1', and 'mvc2') -- indicating AVC (H.264), Scalable Video + Coding (SVC), or Multiview Video Coding (MVC), the second element + (referred to as 'avcoti' in the formal syntax) is the hexadecimal + representation of the following three bytes in the (subset) sequence + parameter set Network Abstraction Layer (NAL) unit specified in + [AVC]: + + (1) profile_idc, + + (2) the byte containing the constraint_set flags (currently + constraint_set0_flag through constraint_set5_flag, and the + reserved_zero_2bits), and + + (3) level_idc. + + + +Gellens, et al. Standards Track [Page 9] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + Note that the sample entries 'avc1' and 'avc2' do not necessarily + indicate that the media only contains AVC NAL units. In fact, the + media may be encoded as an SVC or MVC profile and thus contain SVC or + MVC NAL units. In order to be able to determine which codec is used, + further information is necessary (profile_idc). Note also that + reserved_zero_2bits is required to be equal to 0 in [AVC], but other + values for it may be specified in the future by ITU-T or ISO/IEC. + + This is as previously defined in the 3GPP File Format specification + 3GPP TS 26.244 [3GPP-Formats], Section A.2.2. + + When SVC or MVC content is coded in an AVC-compatible fashion, the + sample description may include both an AVC configuration record and + an SVC or MVC configuration record. Under those circumstances, it is + recommended that the two configuration records both be reported as + they may contain different AVC profile, level, and compatibility + indicator values. Thus, the codecs reported would include the sample + description code (e.g., 'avc1') twice, with the values from one of + the configuration records forming the 'avcoti' information in each. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 10] + +RFC 6381 MIME Codecs and Profiles August 2011 + + +3.4. ISO-Family Syntax + + id-simple :=/ id-iso + id-encoded :=/ id-iso + id-iso := iso-gen / iso-mpega / iso-mpegv / iso-avc + iso-gen := cpid *( element / encoded-elm ) + ; <element> used with <codecs-simple> + ; <encoded-elm> used with <codecs-fancy> + ; + ; Note that the BNF permits "." within <element> + ; and <encoded-elm> but "." is reserved as the + ; hierarchy delimiter + iso-mpega := mp4a "." oti [ "." aud-oti ] + iso-mpegv := mp4v "." oti [ "." vid-pli ] + iso-avc := avc1 / avc2 / svc1 / mvc1 / mvc2 [ "." avcoti ] + cpid := 4(octet-simple / octet-fancy) + ; <octet-simple> used with <codecs-simple> + ; <octet-fancy> used with <codecs-fancy> + mp4a := %x6d.70.34.61 ; 'mp4a' + oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + ; leading "0x" omitted + avc1 := %x61.76.63.31 ; 'avc1' + avc2 := %x61.76.63.32 ; 'avc2' + svc1 := %x73.76.63.31 ; 'svc1' + mvc1 := %x6d.76.63.31 ; 'mvc1' + mvc2 := %x6d.76.63.32 ; 'mvc2' + avcoti := 6(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + ; leading "0x" omitted + aud-oti := 1*DIGIT + mp4v := %x6d.70.34.76 ; 'mp4v' + vid-pli := 1*DIGIT + +3.5. Use in Additional Media Types + + This parameter MAY be specified for use with additional MIME media + types. + + For ISO family 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 family 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 11] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + For non-ISO family file formats, a new document MAY update this one + by specifying the name space for the media type(s). + +3.6. 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) + Content-Type: video/mp4; codecs="avc1.640028" + (H.264/AVC video, High Profile, Level 40, + e.g., DVB 720p 50Hz HDTV) + Content-Type: video/mp4; codecs="svc1.56401E, avc1.4D401E" + (SVC video, Scalable High Profile, Level 30, + with a Main Profile AVC base layer, e.g., DVB 25 Hz SDTV) + Content-Type: video/mp4; codecs="mvc1.800030, avc1.640030" + (MVC video, Stereo High Profile, Level 42, + with a High Profile base layer, e.g., as adopted in Blu-ray) + + Note: OTI value 20 ("0x20" in [MP4RA]) 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). + +3.7. 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 + [RFC2912] header provides a handy way to do so. + +4. The 'Profiles' Parameter + +4.1. Introduction + + Just as some codecs have a variety of profiles (subsets of their + functionality within which a bitstream can be coded), some media + files can also be profiled and be associated with one or more profile + identifiers of the profiles to which they conform. These profiles + + + +Gellens, et al. Standards Track [Page 12] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + can indicate features of the file format itself, which codecs may be + present, the profiles of those codecs, and so on. It can be + advantageous to a receiving system to know the overall file + profile(s) of a file; indeed, under these circumstances it may not be + necessary to know the codecs themselves if they are implied by the + profile. + + The 'profiles' parameter reports on the profile(s) of the overall + container format. A profile of the container format may have + restrictions on not only the features of the container format itself + but also on what codecs may be included, and it may indeed have + restrictions on the profiles of those codecs. The 'profiles' + parameter does not, however, report directly any profiles of the + contained media: when such codec-specific profiles are reported, this + report is part of the 'codecs' parameter. The 'profiles' parameter + reports only the profile(s) applying to the complete container. + + When the use of the 'profiles' parameter is defined for a given + format, that definition SHOULD indicate that it directly reflects + information in the body part, i.e., that it does not convey + information beyond, or different from, what can be learnt by + inspecting the body part. Although a mismatch is not permitted by + this specification, the body part is definitive of the actual + profiles; the parameter supplied here is informative. + +4.2. Formal Declaration + + This section adds a parameter to allow unambiguous specification of + the profiles to which a file claims conformance. This parameter is + OPTIONAL in all current types to which it is added. + + This parameter applies to Box-structured (also known as atom- + structured) files that have an initial box containing compatibility + brands, as registered at the MP4 Registration Authority [MP4RA], such + as a filetype or segment-type box. Principally, this includes files + in the family based on the ISO Base Media File Format [ISO14496-12] + and the QuickTime file format, owned by Apple, Inc. (A brand can + indicate conformance with restrictions regarding which codecs and + file format features are used, adherence to quantitative limits such + as the length/size of the file, and so on.) + + This includes the media types: + + 1. audio/3gpp, video/3gpp [RFC3839] + + 2. audio/3gpp2, video/3gpp2 [RFC4393] + + 3. audio/mp4, video/mp4 [RFC4337] + + + +Gellens, et al. Standards Track [Page 13] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + 4. video/quicktime + + 5. application/mp21 + + Parameter name: profiles + + Parameter value: A single value, or a comma-separated list of values + identifying the profiles(s) to which the file claims conformance. + + The name space is determined by the MIME type. + + Note that, per [RFC2045], 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 [RFC2045] requires encoding. In + this case, [RFC2231] is used: an asterisk ("*") is placed at the end + of the parameter name (becoming 'profiles*' instead of 'profiles'), + 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 [RFC2231] form is used, the percent sign, asterisk, and + single quote characters have special meaning and so MUST themselves + be percent encoded. + + Examples of Generic Syntax: + profiles="isom,mp41,qvXt" + profiles*="''%25%20xz, gork" + +4.3. 'Profiles' Parameter Definition + + The 'profiles' parameter is an OPTIONAL parameter that indicates one + or more profiles to which the file claims conformance. Like the + 'codecs' parameter described above, it may occur as either 'profiles' + or 'profiles*', with the same encoding rules. The value is, as for + the 'codecs' parameter, a comma-separated list of profile + identifiers. + +4.4. Profiles for Files Carrying MP4RA-Registered Brands + + For any file format carrying a brand registered at the MP4 + Registration Authority [MP4RA], notably files based on the ISO Base + Media File Format ISO/IEC 14496-12 [ISO14496-12] and QuickTime movie + files, the 'profiles' parameter MUST list exactly the major-brand, + followed by the compatible-brands, as listed in the filetype box + ('ftyp') or segment-type box ('styp'). The major-brand MUST be + first, and MAY be removed from the compatible-brands list. (The file + + + +Gellens, et al. Standards Track [Page 14] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + format requires that it be repeated in the compatible-brands, but + this requirement is relaxed here for compactness.) + + An example might be profiles="mp41,isom,qvXt", indicating that MPEG-4 + version 1 is the major-brand and preferred use, that the file is + compatible with the version of the base file format identified by + 'isom', and that it is also compatible with the specification/profile + 'qvXt' (whatever that may be). + +4.5. 'Profiles' Parameter BNF Definition + + profiles := pro-simple / pro-fancy + pro-simple := "profiles" "=" unencodedv + pro-fancy := "profiles*" "=" encodedv + +5. IANA Considerations + + IANA has replaced references to [RFC4281] with references to this + document in the "MIME Media Types" registry, thereby indicating that + the 'codecs' and/or 'profiles' parameters are optional for the + following media types (as listed in Sections 3 and 4): + + 1. audio/3gpp, video/3gpp [RFC3839] + + 2. audio/3gpp2, video/3gpp2 [RFC4393] + + 3. audio/mp4, video/mp4, application/mp4 [RFC4337] + + 4. video/quicktime + + 5. application/mp21 + +6. Registration + + The MPEG4 Registration Authority can be consulted for the most up-to- + date registration of sub-parameters for the codecs type, for specific + codecs. + + + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 15] + +RFC 6381 MIME Codecs and Profiles August 2011 + + +7. 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 not to be sent to a device that 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. + + To the extent that a receiver reacts to a 'codecs' parameter that + indicates an unsupported codec, by fetching and installing the + required codecs, such reaction needs to be performed carefully and in + accord with the system's normal validity and security checks and + procedures. + +8. Differences from RFC 4281 + + 1. Improved the introduction and other supporting and explanatory + text; + + 2. improved the references; + + 3. clarified the MIME types to which the parameters apply, and + clarified the consequent IANA actions; + + 4. added the 'profiles' parameter; + + 5. fixed an error in the BNF, where it did not correspond to either + the examples or common usage; + + 6. added the definition of the sub-parameters for the AVC family of + codecs; + + 7. added a security consideration for possible triggering of + downloads; + + 8. updated acknowledgments. + + + + + +Gellens, et al. Standards Track [Page 16] + +RFC 6381 MIME Codecs and Profiles August 2011 + + +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. + + Christian Timmerer helped with the MPEG-21 material, and Thomas + Schierl and Yago Sanchez helped with SVC and MVC. + +10. References + +10.1. Normative References + + [3GPP-Formats] 3rd Generation Partnership Project, "Technical + Specification Group Services and System Aspects; + Transparent end-to-end packet switched streaming + service (PSS); 3GPP file format (3GP)", 3GPP + TS 26.244. + + [AVC] "Advanced video coding for generic audiovisual + services", ITU-T Recommendation H.264, ISO/ + IEC 14496-10:2009. + + [AVC-Formats] "Information technology -- Coding of audio-visual + objects -- Part 15: Advanced Video Coding (AVC) file + format", ISO/IEC 14496-15:2010. + + [ISO14496-12] "Information technology -- Coding of audio-visual + objects -- Part 12: ISO base media file format", + ISO/IEC 14496-12:2008. + + [MP4RA] "MP4REG, The MPEG-4 Registration Authority", + <http://www.mp4ra.org>. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part One: Format of Internet + Message Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and + Encoded Word Extensions: + Character Sets, Languages, and Continuations", + RFC 2231, November 1997. + + + + +Gellens, et al. Standards Track [Page 17] + +RFC 6381 MIME Codecs and Profiles August 2011 + + + [RFC2912] Klyne, G., "Indicating Media Features for MIME + Content", RFC 2912, September 2000. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3839] Castagno, R. and D. Singer, "MIME Type Registrations + for 3rd Generation Partnership Project (3GPP) + Multimedia files", RFC 3839, July 2004. + + [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs + Parameter for "Bucket" Media Types", RFC 4281, + November 2005. + + [RFC4337] Y Lim and D. Singer, "MIME Type Registration for + MPEG-4", RFC 4337, March 2006. + + [RFC4393] Garudadri, H., "MIME Type Registrations for 3GPP2 + Multimedia Files", RFC 4393, March 2006. + +10.2. Informative References + + [3GPP2-Formats] Third Generation Partnership Project 2, "3GPP2 File + Formats for Multimedia Service", <http:// + www.3gpp2.org/Public_html/specs/ + C.S0050-0_v1.0_121503.pdf>. + + [MP41] "Information technology--Coding of audio-visual + objects -- Part 1: Systems", ISO/IEC 14496-1:2010. + + [MP4A] "Information technology--Coding of audio-visual + objects -- 3: Audio", ISO/IEC 14496-3:2009. + + [MP4V] "Information technology--Coding of audio-visual + objects -- Part 2: Visual", ISO/IEC 14496-2:2004. + + [RFC1345] Simonsen, K., "Character Mnemonics and Character + Sets", RFC 1345, June 1992. + + [RFC3625] 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 18] + +RFC 6381 MIME Codecs and Profiles August 2011 + + +Authors' Addresses + + Randall Gellens + QUALCOMM Incorporated + 5775 Morehouse Drive + San Diego, CA 92121 + US + + EMail: rg+ietf@qualcomm.com + + + David Singer + Apple, Inc. + 1 Infinite Loop + Cupertino, CA 95014 + US + + Phone: +1 408 996 1010 + EMail: singer@apple.com + + + Per Frojdh + Ericsson AB + Ericsson Research + Stockholm SE-164 80 + Sweden + + Phone: +46 10 7190000 + EMail: Per.Frojdh@ericsson.com + + + + + + + + + + + + + + + + + + + + + + +Gellens, et al. Standards Track [Page 19] + |