[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 4281

Internet Draft                                               R. Gellens
Document: draft-gellens-mime-bucket-01.txt                     Qualcomm
Expires: April 2005                                        October 2004

             The Codecs Parameter for "Bucket" Media Types

Status of this Memo

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed
    and any of which I become aware will be disclosed, in accordance
    with RFC 3668 (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-

    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

Copyright Notice

    Copyright (C) The Internet Society (2004).  All Rights Reserved.


    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
    helpful to know from the Content-Type alone if the content can be

Gellens                   [Page 1]                   Expires April 2005

Internet Draft             The Codecs Parameter             October 2004

    This document adds a new parameter, "codecs", to various
    type/subtype combinations to allow for unambiguous specification of
    the codecs required to support the media formats contained within.

    By labelling content with the specific codecs required 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, etc.)

Gellens                   [Page 2]                   Expires April 2005

Internet Draft             The Codecs Parameter             October 2004

Table of Contents

     1.  Conventions Used in this Document  . . . . . . . . . . . . .  3
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  The Codecs Parameter . . . . . . . . . . . . . . . . . . . .  5
     4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.  Additional Media Feature Details . . . . . . . . . . . . . .  7
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . .   7
     7.  Security Considerations  . . . . . . . . . . . . . . . . . .  7
     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . .   8
     9.  Normative References . . . . . . . . . . . . . . . . . . . .  8
    10.  Informative References  . . . . . . . . . . . . . . . . . .   9
    11.  Author's Address . . . . . . . . . . . . . . . . . . . . . .  9
       Intellectual Property Statement . . . . . . . . . . . . . . .   9
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
       Disclaimer  . . . . . . . . . . . . . . . . . . . . . . . . .  10

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"

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 required in order to display the

    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, H.263+, H.264, MPEG-4 SPL0, and/or any of the audio
    formats AMR, AMR-WB, or AAC, as specified in [3GPP-Formats].

Gellens                   [Page 3]                   Expires April 2005

Internet Draft             The Codecs Parameter             October 2004

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


    o    audio/3gpp can contain AMR or AAC contents as specified in
    o   audio/3gpp2 can contain AMR, AAC, 13K (as per [13k]), EVRC, or
        SMV, as specified in [3GPP2-Formats] (video/3gpp2 MIME
        registration pending).
    o   video/3gpp can contain H.263, H.263+, H.264, MPEG-4 SPL0, and/or
        AMR, AMR-WB, or AAC, as specified in [3GPP-Formats].
    o   video/3gpp2 can contain H.263, H.263+, H.264, MPEG-4 SPL0,
        and/or AMR, AAC, 13K (as per [13k]), EVRC, or SMV, 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/mp4V-ES and 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 labelled
    video/3GPP or video/3GPP2 contains video; it might be audio only,
    audio and video, or video only.

Gellens                   [Page 4]                   Expires April 2005

Internet Draft             The Codecs Parameter             October 2004

    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
    the codecs required to render the content in a media element.  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, as mandatory if possible, as optional

    Media types:

        *registration pending

    Parameter name:

    Parameter value:
        A single value, or a comma-separated list of values (which must
        be enclosed in quotes to comply with MIME rules) which
        identifies the codec(s) required 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.

        Examples of Generic Syntax:
            "a.bb, c.dd"

        Initial name space:  This document only defines values for files
        in the ISO File Format family.  Other file formats may also
        define codec naming.

Gellens                   [Page 5]                   Expires April 2005

Internet Draft             The Codecs Parameter             October 2004

        For the ISO File format, the first element is a sample
        description entry four-character code as registered by the MP4
        Registration Authority [MP4-Reg].  The values are
        case-sensitive.  For the name 'mp4a', indicating some kind of
        MPEG-4 audio, the second element is the hexadecimal
        representation of the MP4 Registration Authority
        ObjectTypeIndication (OTI) [MP4-Reg] (e.g., the element "0x20").


    codecs      = "Codecs" *SP "=" *SP value

    value       = id / DQUOTE *SP id *(*SP "," *SP id) *SP DQUOTE

    id          = id-ISO / id-gen

    id-gen      = element *( "." element )

    id-ISO      = cpid [ "." oti ]

    cpid        = 4 (idchar / idchar-spec)

    oti         = "0x" 2HEXDIG

    element     = 1*(idchar / idchar-spec)

    idchar      = <any (US-ASCII) CHAR except SPACE, CTLs,
                  "$", or tspecials>

    idchar-spec = "$" 2DIGIT

    tspecials   =  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="

    Note that in some cases, the four-character ID registered in
    [MP4-Reg] may still be ambiguous, even when using the OTI.  For
    example, all mpeg-4 audio codecs are under 'mp4a', including HVXC,
    CELP, GA (which can be AAC, twinVQ, or BSAC), SA, TTSI, HILN (see
    MP4A).  However, since audio/3gpp2, video/3gpp2, audio/3gpp, and
    video/3gpp restrict the allowable ISO code points, there is no
    ambiguity in these four cases.

Gellens                   [Page 6]                   Expires April 2005

Internet Draft             The Codecs Parameter             October 2004

    When the Codecs parameter is used, it MUST contain all codecs
    required to render all content present in the body part.  The Codecs
    parameter MUST NOT contain any codecs which are not present in the
    body part.

4.  Examples

    Content-Type:  Video/3GPP2; Codecs="sevc, s263"
        (EVRC audio plus H.263 video)
    Content-Type:  Audio/3gp; Codecs=samr
        (AMR audio)
    Content-Type: video/3gpp; Codecs="s263, samr"
        (H.263 video plus AMR audio)
    Content-Type: audio/3gpp2; Codecs=mp4a.0xE1
        (13k audio)
    Content-Type: video/3gpp2; Codecs="mp4v.0x20, mp4a.0xE1"
        (Visual ISO/IEC 14496-2 [MP4V] plus 13K voice)

        Note: 0x20 OTI value says "Includes associated Amendment(s) and
        Corrigendum(a).  The actual object types are defined in ISO/IEC
        14496-2 and are conveyed in the DecoderSpecificInfo as specified
        in ISO/IEC 14496-2, Annex K."

    5.  Additional Media Feature Details

        For the same reasons that the Codecs parameter is useful, 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.

    6.  IANA Considerations

        The hard-working IANA staff is kindly requested to add "Codecs"
        as an optional parameter to the media types listed in Section
        3, with a reference to this document

Gellens                   [Page 7]                   Expires April 2005

Internet Draft             The Codecs Parameter             October 2004

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

    8.  Acknowledgements

        David Singer and Harinath Garudadri provided significant help,
        which is very much appreciated.

    9.  Normative References

        [ABNF] Crocker, Overell, "Augmented BNF for Syntax
        Specifications:  ABNF", RFC 2234, Internet Mail Consortium,
        Demon Internet Ltd., November 1997.

        [Content-Features] Kline, G., "Indicating Media Features for
        MIME Content", RFC 2912, September 2000.

        [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

Gellens                   [Page 8]                   Expires April 2005

Internet Draft             The Codecs Parameter             October 2004

        [MP4-reg] MP4REG, The MPEG-4 Registration Authority,

    10.  Informative References

        [13k] Gellens, R and H. Garudadri, "The QCP File Format and
        Media Types for Speech Data", RFC 3625, September 2003.

        [AMR] Sjoberg, J., M. Westerlund, A. Lakaniemi, Q. Xie,
        "Real-Time Transport Protocol (RTP) Payload Format and File
        Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive
        Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.

        [3GPP-Codecs] TS 26.234, Third Generation Partnership Project
        (3GPP), "Transparent end-to-end streaming service; Protocols and
        codecs", URL:

        [3GPP-Formats] TS 26.244, Third Generation Partnership Project
        (3GPP), "Transparent end-to-end streaming service; 3GPP file
        format (3GP)", URL:

        [3GPP2-Formats] Third Generation Partnership Project 2, "3GPP2
        File Formats for Multimedia Service", URL:

        [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".

    11.  Author's Address

    Randall Gellens
    QUALCOMM Incorporated
    5775 Morehouse Drive
    San Diego, CA  92121

Gellens                   [Page 9]                   Expires April 2005

Internet Draft             The Codecs Parameter             October 2004

    Intellectual Property Statement

        The IETF takes no position regarding the validity or scope of
        any intellectual property 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; neither does
        it represent that it has made any effort to identify any such
        rights.  Information on the IETF's procedures with respect to
        rights in standards-track and standards-related documentation
        can be found in BCP-11.  Copies of claims of rights made
        available for publication 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 implementors or users of this specification can be
        obtained from the IETF Secretariat.

        The IETF invites any interested party to bring to its attention
        any copyrights, patents or patent applications, or other
        proprietary rights which may cover technology that may be
        required to practice this standard.  Please address the
        information to the IETF Executive Director.

    Full Copyright Statement

        Copyright (C) The Internet Society (2004).

        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

Gellens                   [Page 10]                   Expires April 2005

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/