GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4281

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 <tspecials> (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   := <any TOKEN character>
             ; <TOKEN> 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 <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
             ; <ext-octet> and <attribute-char> 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 )
             ; <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 ]
 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
 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:
                    <http://www.mp4ra.org>.

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:
                    <http://www.3gpp.org/ftp/Specs/html-info/
                    26244.htm>.
 [3GPP2-Formats]    Third Generation Partnership Project 2, "3GPP2
                    File Formats for Multimedia Service", URL:
                    <http://www.3gpp2.org/Public_html/specs/
                    C.S0050-0_v1.0_121503.pdf>.
 [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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4281.txt · Last modified: 2005/11/30 18:38 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki