doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc4281.txt b/doc/rfc/rfc4281.txt
new file mode 100644
index 0000000..97ae375
--- /dev/null
+++ b/doc/rfc/rfc4281.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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]
+