idnits 2.17.1 draft-gellens-mime-bucket-bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3839, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4337, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4393, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3839, updated by this document, for RFC5378 checks: 2003-08-19) (Using the creation date from RFC4337, updated by this document, for RFC5378 checks: 2002-06-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 3, 2011) is 4642 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '3GPP-Formats' -- Possible downref: Non-RFC (?) normative reference: ref. 'AVC' -- Possible downref: Non-RFC (?) normative reference: ref. 'AVC-Formats' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO14496-12' -- Possible downref: Non-RFC (?) normative reference: ref. 'MP4RA' ** Obsolete normative reference: RFC 4281 (Obsoleted by RFC 6381) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gellens 3 Internet-Draft QUALCOMM Incorporated 4 Obsoletes: 4281 (if approved) D. Singer 5 Updates: 3839,4393,4337 Apple Inc. 6 (if approved) P. Frojdh 7 Intended status: Standards Track Ericsson AB 8 Expires: February 4, 2012 August 3, 2011 10 The Codecs and Profiles Parameters for "Bucket" Media Types 11 draft-gellens-mime-bucket-bis-09.txt 13 Abstract 15 Several MIME type/subtype combinations exist that can contain 16 different media formats. A receiving agent thus needs to examine the 17 details of such media content to determine if the specific elements 18 can be rendered given an available set of codecs. Especially when 19 the end system has limited resources, or the connection to the end 20 system has limited bandwidth, it is helpful to know from the Content- 21 Type alone if the content can be rendered. 23 This document specifies two parameters, "codecs" and "profiles", 24 which are used with various MIME types or type/subtype combinations 25 to allow for unambiguous specification of the codecs employed by the 26 media formats contained within, or the profile(s) of the overall 27 container format. This document obsoletes RFC 4281; RFC 4281 defines 28 the "codecs" parameter, which this document retains in a backwards 29 compatible manner with minor clarifications; the "profiles" parameter 30 is added by this document. 32 By labeling content with the specific codecs indicated to render the 33 contained media, receiving systems can determine if the codecs are 34 supported by the end system, and if not, can take appropriate action 35 (such as rejecting the content, sending notification of the 36 situation, transcoding the content to a supported type, fetching and 37 installing the required codecs, further inspection to determine if it 38 will be sufficient to support a subset of the indicated codecs, etc.) 40 Similarly, the profiles can provide an overall indication, to the 41 receiver, of the specifications with which the content complies. 42 This is an indication of the compatibility of the container format 43 and its contents to some specification. The receiver may be able to 44 work out the extent to which it can handle and render the content by 45 examining to see which of the declared profiles it supports, and what 46 they mean. 48 Status of this Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on February 4, 2012. 64 Copyright Notice 66 Copyright (c) 2011 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 83 3. The Codecs Parameter . . . . . . . . . . . . . . . . . . . . . 7 84 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 85 3.2. Generic Syntax . . . . . . . . . . . . . . . . . . . . . . 9 86 3.3. ISO File Format Name Space . . . . . . . . . . . . . . . . 10 87 3.4. ISO Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 88 3.5. Use in Additional Media Types . . . . . . . . . . . . . . 12 89 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 3.7. Additional Media Feature Details . . . . . . . . . . . . . 13 91 4. The Profiles Parameter . . . . . . . . . . . . . . . . . . . . 15 92 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 15 93 4.2. Formal Declaration . . . . . . . . . . . . . . . . . . . . 15 94 4.3. Profiles Parameter Definition . . . . . . . . . . . . . . 16 95 4.4. Profiles for files carrying MP4RA registered brands . . . 17 96 4.5. Profiles Parameter BNF Definition . . . . . . . . . . . . 17 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 98 6. Registration . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 100 8. Differences from RFC 4281 . . . . . . . . . . . . . . . . . . 21 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 107 1. Introduction 109 One of the original motivations for MIME is the ability to identify 110 the specific media type of a message part. However, due to various 111 factors, it is not always possible from looking at the MIME type and 112 subtype to know which specific media formats are contained in the 113 body part, or which codecs are indicated in order to render the 114 content. 116 There are several media type/subtypes (either currently registered or 117 deployed with registration pending) that contain codecs chosen from a 118 set. In the absence of the parameters described here, it is 119 necessary to examine each media element in order to determine the 120 codecs or other features required to render the content. For 121 example, video/3gpp may contain any of the video formats H.263 122 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or any 123 of the audio formats Adaptive Multi Rate (AMR), Adaptive Multi Rate - 124 WideBand (AMR-WB), Extended AMR-WB, Advanced Audio Coding (AAC), or 125 Enhanced aacPlus, as specified in [3GPP-Formats]. 127 In some cases, the specific codecs can be determined by examining the 128 header information of the media content. While this isn't as bad as 129 examining the entire content, it still requires specialized knowledge 130 of each format and is resource consumptive. 132 This ambiguity can be a problem for various clients and servers. For 133 example, it presents a significant burden to Multimedia Messaging 134 (MMS) servers, which must examine the media sent in each message in 135 order to determine which codecs are required to render the content. 136 Only then can such a server determine if the content requires 137 transcoding or specialized handling prior to being transmitted to the 138 handset. 140 Additionally, it presents a challenge to smart clients on devices 141 with constrained memory, processing power, or transmission bandwidth 142 (such as cellular telephones and PDAs). Such clients often need to 143 determine in advance if they are currently capable of rendering the 144 content contained in an MMS or email message. 146 Ambiguity: 148 o audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or 149 Enhanced aacPlus contents as specified in [3GPP-Formats]. 151 o audio/3gpp2 can contain AMR, AAC, 13K (as per [RFC3625]), Enhanced 152 Variable Rate Codec (EVRC), Selectable Mode Vocoder (SMV), or 153 VMR-WB, as specified in [3GPP2-Formats]. 155 o video/3gpp can contain H.263 Profile 0, H.263 Profile 3, H.264, 156 MPEG-4 Simple Profile, and/or AMR, AMR-WB, Extended AMR-WB, AAC, 157 or Enhanced aacPlus, as specified in [3GPP-Formats]. 159 o video/3gpp2 can contain H.263 Profile 0, H.263 Profile 3, H.264, 160 MPEG-4 Simple Profile, and/or AMR, AAC, 13K (as per [RFC3625]), 161 EVRC, SMV, or VMR-WB, as specified in [3GPP2-Formats]. 163 o audio/mp4 can include any codec defined in MPEG-1, MPEG-2, MPEG-4 164 or registered at the MP4 registration authority [MP4RA]. 166 o video/mp4 has the same issues as audio/mp4, and in addition many 167 video codecs, and especially the MPEG codecs, have a variety of 168 profiles and levels, not all of which are supported by every 169 implementation. 171 Note that there are additional media types that are ambiguous, but 172 are outside the scope of this document, including: 174 o video/mpeg4-generic, which can contain anything allowed by the 175 MPEG-4 specification, or any codec registered with the MP4 176 registration authority [MP4RA]; 178 With each "bucket" type, a receiving agent only knows that it has a 179 container format. It doesn't even know whether content labeled 180 video/3gpp or video/3gpp2 contains video; it might be audio only, 181 audio and video, or video only. 183 A solution that permits a receiving agent to determine the specific 184 codecs or profiles required to render media content would help 185 provide efficient and scalable servers, especially for Multimedia 186 Messaging (MMS), and aid the growth of multimedia services in 187 wireless networks. 189 2. Conventions Used in This Document 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in "Key words for use in 194 RFCs to Indicate Requirement Levels" [RFC2119] . 196 The syntax in this document uses the BNF rules specified in [RFC2045] 197 and [RFC2231]. 199 3. The Codecs Parameter 201 3.1. Introduction 203 This section adds a parameter to allow unambiguous specification of 204 all codecs indicated to render the content in the MIME part. This 205 parameter is optional in all current types to which it is added. 206 Future types that contain ambiguity are strongly encouraged to 207 include this parameter. 209 This parameter applies to: 211 1. Files in the family based on the ISO Base Media File Format 212 [ISO14496-12]. 214 2. The QuickTime file format, owned by Apple Inc. 216 This includes the media types: 218 1. audio/3gpp, video/3gpp [RFC3839] 220 2. audio/3gpp2, video/3gpp2 [RFC4393] 222 3. audio/mp4, video/mp4, application/mp4 [RFC4337] 224 4. video/quicktime 226 5. application/mp21 (see note below) 228 Note that MPEG-21 files under the type application/mp21 may, but are 229 not required to, contain a top-level 'moov' atom providing a timed, 230 coded, resource. The codecs parameter SHOULD only be used for 231 MPEG-21 files when this timed material is also present in the file. 233 Parameter name: codecs 235 Parameter value: A single value, or a comma-separated list of values 236 identifying the codec(s) indicated to render the content in the body 237 part. 239 Each value consists of one or more dot-separated elements. The name 240 space for the first element is determined by the MIME type. The name 241 space for each subsequent element is determined by the preceding 242 element. The precise syntax is given below in the Generic Syntax 243 (Section 3.2). 245 Note that, per [RFC2045], some characters (including the comma used 246 to separate multiple values) require that the entire parameter value 247 be enclosed in quotes. 249 An element MAY include an octet that [RFC2045] requires to be 250 encoded. In this case, [RFC2231] is used: an asterisk ("*") is 251 placed at the end of the parameter name (becoming "codecs*" instead 252 of "codecs"), the parameter value usually starts with two single 253 quote ("'") characters (indicating that neither character set nor 254 language is specified), and each octet that requires encoding is 255 represented as a percent sign ("%") followed by two hexadecimal 256 digits. Note that, when the [RFC2231] form is used, the percent 257 sign, asterisk, and single quote characters have special meaning and 258 so MUST themselves be percent encoded. 260 Examples of Generic Syntax: 261 codecs=a.bb.ccc.d 262 codecs="a.bb.ccc.d, e.fff" 263 codecs*=''fo%2e 264 codecs*="''%25%20xz, gork" 266 When the codecs parameter is used, it MUST contain all codecs 267 indicated by the content present in the body part. The codecs 268 parameter MUST NOT include any codecs that are not indicated by any 269 media elements in the body part. 271 In some cases, not all indicated codecs are absolutely required in 272 order to render the content. Therefore, when a receiver does not 273 support all listed codecs, special handling might be required. For 274 example, the media element(s) could be examined in order to determine 275 if an unsupported codec is actually required (e.g., there may be 276 alternative tracks (such as English and Spanish audio), there may be 277 timed text that can be dropped, etc.) 279 Although the encoder MUST create parameter values that are complete 280 and accurate in 'breadth' (that is, the encoder MUST report all four- 281 character codes used in all tracks for ISO-family files, for example) 282 receivers MUST NOT rely on the parameter values being complete in 283 'depth'. (If the hierarchical rules for a given code (e.g., 'qvxy') 284 were written after a server was implemented, for example, that server 285 will not know what elements to place after 'qvxy'). 287 Although a mismatch is not permitted by this specification, the body- 288 part is definitive of the actual codecs needed; the parameter 289 supplied here is informative. If a receiver encounters a body part 290 whose codecs parameter contains codecs that are not indicated by any 291 media elements, then the receiver SHOULD process the body part by 292 discarding the information in the codecs parameter. 294 If a receiver encounters a body part whose codecs parameter does not 295 contain all codecs indicated by the media elements, then the receiver 296 MAY process the body part by discarding the information in the codecs 297 parameter. 299 3.2. Generic Syntax 301 The codecs parameter takes either of two forms. The first form is 302 used when the value does not contain any octets that require 303 encoding. The second form uses [RFC2231] to allow arbitrary octets 304 to be encoded. With either form, quotes allow for commas and other 305 characters in (quotes MAY be used even when not 306 required). 308 This BNF uses the rules specified in [RFC2045] and [RFC2231]. 310 While [RFC2231] allows specification of character set and language, 311 this parameter does not contain items intended for human consumption, 312 and hence makes no use of language. The language element SHOULD be 313 omitted; the character set SHOULD also be omitted. A receiver MAY 314 ignore language and MAY choose to support only US-ASCII [RFC1345] and 315 UTF-8 [RFC3629]. 317 Implementations MUST NOT add CFWS between the tokens except after 318 ",". TOKEN is defined in [RFC2045], and and are defined in [RFC2231]. 321 The BNF syntax is as follows: 323 codecs := cod-simple / cod-fancy 324 cod-simple := "codecs" "=" unencodedv 325 unencodedv := id-simple / simp-list 326 simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE 327 id-simple := element 328 ; "." reserved as hierarchy delimiter 329 element := 1*octet-sim 330 octet-sim := 332 ; Within a codecs parameter value, "." is reserved 333 ; as a hierarchy delimiter 334 cod-fancy := "codecs*" "=" encodedv 335 encodedv := fancy-sing / fancy-list 336 fancy-sing := [charset] "'" [language] "'" id-encoded 337 ; Parsers MAY ignore 338 ; Parsers MAY support only US-ASCII and UTF-8 339 fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE 340 ; Parsers MAY ignore 341 ; Parsers MAY support only US-ASCII and UTF-8 342 id-list := id-encoded *( "," id-encoded ) 343 id-encoded := encoded-elm *( "." encoded-elm ) 344 ; "." reserved as hierarchy delimiter 345 encoded-elm := 1*octet-fancy 346 octet-fancy := ext-octet / attribute-char 348 DQUOTE := %x22 ; " (double quote) 350 Initial name space: This document only defines values for files in 351 the ISO Base Media File Format, and QuickTime, families. Other file 352 formats may also define codec naming. 354 3.3. ISO File Format Name Space 356 For the ISO Base Media File Format, and the QuickTime movie file 357 format, the first element of a codecs parameter value is a sample 358 description entry four-character code as registered by the MP4 359 Registration Authority [MP4RA]. Values are case sensitive. 361 Note that there are potentially multiple tracks in a file, each 362 potentially carrying multiple sample entries (some but not all uses 363 of the ISO File Format restrict the number of sample entries in a 364 track to one). 366 When the first element of a value is 'mp4a' (indicating some kind of 367 MPEG-4 audio), or 'mp4v' (indicating some kind of MPEG-4 part-2 368 video), or 'mp4s' (indicating some kind of MPEG-4 Systems streams 369 such as MPEG-4 BIFS), the second element is the hexadecimal 370 representation of the MP4 Registration Authority ObjectTypeIndication 371 (OTI), as specified in [MP4RA] and [MP41] (including amendments). 372 Note that [MP4RA] uses a leading "0x" with these values, which is 373 omitted here and hence implied. 375 One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio). 376 For this value, the third element identifies the audio 377 ObjectTypeIndication (OTI) as defined in [MP4A] (including 378 amendments), expressed as a decimal number. 380 For example, AAC low complexity has the value 2, so a complete string 381 for AAC-LC would be "mp4a.40.2". 383 One of the OTI values for 'mp4v' is 20 (identifying MPEG-4 part-2 384 video). For this value, the third element identifies the video 385 ProfileLevelIndication as defined in [MP4V] (including amendments), 386 expressed as a decimal number. 388 For example, MPEG-4 Visual Simple Profile Level 0 has the value 9, so 389 a complete string for MPEG-4 Visual Simple Profile Level 0 would be 390 "mp4v.20.9". 392 When the first element of a value is a code indicating a codec from 393 the Advanced Video Coding specification [AVC], specifically one of 394 the sample entries defined in [AVC-Formats] (such as 'avc1', 'avc2', 395 'svc1', 'mvc1' and 'mvc2') - indicating AVC (H.264), Scalable Video 396 Coding (SVC) or Multiview Video Coding (MVC), the second element 397 (referred to as 'avcoti' in the formal syntax) is the hexadecimal 398 representation of the following three bytes in the (subset) sequence 399 parameter set NAL unit specified in [AVC]: 401 (1) profile_idc, 403 (2) the byte containing the constraint_set flags (currently 404 constraint_set0_flag through constraint_set5_flag, and the 405 reserved_zero_2bits) and 407 (3) level_idc. 409 Note that the sample entries 'avc1' and 'avc2' do not necessarily 410 indicate that the media only contains AVC NAL units. In fact, the 411 media may be encoded as an SVC or MVC profile and thus contain SVC or 412 MVC NAL units. In order to be able to determine which codec is used 413 further information is necessary (profile_idc). Note also that 414 reserved_zero_2bits is required to be equal to 0 in [AVC], but other 415 values for it may be specified in the future by ITU-T or ISO/IEC. 417 This is as previously defined in the 3GPP File Format specification 418 3GPP TS 26.244 [3GPP-Formats], section A.2.2. 420 When SVC or MVC content is coded in an AVC-compatible fashion, the 421 sample description may include both an AVC configuration record and 422 an SVC or MVC configuration record. Under those circumstances, it is 423 recommended that the two configuration records both be reported as 424 they may contain different AVC profile, level, and compatibility 425 indicator values. Thus the codecs reported would include the sample 426 description code (e.g. 'avc1') twice, with the values from one of the 427 configuration records forming the 'avcoti' information in each. 429 3.4. ISO Syntax 431 id-simple :=/ id-iso 432 id-encoded :=/ id-iso 433 id-iso := iso-gen / iso-mpega / iso-mpegv / iso-avc 434 iso-gen := cpid *( element / encoded-elm ) 435 ; used with 436 ; used with 437 ; 438 ; Note that the BNF permits "." within 439 ; and but "." is reserved as the 440 ; hierarchy delimiter 441 iso-mpega := mp4a "." oti [ "." aud-oti ] 442 iso-mpegv := mp4v "." oti [ "." vid-pli ] 443 iso-avc := avc1 / avc2 / svc1 / mvc1 / mvc2 [ "." avcoti ] 444 cpid := 4(octet-simple / octet-fancy) 445 ; used with 446 ; used with 447 mp4a := %x6d.70.34.61 ; 'mp4a' 448 oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") 449 ; leading "0x" omitted 450 avc1 := %x61.76.63.31 ; 'avc1' 451 avc2 := %x61.76.63.32 ; 'avc2' 452 svc1 := %x73.76.63.31 ; 'svc1' 453 mvc1 := %x6d.76.63.31 ; 'mvc1' 454 mvc2 := %x6d.76.63.32 ; 'mvc2' 455 avcoti := 6(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") 456 ; leading "0x" omitted 457 aud-oti := 1*DIGIT 458 mp4v := %x6d.70.34.76 ; 'mp4v' 459 vid-pli := 1*DIGIT 461 3.5. Use in Additional Media Types 463 This parameter MAY be specified for use with additional MIME media 464 types. 466 For ISO file formats where the name space as defined here is 467 sufficient, all that needs to be done is to update the media type 468 registration to specify the codecs parameter with a reference to this 469 document. For existing media types, it is generally advisable for 470 the parameter to be optional; for new media types, the parameter MAY 471 be optional or required, as appropriate. 473 For ISO file formats where the name space as defined here needs to be 474 expanded, a new document MAY update this one by specifying the 475 additional detail. 477 For non-ISO formats, a new document MAY update this one by specifying 478 the name space for the media type(s). 480 3.6. Examples 482 Content-Type: video/3gpp2; codecs="sevc, s263" 483 (EVRC audio plus H.263 video) 484 Content-Type: audio/3gpp; codecs=samr 485 (AMR audio) 486 Content-Type: video/3gpp; codecs="s263, samr" 487 (H.263 video plus AMR audio) 488 Content-Type: audio/3gpp2; codecs=mp4a.E1 489 (13k audio) 490 Content-Type: video/3gpp2; codecs="mp4v.20.9, mp4a.E1" 491 (MPEG-4 Visual Simple Profile Level 0 plus 13K voice) 492 Content-Type: video/mp4; codecs="avc1.640028" 493 (H.264/AVC video, High Profile, Level 40, 494 e.g. DVB 720p 50Hz HDTV) 495 Content-Type: video/mp4; codecs="svc1.56401E, avc1.4D401E" 496 (SVC video, Scalable High Profile, Level 30, 497 with a Main Profile AVC base layer, e.g. DVB 25 Hz SDTV) 498 Content-Type: video/mp4; codecs="mvc1.800030, avc1.640030" 499 (MVC video, Stereo High Profile, Level 42, 500 with a High Profile base layer, e.g. as adopted in Blu-ray) 502 Note: OTI value 20 ("0x20" in [MP4RA]) says "Includes associated 503 Amendment(s) and Corrigendum(a). The actual object types are defined 504 in [MP4V] and are conveyed in the DecoderSpecificInfo as specified in 505 [MP4V], Annex K." (references adjusted). 507 3.7. Additional Media Feature Details 509 It is sometimes helpful to provide additional details for a media 510 element (e.g., the number of X and Y pixels, the color depth, etc.). 511 These details are sometimes called "media features" or "media 512 characteristics". 514 When such additional features are included, the content-features 516 [RFC2912] header provides a handy way to do so. 518 4. The Profiles Parameter 520 4.1. Introduction 522 Just as some codecs have a variety of profiles (subsets of their 523 functionality within which a bitstream can be coded), so also some 524 media files can be profiled, and be associated with one or more 525 profile identifiers of the profiles to which they conform. These 526 profiles can indicate features of the file format itself, which 527 codecs may be present, the profiles of those codecs, and so on. It 528 can be advantageous to a receiving system to know the overall file 529 profile(s) of a file; indeed, under these circumstances it may not be 530 necessary to know the codecs themselves if they are implied by the 531 profile. 533 The 'profiles' parameter reports on the profile(s) of the overall 534 container format. A profile of the container format may have 535 restrictions on not only the features of the container format itself, 536 but also on what codecs may be included, and indeed have restrictions 537 on the profiles of those codecs. The 'profiles' parameter does not, 538 however, report directly any profiles of the contained media: when 539 such codec-specific profiles are reported, this report is part of the 540 'codecs' parameter. The 'profiles' parameter reports only the 541 profile(s) applying to the complete container. 543 When the use of the profiles parameter is defined for a given format, 544 that definition SHOULD indicate that it directly reflects information 545 in the body-part, i.e. that it does not convey information beyond, or 546 different from, what can be learnt by inspecting the body-part. 547 Although a mismatch is not permitted by this specification, the body- 548 part is definitive of the actual profiles; the parameter supplied 549 here is informative. 551 4.2. Formal Declaration 553 This section adds a parameter to allow unambiguous specification of 554 the profiles to which a file claims conformance. This parameter is 555 OPTIONAL in all current types to which it is added. 557 This parameter applies to: 559 1. Box-structured (also known as atom-structured) files that have an 560 initial box containing compatibility brands, as registered at the 561 MP4 Registration Authority [MP4RA], such as a filetype or 562 segment-type box. This includes principally files in the family 563 based on the ISO Base Media File Format [ISO14496-12], and also 564 the QuickTime file format, owned by Apple Inc. (A brand can 565 indicate conformance with restrictions regarding which codecs and 566 file format features are used, adherence to quantitative limits 567 such as the length/size of the file, and so on.) 569 This includes the media types: 571 1. audio/3gpp, video/3gpp [RFC3839] 573 2. audio/3gpp2, video/3gpp2 [RFC4393] 575 3. audio/mp4, video/mp4 [RFC4337] 577 4. video/quicktime 579 5. application/mp21 581 Parameter name: profiles 583 Parameter value: A single value, or a comma-separated list of values 584 identifying the profiles(s) to which the file claims conformance. 586 The name space is determined by the MIME type. 588 Note that, per [RFC2045], some characters (including the comma used 589 to separate multiple values) require that the entire parameter value 590 be enclosed in quotes. 592 An element MAY include an octet that [RFC2045] requires to be 593 encoded. In this case, [RFC2231] is used: an asterisk ("*") is 594 placed at the end of the parameter name (becoming "profiles*" instead 595 of "profiles"), the parameter value usually starts with two single 596 quote ("'") characters(indicating that neither character set nor 597 language is specified), and each octet that requires encoding is 598 represented as a percent sign ("%") followed by two hexadecimal 599 digits. Note that, when the [RFC2231] form is used, the percent 600 sign, asterisk, and single quote characters have special meaning and 601 so MUST themselves be percent encoded. 603 Examples of Generic Syntax: 604 profiles="isom,mp41,qvXt" 605 profiles*="''%25%20xz, gork" 607 4.3. Profiles Parameter Definition 609 The 'profiles' parameter is an OPTIONAL parameter that indicates one 610 or more profiles to which the file claims conformance. Like the 611 'codecs' parameter described above, it may occur as either 'profiles' 612 or 'profiles*', with the same encoding rules. The value is, as for 613 the codecs parameter, a comma-separated list of profile identifiers. 615 4.4. Profiles for files carrying MP4RA registered brands 617 For any file format carrying a brand registered at the MP4 618 Registration Authority [MP4RA], notably files based on the ISO Base 619 Media File Format ISO/IEC 14496-12 [ISO14496-12] and QuickTime movie 620 files, the profiles parameter MUST list exactly the major brand, 621 followed by the compatible-brands, as listed in the filetype box 622 ('ftyp') or segment-type box ('styp'). The major-brand MUST be 623 first, and MAY be removed from the compatible-brands list. (The file 624 format requires that it be repeated in the compatible brands, but 625 this requirement is relaxed here for compactness.) 627 An example might be profiles="mp41,isom,qvXt", indicating that MPEG-4 628 version 1 is the major brand and preferred use, that the file is 629 compatible with the version of the base file format identified by 630 'isom', and that it is also compatible with the specification/profile 631 'qvXt' (whatever that may be). 633 4.5. Profiles Parameter BNF Definition 635 profil := pro-simple / pro-fancy 636 pro-simple := "profiles" "=" unencodedv 638 ; Within a codecs parameter value, "." is reserved 639 ; as a hierarchy delimiter 640 pro-fancy := "profiles*" "=" encodedv 642 5. IANA Considerations 644 IANA has acted on the "MIME Media Types registry" and either added a 645 reference, or replaced the reference to [RFC4281], with a reference 646 to this document, thereby indicating that the "codecs" and/or 647 "profiles" parameters are optional for the following media types (as 648 listed in Sections 3 and 4): 650 1. audio/3gpp, video/3gpp [RFC3839] 652 2. audio/3gpp2, video/3gpp2 [RFC4393] 654 3. audio/mp4, video/mp4, application/mp4 [RFC4337] 656 4. video/quicktime 658 5. application/mp21 660 6. Registration 662 The MPEG4 Registration Authority can be consulted for the most up-to- 663 date registration of sub-parameters for the codecs type, for specific 664 codecs. 666 7. Security Considerations 668 The codecs parameter itself does not alter the security 669 considerations of any of the media types with which it is used. Each 670 audio and video media type has its own set of security considerations 671 that continue to apply, regardless of the use of the codecs 672 parameter. 674 An incorrect codecs parameter might cause media content to be 675 received by a device that is not capable of rendering it, or might 676 cause media content to not be sent to a device that is capable of 677 receiving it. An incorrect codecs parameter is therefore capable of 678 some types of denial-of-service attacks. However, this is most 679 likely to arise by accident, as an attacker capable of altering media 680 data in transit could cause more harm by altering the media format 681 itself, or even the content type header, rather than just the codecs 682 parameter of the content type header. 684 To the extent that a receiver reacts to a 'codecs' parameter that 685 indicates an unsupported codec, by fetching and installing the 686 required codecs, such reaction needs to be performed carefully and in 687 accord with the system's normal validity and security checks and 688 procedures. 690 8. Differences from RFC 4281 692 1. Improved the introduction and other supporting and explanatory 693 text; 695 2. improved the references; 697 3. clarified the MIME types to which the parameters apply, and 698 clarified the consequent IANA actions; 700 4. added the 'profiles' parameter; 702 5. fixed an error in the BNF, where it did not correspond to either 703 the examples or common usage; 705 6. added the definition of the sub-parameters for the AVC family of 706 codecs; 708 7. switched to the latest boilerplate, and XML2RFC; 710 8. added a security consideration for possible triggering of 711 downloads; 713 9. updated acknowledgments. 715 9. Acknowledgements 717 Harinath Garudadri provided a great deal of help, which is very much 718 appreciated. Mary Barnes and Bruce Lilly provided detailed and 719 helpful comments. Reviews and comments by Sam Hartman, Russ Housley, 720 and Bert Wijnen were much appreciated. Chris Newman carefully 721 reviewed and improved the BNF. 723 Christian Timmerer helped with the MPEG-21 material, and Thomas 724 Schierl and Yago Sanchez helped with SVC and MVC. 726 10. References 728 10.1. Normative References 730 [3GPP-Formats] 731 3rd Generation Partnership Project, "Technical 732 Specification Group Services and System Aspects; 733 Transparent end-to-end packet switched streaming service 734 (PSS); 3GPP file format (3GP)", 3GPP TS 26.244. 736 [AVC] "Advanced video coding for generic audiovisual services", 737 ITU-T Recommendation H.264, ISO/IEC 14496-10:2009. 739 [AVC-Formats] 740 "Information technology -- Coding of audio-visual objects 741 -- Part 15: Advanced Video Coding (AVC) file format", ISO/ 742 IEC 14496-15:2010. 744 [ISO14496-12] 745 "Information technology -- Coding of audio-visual objects 746 -- Part 12: ISO base media file format", ISO/ 747 IEC 14496-12:2008. 749 [MP4RA] "MP4REG, The MPEG-4 Registration Authority", 750 . 752 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 753 Extensions (MIME) Part One: Format of Internet Message 754 Bodies", RFC 2045, November 1996. 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, March 1997. 759 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 760 Word Extensions: 761 Character Sets, Languages, and Continuations", RFC 2231, 762 November 1997. 764 [RFC2912] Klyne, G., "Indicating Media Features for MIME Content", 765 RFC 2912, September 2000. 767 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 768 10646", STD 63, RFC 3629, November 2003. 770 [RFC3839] Castagno, R. and D. Singer, "MIME Type Registrations for 771 3rd Generation Partnership Project (3GPP) Multimedia 772 files", RFC 3839, July 2004. 774 [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs 775 Parameter for "Bucket" Media Types", RFC 4281, 776 November 2005. 778 [RFC4337] Y Lim and D. Singer, "MIME Type Registration for MPEG-4", 779 RFC 4337, March 2006. 781 [RFC4393] Garudadri, H., "MIME Type Registrations for 3GPP2 782 Multimedia Files", RFC 4393, March 2006. 784 10.2. Informative References 786 [3GPP2-Formats] 787 Third Generation Partnership Project 2, "3GPP2 File 788 Formats for Multimedia Service", . 791 [MP41] "Information technology--Coding of audio-visual objects-- 792 Part 1: Systems", ISO/IEC 14496-1:2010. 794 [MP4A] "Information technology--Coding of audio-visual 795 objects--3: Audio", ISO/IEC 14496-3:2009. 797 [MP4V] "Information technology--Coding of audio-visual objects-- 798 Part 2: Visual", ISO/IEC 14496-2:2004. 800 [RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", 801 RFC 1345, June 1992. 803 [RFC3625] Gellens, R. and H. Garudadri, "The QCP File Format and 804 Media Types for Speech Data", RFC 3625, September 2003. 806 Authors' Addresses 808 Randall Gellens 809 QUALCOMM Incorporated 810 5775 Morehouse Drive 811 San Diego, CA 92121 812 US 814 Email: randy@qualcomm.com 816 David Singer 817 Apple Inc. 818 1 Infinite Loop 819 Cupertino, CA 95014 820 US 822 Phone: +1 408 996 1010 823 Email: singer@apple.com 825 Per Frojdh 826 Ericsson AB 827 Ericsson Research 828 Stockholm SE-164 80 829 Sweden 831 Phone: +46 8 7190000 832 Email: Per.Frojdh@ericsson.com