datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

The Codecs Parameter for "Bucket" Media Types
RFC 4281

Document type: RFC - Proposed Standard (December 2005; Errata)
Obsoleted by RFC 6381
Was draft-gellens-mime-bucket (individual in tsv area)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4281 (Proposed Standard)
Responsible AD: Allison Mankin
Send notices to: rg+ietf@qualcomm.com, hardie@qualcomm.com

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

[include full document text]