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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（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.
この文書では、内に含まれるメディアフォーマットで示さコーデックの明確な指定を可能にするために、様々なタイプ/サブタイプの組み合わせに、新しいパラメータ、「コーデック」を加算します。
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
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）、[3GPP-フォーマット]で指定され、AMR-WB、アドバンストオーディオコーディング（AAC）、または拡張aacPlus対応を拡張。
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などの）制約されたメモリ、処理能力、または伝送帯域幅を持つデバイス上のスマートクライアントへの挑戦を提示します。彼らは現在、MMSや電子メールメッセージに含まれるコンテンツをレンダリングすることができる場合には、このようなクライアントは、多くの場合、事前に決定する必要があります。
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].
[3GPP-フォーマット]で指定されるように、Oオーディオ/ 3GPPは、AMR、AAC、AMR-WB、拡張AMR-WB、または拡張aacPlus対応の内容を含むことができます。 Oオーディオ/ 3GPP2は、AMR、AAC、（[13K]の通り）13K、[3GPP2-フォーマット]で指定されるように拡張可変レートコーデック（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 MPEG-4仕様で許可さ何か、またはMP4登録局に登録されたコーデックを含むことができ、ビデオ/ MPEG4-ジェネリック、[MP4-REG]。 QuickTimeのコーデックコンポーネントが存在するために何を含めることができますOビデオ/ 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.
各「バケット」タイプでは、受信エージェントは、それがコンテナフォーマットを持っていることを知っています。それも、コンテンツラベルされたビデオ/ 3GPPまたはビデオ/ 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].
キーワード「REQUIRED」、「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、要件レベルを示すためにRFCで使用するためのキーワード」で説明したように、この文書に解釈されるべきである「MAY」 「[キーワード]。
The syntax in this document uses the BNF rules specified in [MIME-Format] and [MIME-Coding].
この文書の構文は、[MIME-フォーマット]で指定されたBNF規則を使用し、[MIME-コーディング]。
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.
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-フォーマット]あたり、（複数の値を区切るために使用されるカンマを含む）いくつかの文字が全体のパラメータ値を引用符で囲まれることを必要とします。
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-形式]に準拠するために符号化されなければならないオクテットを含むかもしれません。この場合には、[MIME符号化]が使用される：アスタリスク（「*」）パラメータ名の末尾に配置されている（代わりに「コーデック」の「コーデック*」となる）、パラメータ値は通常、2つの単一引用符で始まります（いずれも文字セットや言語が指定されていることを示す）（「' 『）の文字、符号化を必要とする各オクテットは、2桁の16進数が続くパーセント記号（』％」）として表されます。 [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"
一般的な構文の例：コーデック= a.bb.ccc.dコーデック= "a.bb.ccc.d、e.fff" コーデック* = '' ％FO 2eのコーデック* = " '' ％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'.
注：パラメータ値が「幅」に完全かつ正確でなければならないが、システムのそれは、完全なものに頼ってはならない（つまり、それは例えば、ISO-家族のファイルのすべてのトラックに使用されているすべての4文字のコードを報告しなければなりません）は、深さ」。与えられたコード（例えば、「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.
受信機は、そのコーデックのパラメータの任意のメディア要素で示されていないコーデックを含んでいる身体の部分に遭遇した場合、受信機は、コーデックパラメータの情報を破棄することによって身体部分を処理しなければなりません。
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).
コーデックパラメータには2つの形式のいずれかをとります。値は、符号化を必要とする任意のオクテットを含んでいない場合に最初のフォームが使用されます。第二の形式の用途[MIME符号化]任意のオクテットが符号化されることを可能にします。フォームのいずれかで、引用符が<tspecials>（引用符は必要ありません場合でも使用することがあります）にカンマやその他の文字を可能にします。
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 ",".
実装は、「」の後を除いて、トークンの間CFWSを追加してはなりません。
codecs := cod-simple / cod-fancy
コーデック：=タラシンプル/タラファンシー
cod-simple := "codecs" "=" unencodedv
タラシンプル：=「コーデック」「=」unencodedv
unencodedv := id-simple / simp-list
エンコードされていないビデオ・シンプル/簡単なリスト
simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE
簡体字-リスト：= DQUOTEのID-シンプル*（ "" ID-シンプル）DQUOTE
id-simple := element ; "." reserved as hierarchy delimiter
ID-簡単：=エレメント。 ""階層区切り文字として予約
element := 1*octet-sim
要素：= 1 *オクテット-SIM
octet-sim := <any TOKEN character> ; <TOKEN> defined in [MIME-Format] ; ; Within a Codecs parameter value, "." is reserved ; as a hierarchy delimiter
オクテット-SIM：= <任意の文字TOKEN>。 <TOKEN> [MIME-形式]で定義されます。 ;コーデックパラメータ値の中で、「」予約されています。階層区切り文字として
cod-fancy := "codecs*" ":=" encodedv
タラ空想：= "コーデック*" "：=" 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
空想-歌う：= [文字セット] " '" [言語] "'" IDエンコード。パーサは<言語>を無視してもよいです。パーサはUS-ASCIIとUTF-8をサポートしてもよい（MAY）
fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE ; Parsers MAY ignore <language> ; Parsers MAY support only US-ASCII and UTF-8
空想リスト：= DQUOTE [文字セット] " '" [言語] "'" ID-リストDQUOTE。パーサは<言語>を無視してもよいです。パーサはUS-ASCIIとUTF-8をサポートしてもよい（MAY）
id-list := id-encoded *( "," id-encoded )
IDリスト：= IDでエンコードされた（* "" ID-コードされます）
id-encoded := encoded-elm *( "." encoded-elm ) ; "." reserved as hierarchy delimiter
IDエンコード：=エンコードさ-ニレ*（ ""、符号化ELM）。 ""階層区切り文字として予約
encoded-elm := 1*octet-fancy
エンコードされた-ニレ：= 1 *オクテットファンシー
octet-fancy := ext-octet / attribute-char ; <ext-octet> and <attribute-char> defined in ; [MIME-Coding]
オクテット空想：= EXT-オクテット/属性-CHAR。 <EXT-オクテット>と<属性-CHAR>で定義されています。 [MIME符号化]
DQUOTE := %x22 ; " (double quote)
DQUOTE：=％X22; "（二重引用符）
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.
MP4登録機関[MP4-REG]で登録されISOベースメディアファイルフォーマットのため、コーデックのパラメータ値の最初の要素は、サンプル記述エントリ4文字コードです。値は、大文字と小文字が区別されます。
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ビデオのいくつかの種類を示す）である場合、第2の要素はMP4登録の16進表現であります権限ObjectTypeIndication（OTI）、[MP4-REG]及び[MP41]で指定されるように（修正を含みます）。 [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の値の1つが（MPEG-4オーディオを識別する）40です。この値は、第3の要素が[MP4A（修正を含む）で定義されているオーディオObjectTypeIndication（OTI）を識別し、10進数で表現。
For example, AAC low complexity has the value 2, so a complete string for AAC-LC would be "mp4a.40.2".
例えば、AAC低複雑度は値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の値の1つが（MPEG-4パート2ビデオを識別する）20です。この値は、[MP4V]（修正を含む）で定義されるように第三の要素は、ビデオProfileLevelIndicationを識別する、10進数として表現。
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-簡単：= / ID-ISO
id-encoded :=/ id-iso
IDエンコード：= / 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-GEN：= CPID *（要素/符号化された-ELM）。 <要素> <コーデック-シンプル>で使用します。 <コーデック-ファンシー>と共に使用<符号化され、ELM>。 ; BNFの許すことに注意してください「」 <要素>内。そして、<エンコード-ELM>が、 ""予約されています。階層区切り文字
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（オクテット簡単/オクテット空想）。 <オクテットシンプルな> <コーデック-シンプル>で使用します。 <オクテットファンシー>で使用する<コーデック-ファンシー>
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"）。先頭の「0x」が省略します
aud-oti := 1*DIGIT
聞く-OTI：= 1 * DIGIT
mp4v := %x6d.70.34.76 ; 'mp4v' vid-pli := 1*DIGIT
mp4v：=％x6d.70.34.76。顔より 'Mp4v'：= 1 *桁
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ファイル形式、のために行われる必要があることすべては、このドキュメントを参照して、コーデックのパラメータを指定するには、メディアタイプの登録を更新することです。既存のメディアタイプの場合、パラメータがオプションであるためには、一般的に賢明です。新しいメディアタイプのため、パラメータは必要に応じて、オプションまたは必要になることがあります。
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ファイル形式の場合は、新しい文書が追加の詳細を指定することで、この1を更新することができます。
For non-ISO formats, a new document MAY update this one by specifying the name space for the media type(s).
非ISO形式の場合、新しい文書は、メディアタイプ（S）のための名前空間を指定することで、この1を更新することができます。
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)
コンテンツタイプ：ビデオ/ 3GPP2。コーデック= "sevc、S263"（EVRCオーディオプラスH.263ビデオ）のContent-Type：オーディオ/ 3GPP;コーデック= SAMR（AMRオーディオ）のContent-Type：ビデオ/ 3GPP;コーデック= "S263、SAMR"（H.263ビデオプラスAMRオーディオ）のContent-Type：オーディオ/ 3GPP2。コーデック= mp4a.E1（13Kオーディオ）のContent-Type：ビデオ/ 3GPP2。コーデック= "mp4v.20.9、mp4a.E1"（MPEG-4ビジュアルシンプルプロファイルレベル0プラス13K声）
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).
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.
このような追加機能が含まれている場合は、[コンテンツ特長]ヘッダは、そうするための便利な方法を提供します。
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.
コーデックパラメータ自体は、それが使用しているメディアタイプのいずれかのセキュリティ上の考慮事項を変更しません。各オーディオとビデオのメディアタイプに関係なく、コーデックパラメータの使用、引き続き適用されたセキュリティ上の考慮事項の独自のセットを持っています。
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 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.
間違ったコーデックパラメータは、メディアコンテンツがそれをレンダリングすることはできない、またはメディアコンテンツがそれを受信することが可能であるデバイスに送信されないために発生する可能性がありますデバイスによって受信されることがあります。間違ったコーデックパラメータは、サービス拒否攻撃のいくつかのタイプのため、可能です。輸送中のメディアデータを変えることができる攻撃者がメディアフォーマット自体を変化させることによって、より多くの害を引き起こす可能性があるのでしかし、これは、事故によって生じた可能性が最も高い、あるいはコンテンツタイプヘッダーではなく、コンテンツタイプヘッダのちょうどコーデックパラメータ。
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は非常に高く評価され、ヘルプの多くを、提供します。メアリー・バーンズとブルース・リリーは詳細かつ有益なコメントを提供しました。サム・ハートマン、ラスHousley、およびバートWijnenによるレビューやコメントは大歓迎されました。クリス・ニューマンは、慎重に検討し、BNFを改善しました。
[Content-Features] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
、RFC 2912、2000年9月 "MIMEコンテンツのメディアの特徴を示す" [コンテンツ特長] Klyne、G.、。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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-コーディング]フリード、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年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-フォーマット]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年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.ハーディ、 "メディア特徴タグの登録手順"、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 3625、2003年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 /仕様/ HTML-情報/ 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は、 "情報は、オーディオ・ビジュアルオブジェクトのコーディングをtechnology-- - パート1：システム"。
[MP4A] ISO/IEC 14496-3:2001, "Information technology-- Coding of audio-visual objects--Part 3: Audio".
[MP4A] ISO / IEC 14496-3：2001、 "情報はオーディオビジュアルオブジェクトのコーディングtechnology-- - 第3部：オーディオ"。
[MP4V] ISO/IEC 14496-2:2004, "Information technology-- Coding of audio-visual objects--Part 2: Visual".
[MP4V] ISO / IEC 14496-2：2004、 "情報はオーディオビジュアルオブジェクトのコーディングtechnology-- - パート2：ビジュアルを"。
Authors' Addresses
著者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
ランドールGellens QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121 USA
EMail: randy@qualcomm.com
メールアドレス：randy@qualcomm.com
David Singer Apple Computer, Inc. One Infinite Loop, MS:302-3MT Cupertino CA 95014 USA
デビッド・シンガーたApple Computer、Inc.の一つ無限ループ、MS：302-3MTクパチーノCA 95014 USA
EMail: singer@apple.com Phone: +1 408 974 3162
メールアドレス：singer@apple.com電話：+1 408 974 3162
Per Frojdh Ericsson Research Multimedia Technologies SE-164 80 Stockholm, SWEDEN
パーFrojdhエリクソン研究マルチメディア・テクノロジーズSE-164 80ストックホルム、スウェーデン
EMail: Per.Frojdh@ericsson.com Phone: +46 8 7190000
メールアドレス：Per.Frojdh@ericsson.com電話：+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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。