[要約] RFC 4281は、メディアタイプ「Bucket」のためのコーデックパラメータに関する仕様です。このRFCの目的は、メディアタイプ「Bucket」のコーデックパラメータの定義と使用方法を提供することです。
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).
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.
さまざまなメディア形式を含めることができるいくつかの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の元の動機の1つは、メッセージパーツの特定のメディアタイプを識別する機能です。ただし、さまざまな要因により、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、Advanced Audio Coding（AAC）、またはAdced adced（AC）、Adsucted Amr-WBは、
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].
o Audio/3GPPには、[3GPP-Formats]で指定されているように、AMR、AAC、AMR-WB、拡張AMR-WB、または強化されたAACPLUSコンテンツを含めることができます。o Audio/3GPP2には、[3GPP2-Formats]で指定されているように、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を含むことができます。oビデオ/3GPP2には、H.263プロファイル0、H.263プロファイル3、H.264、MPEG-4シンプルなプロファイル、および/またはAMR、AAC、13K（[13K]、SMV、またはVMR-WB）を含むことができます。
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-Generic。MPEG-4仕様によって許可されているもの、またはMP4登録機関に登録されているコーデック[MP4-REG]を含むことができます。oビデオ/QuickTime。これには、QuickTime Codecコンポーネントがあるものを含めることができます。QuickTimeは拡張可能であるため、これはAppleコンピューターによって出荷されているコーデックに限定されません。
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.
各「バケット」タイプで、受信エージェントはコンテナ形式があることのみを知っています。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-format]および[Mime-Coding]で指定された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,
メディアタイプ：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.
各値は、1つ以上のドット分離された要素で構成されています。最初の要素の名前スペースは、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 sign, asterisk, and single quote characters have special meaning and so must themselves be encoded.
要素には、[mime-format]に準拠するためにエンコードする必要があるオクテットを含めることができます。この場合、[mime-coding]が使用されます。アスタリスク（ "*"）がパラメーター名の最後（「コーデック」の代わりに「コーデック*」になる）に配置されます。パラメーター値は通常、2つの単一の引用（「 '"）から始まります（「' '"）文字（文字セットも言語も指定されていないことを示します）、およびそれぞれのオクタイジングがeccodingを指示する必要があります。[mime-coding]フォームを使用する場合、パーセントサイン、アスタリスク、および単一の引用文字には特別な意味があるため、それ自体をエンコードする必要があることに注意してください。
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.
Codecsパラメーターを使用する場合、身体部分に存在するコンテンツで示されるすべてのコーデックを含める必要があります。コーデックパラメーターには、身体部分のメディア要素によって示されないコーデックを含めてはなりません。
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-Familyファイルのすべてのトラックで使用されるすべての4つのCharacterコードを報告する必要があります。たとえば、システムは「Depth」で完全であることに依存してはなりません。たとえば、サーバーが実装された後に特定のコードの階層ルール（「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つのフォームのいずれかを取得します。最初のフォームは、値にエンコードを必要とするオクテットが含まれていない場合に使用されます。2番目のフォームは[Mime-Coding]を使用して、任意のオクテットをエンコードできるようにします。どちらの形式でも、引用符は<tspecials>のコンマやその他のキャラクターを許可します（不要な場合でも引用符は使用できます）。
This BNF uses the rules specified in [MIME-Format] and [MIME-Coding].
このBNFは、[mime-format]および[mime-coding]で指定されたルールを使用します。
Implementations MUST NOT add CFWS between the tokens except after ",".
実装は、「、「」の後を除き、トークン間にCFWを追加してはなりません。
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
id-simple：= element;「。」階層デリミッターとして予約されています
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)
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.
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ベースメディアファイル形式の場合、Codecsパラメーター値の最初の要素は、MP4登録機関[MP4-REG]によって登録されているサンプル説明エントリ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ファイル形式のすべてではありませんが、トラックのサンプルエントリの数が1つに制限されます）。
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番目の要素は、[MP41]と[MP41]を含むように、MP4-Reg]および[MP41]に指定されているように、MP4登録機関オブジェクトタイプインジケーション（OTI）の16進表現です。[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つは40です（MPEG-4オーディオを識別）。この値については、3番目の要素は、[MP4a]（修正を含む）で定義されているAudio ObjectTypeindication（OTI）を小数点以下として識別します。
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つは20です（MPEG-4パート2ビデオを識別）。この値については、3番目の要素は、[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の完全な文字列は「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
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
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)
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).
注：OTI値20（[MP4-Reg]の "0x20"）は「関連する修正（s）と回復（a）を含む。実際のオブジェクトタイプは[mp4v]で定義され、[mp4v]、概説nex 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.
このような追加機能が含まれている場合、[コンテンツフィーチュア]ヘッダーは、それを行うための便利な方法を提供します。
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.
Codecsパラメーター自体は、使用されているメディアタイプのセキュリティに関する考慮事項を変更しません。各オーディオおよびビデオメディアタイプには、コーデックパラメーターの使用に関係なく、適用され続ける独自のセキュリティに関する考慮事項があります。
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は多大な助けを提供しましたが、これは非常に高く評価されています。メアリー・バーンズとブルース・リリーは、詳細で有益なコメントを提供しました。Sam Hartman、Russ Housley、およびBert Wijnenによるレビューとコメントは大歓迎でした。クリス・ニューマンはBNFを慎重にレビューし、改善しました。
[Content-Features] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[Content-Features] 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-Coding] Freed、N。and K. Moore、「Mimeパラメーター値とエンコードされた単語拡張機能：文字セット、言語、継続」、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-format] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[Media-Features] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[Media-Features] 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 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-formats] TS 26.244、第三世代パートナーシッププロジェクト（3GPP）、「透明なエンドツーエンドパケットスイッチングストリーミングサービス; 3GPPファイル形式（3GP）」、URL：<http://www.3gpp.org/ftp/specs/html-info/ 2624.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-Formats]第3世代パートナーシッププロジェクト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
ランドール・ゲレンズ・クアルコム・インコーポレーテッド5775モアハウス・ドライブサンディエゴ、カリフォルニア州92121 USA
EMail: randy@qualcomm.com
David Singer Apple Computer, Inc. One Infinite Loop, MS:302-3MT Cupertino CA 95014 USA
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
Frojdh Ericsson Research Multimedia Technologies SE-164 80 Stockholm、Sweden
EMail: Per.Frojdh@ericsson.com
Phone: +46 8 7190000
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
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.
この文書は、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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。