The Codecs Parameter for "Bucket" Media Types
draft-gellens-mime-bucket-04

Internet Draft                                               R. Gellens
Document: draft-gellens-mime-bucket-04.txt                     Qualcomm
Expires: December 2005                                        D. Singer
                                                                  Apple
                                                              P. Frojdh
                                                               Ericsson
                                                              June 2005
    
    
             The Codecs Parameter for "Bucket" Media Types
    
Status of this Memo
    
    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.
    
    By submitting this Internet-Draft, I accept the provisions of
    Section 3 of RFC 3667 (BCP 78).
    
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
    
    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as "work in progress."
    
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt The list of
    Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
    
    
Copyright Notice
    
    Copyright (C) The Internet Society (2005).  All Rights Reserved.
    
    
Abstract
    
    Several MIME type/subtype combinations exist which can contain
    different media formats.  A receiving agent thus needs to examine
    the details of such media content to determine if the specific
    elements can be rendered given an available set of codecs.
    Especially when the end system has limited resources, or the
    connection to the end system has limited bandwidth, it would be

Gellens, Singer, Frojdh          [Page 1]          Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

    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, Singer, Frojdh          [Page 2]          Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

Table of Contents
    
     1.  Conventions Used in this Document  . . . . . . . . . . . . .  3
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  The Codecs Parameter . . . . . . . . . . . . . . . . . . . .  5
       3.1.  Generic Syntax  . . . . . . . . . . . . . . . . . . . .   6
       3.2.  ISO File Format Name Space . . . . . . . . . . . . . . .  7
       3.3.  ISO Syntax  . . . . . . . . . . . . . . . . . . . . . .   8
     4.  Use in Additional Media Types  . . . . . . . . . . . . . . .  9
     5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.  Additional Media Feature Details . . . . . . . . . . . . . . 10
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . .  10
     8.  Security Considerations  . . . . . . . . . . . . . . . . . . 10
     9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  11
    10.  Normative References . . . . . . . . . . . . . . . . . . . . 11
    11.  Informative References  . . . . . . . . . . . . . . . . . .  11
    12.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property Statement . . . . . . . . . . . . . . .  12
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
    
    
1.  Conventions Used in this Document
    
    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
    NOT", and "MAY" in this document are to be interpreted as described
    in "Key words for use in RFCs to Indicate Requirement Levels"
    [KEYWORDS].
    
    The syntax in this document uses the BNF rules specified in
    [MIME-Format] and [MIME-Coding].
    
    
2.  Introduction
    
    One of the original motivations for MIME is the ability to identify
    the specific media type of a message part.  However, due to various
    factors, it is not always possible from looking at the MIME type and
    subtype to know which specific media formats are contained in the
    body part, or which codecs are indicated in order to render the
    content.
    
    There are several media type/subtypes (either currently registered
    or deployed with registration pending) which may contain codecs
    chosen from a set.  It is currently necessary to examine each media
    element in order to determine the codecs required to render the
    content.  For example, video/3gpp may contain any of the video
    formats H.263 Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple
    Profile, and/or any of the audio formats AMR, AMR-WB, Extended
    AMR-WB, AAC, or Enhanced aacPlus, as specified in [3GPP-Formats].

Gellens, Singer, Frojdh          [Page 3]          Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

    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.
    
    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]), EVRC, SMV,
        or VMR-WB, as specified in [3GPP2-Formats] (video/3gpp2 MIME
        registration pending).
    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]
        (video/3gpp2 MIME registration pending).
        
    Note that there are additional media types which are ambiguous, but
    are outside the scope of this document, including:
    o   video/mpeg4-generic which can contain anything allowed by the
        MPEG-4 specification, or any audio codec registered with the MP4
        registration authority [MP4-Reg];
    o   video/quicktime which can contain anything for which there is a
        QuickTime codec component; since QuickTime is extensible, this
        is not limited to the codecs that are or have been shipped by
        Apple Computer.
        
    With each "bucket" type, a receiving agent only knows that it has a
    container format.  It doesn't even know whether content labeled
    video/3GPP or video/3GPP2 contains video; it might be audio only,
    audio and video, or video only.
    

Gellens, Singer, Frojdh          [Page 4]          Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

    A solution which permits a receiving agent to determine the specific
    codecs required to render media content would help provide efficient
    and scalable servers, especially for Multimedia Messaging (MMS), and
    aid the growth of multimedia services in wireless networks.
    
    
3.  The Codecs Parameter
    
    This document adds a parameter to allow unambiguous specification of
    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 which contain ambiguity are strongly encouraged to
    include this parameter.
    
    Media types:
        audio/3gpp,
        audio/3gpp2*,
        video/3gpp,
        video/3gpp2*,
        
        *registration pending
    
    Parameter name:
        Codecs
    
    Parameter value:
        A single value, or a comma-separated list of values 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
        starts with two single quote ("'") characters (indicating that
        neither character set nor language are specified), and each
        octet which requires encoding is represented as a percent-sign
        ("%") followed by two hexadecimal digits.  Note that, when the
        [MIME-Coding] form is used, the percent sign, asterisk, and
        single quote characters have special meaning and so must
        themselves be encoded.

Gellens, Singer, Frojdh          [Page 5]          Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

        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 which 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 which 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 which 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, Singer, Frojdh          [Page 6]          Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

    This BNF uses the rules specified in [MIME-Format] and
    [MIME-Coding].
    

    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 *( "." element )

    element     = 1*octet-sim

    octet-sim   = <any TOKEN character except ".">
                ; token defined in [MIME-Format]

    cod-fancy   = "codecs*" "=" encodedv

    encodedv    = fancy-sing / fancy-list

    fancy-sing  = "''" id-encoded

    fancy-list  = DQUOTE "''" id-list DQUOTE

    id-list     = id-encoded *( "," id-encoded )

    id-encoded  = encoded-elm *( "." encoded-elm )

    encoded-elm = 1*octet-fancy
    
    octet-fancy = ext-octet / attribute-char
                ; ext-octet and attribute-char defined in [MIME-coding]

    DQUOTE      = %x22 ; " (double quote)
    
    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
    

Gellens, Singer, Frojdh          [Page 7]          Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

    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".
    
3.3.  ISO Syntax
    
    id-simple   =/ id-iso

    id-encoded  =/ id-iso

    id-iso      = iso-gen / iso-mpega / iso-mpegv
    
    iso-gen     = cpid *( "." 1(element / encoded-elm ) )
                ; <element> used with <codecs-simple>
                ; <encoded> used with <codecs-fancy>
    
    iso-mpega   = mp4a "." oti [ "." aud-oti ]
    

Gellens, Singer, Frojdh          [Page 8]          Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

    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.
    
    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)

Gellens, Singer, Frojdh          [Page 9]          Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

    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" and sometimes
    "media characteristics".
    
    When such additional features are included, the [Content-Features]
    header provides a handy way to do so.
    
    
7.  IANA Considerations
    
    The IANA is kindly requested to add "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 for which it is available.
    Each audio and video media type has its own set of security
    considerations which continue to apply, regardless of the use of the
    codecs parameter.
    
    An incorrect codecs parameter might cause media content to be
    received by a device which is not capable of rendering it, or might
    cause media content to not be sent to a device which is capable of
    receiving it.  An incorrect codecs parameter is therefore capable of
    some types of denial of service attacks.  However, this is most
    likely to arise by accident, as an attacker capable of altering
    media data in transit could cause more harm by altering the media
    format itself, or even the content type header, rather than just the
    codecs parameter of the content type header.

Gellens, Singer, Frojdh         [Page 10]         Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

9.  Acknowledgments
    
    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.
    
    
10.  Normative References
    
    [Content-Features] Kline, G., "Indicating Media Features for MIME
    Content", RFC 2912, September 2000.
    
    [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
    Requirement Levels", March 1997, BCP 14, RFC 2119,
    <ftp://ftp.isi.edu/in-notes/rfc2119.txt>
    
    [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 2996.
    
    [MIME-Types] Freed, N. and N. Borenstein, "Multipurpose Internet
    Mail Extensions (MIME) Part Two:  Media Types", RFC 2046, November
    1996.
    
    [Media-Features] Holtman, K., A. Mutz and T. Hardie, "Media Feature
    Tag Registration Procedure", RFC 2506, BCP 31, March 1999.
    
    [MP4-reg] MP4REG, The MPEG-4 Registration Authority,
    <url://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, Singer, Frojdh         [Page 11]         Expires December 2005


Internet Draft              The Codecs Parameter              June 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:2001, "Information technology--Coding of
    audio-visual objects--Part 1:  Systems".
    
    [MP4A] ISO/IEC 14496-3:2001, "Information Technology--Coding of
    Audio/Visual Object--Part 3:  Audio".
    
    [MP4V] ISO/IEC 14496-2:2001, "Information Technology--Coding of
    Audio/Visual Object--Part 2:  Video".
    
    
12.  Authors' Addresses
    
    Randall Gellens  
    QUALCOMM Incorporated              
    5775 Morehouse Drive
    San Diego, CA  92121
    USA
    randy@qualcomm.com
    
    David Singer
    Apple Computer, Inc.
    One Infinite Loop, MS:302-3MT
    Cupertino  CA 95014
    USA
    singer@apple.com
    +1 408 974 3162
    
    Per Frojdh
    Ericsson Research
    Multimedia Technologies
    SE-164 80 Stockholm, SWEDEN
    +46 8 7190000
    Per.Frojdh@ericsson.com
    
    

Gellens, Singer, Frojdh         [Page 12]         Expires December 2005


Internet Draft              The Codecs Parameter              June 2005

Intellectual Property Statement
    
    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.
    
    
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.
    

Gellens, Singer, Frojdh         [Page 13]         Expires December 2005