Network Working Group R. Gellens
Request for Comments: 4281 Qualcomm
Category: Standards Track D. Singer
Apple
P. Frojdh
Ericsson
November 2005
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
“Bucket”媒体类型的codecks参数
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
存在多个MIME类型/子类型组合，它们可以包含不同的媒体格式。因此，接收代理需要检查此类媒体内容的细节，以确定在给定一组可用编解码器的情况下是否可以呈现特定元素。特别是当终端系统的资源有限，或者与终端系统的连接带宽有限时，仅从内容类型了解内容是否可以呈现是很有帮助的。
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.
本文档在各种类型/子类型组合中添加了一个新参数“codecs”，以明确指定其中包含的媒体格式所指示的编解码器。
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.)
通过使用指定用于呈现包含媒体的特定编解码器标记内容，接收系统可以确定终端系统是否支持编解码器，如果不支持，则可以采取适当的操作（例如拒绝内容、发送情况通知、将内容转换为支持的类型、获取和安装所需的编解码器、进一步检查以确定是否足以支持所示编解码器的子集等。）
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 ....................................................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
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.
MIME最初的动机之一是能够识别消息部分的特定媒体类型。但是，由于各种因素，查看MIME类型和子类型并不总是能够知道主体部分中包含哪些特定媒体格式，或者指示哪些编解码器来呈现内容。
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].
有几种媒体类型/子类型（当前已注册或已部署且注册挂起）包含从集合中选择的编解码器。目前有必要检查每个媒体元素，以确定呈现内容所需的编解码器。例如，视频/3gpp可以包含任何视频格式H.263简档0、H.263简档3、H.264、MPEG-4简单简档和/或任何音频格式自适应多速率（AMR）、自适应多速率宽带（AMR-WB）、扩展AMR-WB、高级音频编码（AAC）或增强aacPlus，如[3gpp格式]中所规定。
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.
对于各种客户端和服务器来说，这种模糊性可能是一个问题。它给彩信（MMS）服务器带来了巨大的负担，这些服务器必须检查每条消息中发送的媒体，以确定需要哪些编解码器来呈现内容。只有这样，这样的服务器才能确定内容在传输到手机之前是否需要转码或专门处理。
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.
此外，它对内存、处理能力或传输带宽受限的设备（如蜂窝电话和PDA）上的智能客户端提出了挑战。此类客户端通常需要提前确定当前是否能够呈现彩信或电子邮件中包含的内容。
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].
o 音频/3gpp可以包含[3gpp格式]中指定的AMR、AAC、AMR-WB、扩展AMR-WB或增强aacPlus内容。o音频/3gpp2可包含[3gpp2格式]中规定的AMR、AAC、13K（根据[13K]）、增强型可变速率编解码器（EVRC）、可选模式声码器（SMV）或VMR-WB。o视频/3gpp可以包含H.263配置文件0、H.263配置文件3、H.264、MPEG-4简单配置文件和/或AMR、AMR-WB、扩展AMR-WB、AAC或增强aacPlus，如[3gpp格式]中所述。o视频/3gpp2可以包含H.263配置文件0、H.263配置文件3、H.264、MPEG-4简单配置文件和/或AMR、AAC、13K（根据[13K]）、EVRC、SMV或VMR-WB，如[3gpp2格式]中所规定。
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.
o 视频/mpeg4通用，可包含MPEG-4规范允许的任何内容，或在MP4注册机构[MP4 Reg]注册的任何编解码器；o视频/quicktime，它可以包含任何有quicktime编解码器组件的内容；由于QuickTime是可扩展的，所以它不仅限于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.
对于每个“bucket”类型，接收代理只知道它有一个容器格式。它甚至不知道标记为video/3gpp或video/3gpp2的内容是否包含视频；它可能是纯音频、音频和视频或纯视频。
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.
允许接收代理确定呈现媒体内容所需的特定编解码器的解决方案将有助于提供高效和可扩展的服务器，特别是用于彩信（MMS），并有助于无线网络中多媒体服务的增长。
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].
本文件中的关键词“必需”、“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于指示需求水平的关键词”[关键词]中的描述进行解释。
The syntax in this document uses the BNF rules specified in [MIME-Format] and [MIME-Coding].
本文档中的语法使用[MIME格式]和[MIME编码]中指定的BNF规则。
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.
本文档添加了一个参数，以允许明确指定用于呈现MIME部分内容的所有编解码器。此参数在添加到的所有当前类型中都是可选的。强烈建议包含歧义的未来类型包含此参数。
Media types: audio/3gpp, audio/3gpp2, video/3gpp, video/3gpp2,
媒体类型：音频/3gpp、音频/3gpp2、视频/3gpp、视频/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.
每个值由一个或多个点分隔的元素组成。第一个元素的名称空间由MIME类型决定。每个后续元素的名称空间由前面的元素确定。
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.
请注意，根据[MIME Format]，某些字符（包括用于分隔多个值的逗号）要求将整个参数值括在引号中。
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
一个元素可能包含一个八位字节，必须对其进行编码才能符合[MIME Format]。在这种情况下，使用[MIME编码]：将星号（“*”）放在参数名称的末尾（变成“codecs*”而不是“codecs”），参数值通常以两个单引号（“”）字符开头（表示未指定字符集或语言），每个需要编码的八位字节都用百分号（“%”）表示，后跟两个十六进制数字。注意，当使用[MIME编码]形式时，百分比
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"
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.
使用codecks参数时，它必须包含由正文部分中的内容指示的所有编解码器。codecks参数不得包括任何未由主体部分中的任何媒体元素指示的编解码器。
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'.
注意：尽管参数值在“宽度”中必须完整且准确（即，它必须报告ISO系列文件的所有轨迹中使用的所有四个字符的代码），但系统不能依赖于它在“深度”中的完整性。例如，如果给定代码（例如，“qvxy”）的分层规则是在服务器实现之后编写的，则该服务器将不知道在“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.
如果接收器遇到其Codecs参数包含未由任何媒体元素指示的编解码器的主体部分，则接收器应通过丢弃Codecs参数中的信息来处理主体部分。
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.
如果接收器遇到编解码器参数不包含由媒体元素指示的所有编解码器的身体部分，则接收器可通过丢弃编解码器参数中的信息来处理身体部分。
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).
Codecodes参数采用两种形式之一。当值不包含任何需要编码的八位字节时，使用第一种形式。第二种形式使用[MIME编码]允许对任意八位字节进行编码。无论采用哪种形式，引号都允许在<t特殊规范>（即使不需要引号，也可以使用引号）中使用逗号和其他字符。
This BNF uses the rules specified in [MIME-Format] and [MIME-Coding].
此BNF使用[MIME格式]和[MIME编码]中指定的规则。
Implementations MUST NOT add CFWS between the tokens except after ",".
实现不能在令牌之间添加CFW，除非在“，”之后。
codecs := cod-simple / cod-fancy
codecs := cod-simple / cod-fancy
cod-simple := "codecs" "=" unencodedv
cod-simple := "codecs" "=" unencodedv
unencodedv := id-simple / simp-list
unencodedv := id-simple / simp-list
simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE
simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE
id-simple := element ; "." reserved as hierarchy delimiter
id simple:=元素；“.”保留为层次分隔符
element := 1*octet-sim
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
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
cod-fancy := "codecs*" ":=" encodedv
encodedv := fancy-sing / fancy-list
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-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
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-list := id-encoded *( "," id-encoded )
id-encoded := encoded-elm *( "." encoded-elm )
; "." reserved as hierarchy delimiter
id-encoded := encoded-elm *( "." encoded-elm )
; "." reserved as hierarchy delimiter
encoded-elm := 1*octet-fancy
encoded-elm := 1*octet-fancy
octet-fancy := ext-octet / attribute-char
; <ext-octet> and <attribute-char> defined in
; [MIME-Coding]
octet-fancy := ext-octet / attribute-char
; <ext-octet> and <attribute-char> defined in
; [MIME-Coding]
DQUOTE := %x22 ; " (double quote)
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.
初始名称空间：本文档仅定义ISO基本媒体文件格式系列中文件的值。其他文件格式也可以定义编解码器命名。
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.
对于ISO基本媒体文件格式，编解码器参数值的第一个元素是由MP4注册机构[MP4 Reg]注册的示例描述条目四字符代码。值区分大小写。
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).
请注意，一个文件中可能有多个磁道，每个磁道都可能包含多个示例条目（ISO文件格式的某些但并非全部使用将一个磁道中的示例条目数限制为一个）。
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.
当值的第一个元素是“mp4a”（表示某种MPEG-4音频）或“mp4v”（表示某种MPEG-4第2部分视频）时，第二个元素是[MP4 Reg]和[MP41]（包括修改件）中规定的MP4注册机构对象类型指示（OTI）的十六进制表示。请注意，[MP4 Reg]将前导“0x”与这些值一起使用，此处省略，因此暗示。
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.
“mp4a”的OTI值之一是40（识别MPEG-4音频）。对于该值，第三个元素标识[MP4A]（包括修改件）中定义的音频对象类型指示（OTI），表示为十进制数。
For example, AAC low complexity has the value 2, so a complete string for AAC-LC would be "mp4a.40.2".
例如，AAC low complexity的值为2，因此AAC-LC的完整字符串应为“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.
“mp4v”的OTI值之一是20（标识MPEG-4第2部分视频）。对于该值，第三个元素标识[MP4V]（包括修改件）中定义的视频配置文件级别指示，表示为十进制数。
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".
例如，MPEG-4视觉简单配置文件级别0的值为9，因此MPEG-4视觉简单配置文件级别0的完整字符串应为“mp4v.20.9”。
id-simple :=/ id-iso
id-simple :=/ id-iso
id-encoded :=/ id-iso
id-encoded :=/ id-iso
id-iso := iso-gen / iso-mpega / iso-mpegv
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-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 ]
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>
cpid := 4(octet-simple / octet-fancy)
; <octet-simple> used with <codecs-simple>
; <octet-fancy> used with <codecs-fancy>
mp4a := %x6d.70.34.61 ; 'mp4a'
mp4a := %x6d.70.34.61 ; 'mp4a'
oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; leading "0x" omitted
oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; leading "0x" omitted
aud-oti := 1*DIGIT
aud-oti := 1*DIGIT
mp4v := %x6d.70.34.76 ; 'mp4v'
vid-pli := 1*DIGIT
mp4v := %x6d.70.34.76 ; 'mp4v'
vid-pli := 1*DIGIT
This parameter MAY be specified for use with additional MIME media types.
可以指定此参数与其他MIME媒体类型一起使用。
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.
对于此处定义的名称空间足够大的ISO文件格式，只需更新媒体类型注册，以参考此文档指定Codecs参数。对于现有媒体类型，通常建议将参数设置为可选参数；对于新媒体类型，参数可能是可选的，也可能是必需的（视情况而定）。
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.
对于需要扩展此处定义的名称空间的ISO文件格式，新文档可以通过指定其他详细信息来更新此文件。
For non-ISO formats, a new document MAY update this one by specifying the name space for the media type(s).
对于非ISO格式，新文档可以通过指定媒体类型的名称空间来更新此文档。
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)
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).
注：[MP4 Reg]中的OTI值20（“0x20”）表示“包括相关修正案和勘误表（a）。实际对象类型在[MP4V]中定义，并在[MP4V]附录K中规定的解码器规范信息中传达”（参考调整）。
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".
有时，提供媒体元素的附加细节（例如，X和Y像素的数量、颜色深度等）会有所帮助。这些细节有时被称为“媒体特征”或“媒体特征”。
When such additional features are included, the [Content-Features] header provides a handy way to do so.
当包含这些附加功能时，[Content features]标题提供了一种方便的方法。
The IANA has added "codecs" as an optional parameter to the media types listed in Section 3, with a reference to this document.
IANA已将“编解码器”作为可选参数添加到第3节中列出的媒体类型中，并参考了本文档。
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.
codecks参数本身不会改变使用它的任何媒体类型的安全考虑。每种音频和视频媒体类型都有自己的一组安全注意事项，无论使用codecks参数如何，这些注意事项都将继续适用。
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
不正确的codecks参数可能导致无法呈现媒体内容的设备接收媒体内容，或者可能导致媒体内容无法发送到能够呈现媒体内容的设备
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.
收到了。因此，不正确的编解码器参数会导致某些类型的拒绝服务攻击。但是，这很可能是偶然发生的，因为能够在传输过程中更改媒体数据的攻击者可能会通过更改媒体格式本身，甚至内容类型标头，而不仅仅是内容类型标头的Codecs参数，造成更大的伤害。
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.
Harinath Garudadri提供了大量帮助，我们对此深表感谢。玛丽·巴恩斯和布鲁斯·莉莉提供了详细而有益的评论。Sam Hartman、Russ Housley和Bert Wijnen的评论和评论非常受欢迎。Chris Newman仔细审查并改进了BNF。
[Content-Features] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[内容特征]Klyne，G.“为MIME内容指示媒体特征”，RFC 2912，2000年9月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MIME-Coding] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[MIME编码]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[MIME-Format] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME格式]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[Media-Features] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[媒体功能]Holtman，K.，Mutz，A.，和T.Hardie，“媒体功能标签注册程序”，BCP 31，RFC 2506，1999年3月。
[MP4-Reg] MP4REG, The MPEG-4 Registration Authority, URL: <http://www.mp4ra.org>.
[MP4 Reg]MP4REG，MPEG-4注册机构，URL:<http://www.mp4ra.org>.
[13k] Gellens, R. and H. Garudadri, "The QCP File Format and Media Types for Speech Data", RFC 3625, September 2003.
[13k]Gellens，R.和H.Garudadri，“语音数据的QCP文件格式和媒体类型”，RFC 36252003年9月。
[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>.
[3GPP格式]TS 26.244，第三代合作伙伴计划（3GPP），“透明端到端分组交换流媒体服务；3GPP文件格式（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>.
[3GPP2格式]第三代合作项目2，“多媒体服务的3GPP2文件格式”，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".
[MP41]ISO/IEC 14496-1:2004，“信息技术——视听对象的编码——第1部分：系统”。
[MP4A] ISO/IEC 14496-3:2001, "Information technology-- Coding of audio-visual objects--Part 3: Audio".
[MP4A]ISO/IEC 14496-3:2001，“信息技术——视听对象的编码——第3部分：音频”。
[MP4V] ISO/IEC 14496-2:2004, "Information technology-- Coding of audio-visual objects--Part 2: Visual".
[MP4V]ISO/IEC 14496-2:2004，“信息技术——视听对象的编码——第2部分：视觉”。
Authors' Addresses
作者地址
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
美国加利福尼亚州圣地亚哥Morehouse大道5775号兰德尔盖伦高通公司，邮编92121
EMail: randy@qualcomm.com
EMail: randy@qualcomm.com
David Singer Apple Computer, Inc. One Infinite Loop, MS:302-3MT Cupertino CA 95014 USA
David Singer苹果电脑有限公司One Infinite Loop，MS:302-3MT Cupertino CA 95014美国
EMail: singer@apple.com
Phone: +1 408 974 3162
EMail: singer@apple.com
Phone: +1 408 974 3162
Per Frojdh Ericsson Research Multimedia Technologies SE-164 80 Stockholm, SWEDEN
Per Frojdh Ericsson Research多媒体技术SE-164 80瑞典斯德哥尔摩
EMail: Per.Frojdh@ericsson.com
Phone: +46 8 7190000
EMail: Per.Frojdh@ericsson.com
Phone: +46 8 7190000
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。