RFC4281 日本語訳

Network Working Group                                         R. Gellens
Request for Comments: 4281                                      Qualcomm
Category: Standards Track                                      D. Singer
                                                                   Apple
                                                               P. Frojdh
                                                                Ericsson
                                                           November 2005

Gellensがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4281年のクアルコムカテゴリ: 標準化過程D.歌手アップルP.Frojdhエリクソン2005年11月

             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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(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.)

含まれたメディアを表すために示される特定のコーデックで内容をラベルすることによって、受電方式は、コーデックがエンドシステムによってサポートされるかどうか決定できます、そして、そうでなければ、適切な行動を取ることができます。(サポートしているタイプへの内容を状況の通知、コード変換に送って、内容を拒絶する必要なコーデックをとって来て、インストールする示されたコーデックの部分集合をサポートするのが十分であるかどうか決定するさらなる点検などの)

Gellens, et al.             Standards Track                     [Page 1]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[1ページ]。

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. 序論…2 2. このドキュメントで中古のコンベンション…4 3. コーデックパラメタ…4 3.1. ジェネリック構文…5 3.2. ISOは形式名前スペースをファイルします…7 3.3. ISO構文…8 4. 追加メディアで、タイプを使用してください…8 5. 例…9 6. 追加メディアは詳細を特徴とします…9 7. IANA問題…9 8. セキュリティ問題…9 9. 承認…10 10. 標準の参照…10 11. 有益な参照…10

1.  Introduction

1. 序論

   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の種類を見るのでいつも可能であって、subtypeではありません。

   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はオーディオ形式Adaptive Multi Rate(AMR)のビデオ形式H.263 Profile0のどれか、H.263 Profile3、H.264、MPEG-4Simple Profile、そして/または、どれかを含むかもしれません、Adaptive Multi Rate--[3GPP-形式]における指定されるとしてのWideBand(AMR-WB)、Extended AMR-WB、アドバンスド・オーディオ・コーディング(AAC)、またはEnhanced 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.

このあいまいさは様々なクライアントとサーバのための問題であるかもしれません。 それはMultimedia Messaging(MMS)サーバに重要な負担を寄贈します。(サーバはどのコーデックが内容を表さなければならないかを決定するために各メッセージで送られたメディアを調べなければなりません)。 そして、そのようなサーバは、内容が受話器に伝えられる前にコード変換か専門化している取り扱いを必要とするかどうか決定できるだけです。

Gellens, et al.             Standards Track                     [Page 2]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[2ページ]。

   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 オーディオ/3gppは3GPP-Formatsの指定されるとしてのAMR、AAC、AMR-WB、Extended AMR-WB、またはEnhanced aacPlusコンテンツを含むことができます。oオーディオ/3gpp2は3GPP2-FormatsのAMR、AAC、13K(13kに従って)、Enhanced Variable Rate Codec(EVRC)、Selectable Mode Vocoder(SMV)、または指定されるとしてのVMR-WBを含むことができます。oビデオ/3gppはH.263 Profile0を含むことができます、H; 263 3GPP-Formats oビデオ/3gpp2の指定されるとしてのプロフィール3、H.264、MPEG-4Simple Profile、そして/または、AMR、AMR-WB、Extended AMR-WB、AAC、またはEnhanced aacPlusが3GPP2-形式における指定されるとしてのH.263 Profile0、H.263 Profile3、H.264、MPEG-4Simple Profile、そして/または、AMR、AAC、13K(13kに従って)、EVRC、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 MPEG-4仕様で許容されたものは何でも含むことができるmpeg4ビデオ/ジェネリックかどんなコーデックもMP4登録局[MP4-レッジ]とともに記名しました。 o ビデオ/quicktime(quicktimeはクイックタイムコーデックコンポーネントがある何でも含むことができます)。 クイックタイムが広げることができるので、これはあるか、またはアップル・コンピューターによって出荷されたコーデックに制限されません。

   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.

受信エージェントが、特定のコーデックがメディア内容を表すのが必要であると決心していることを許可するソリューションは、特にMultimedia Messaging(MMS)、および援助のための効率的でスケーラブルなサーバにワイヤレス・ネットワークでのマルチメディアサービスの成長を供給するのを助けるでしょう。

Gellens, et al.             Standards Track                     [Page 3]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[3ページ]。

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   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].

“MUST"、「必須NOT」がキーワードが、「必要でした」、“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で説明されるように本書では解釈されることになっているべきです。

   The syntax in this document uses the BNF rules specified in
   [MIME-Format] and [MIME-Coding].

構文は本書では[MIME形式]と[MIMEコード化]で指定されたBNF規則を使用します。

3.  The Codecs Parameter

3. コーデックパラメタ

   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.

各値は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形式]単位で必要とすることに注意してください。

        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をコード化しています]のフォーム、パーセントであるときにはそれに注意してください。

Gellens, et al.             Standards Track                     [Page 4]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[4ページ]。

        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.

Codecsパラメタが使用されているとき、それは身体の部分の現在の内容によって示されたすべてのコーデックを含まなければなりません。 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-ファミリーにすべての道で使用したすべての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.

受信機がCodecsパラメタがどんなメディア要素によっても示されないコーデックを含む身体の部分に遭遇するなら、受信機SHOULDは、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.

受信機がCodecsパラメタがメディア要素によって示されたすべてのコーデックを含まない身体の部分に遭遇するなら、受信機は、Codecsパラメタの情報を捨てることによって、身体の部分を処理するかもしれません。

3.1.  Generic Syntax

3.1. ジェネリック構文

   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).

Codecsパラメタは2つのフォームのどちらかを取ります。値がコード化するのを必要とするどんな八重奏も含まないとき、最初のフォームは使用されています。 2番目のフォームは、任意の八重奏がコード化されるのを許容するのに[MIMEコード化]を使用します。 どちらのフォームでも、引用文は<tspecials>でコンマと他のキャラクタを考慮します(必要でないと、引用文は使用されるかもしれません)。

Gellens, et al.             Standards Track                     [Page 5]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[5ページ]。

   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

unencodedv:=イド純真な/短絡的な人

   simp-list   := DQUOTE id-simple *( "," id-simple ) DQUOTE

短絡的な人の:=のDQUOTEのイド簡単な*、(「」、イド簡単である、)、DQUOTE

   id-simple   := element
               ; "." reserved as hierarchy delimiter

イド簡単な:=要素。 「」、階層構造デリミタとして、予約されます。

   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キャラクタ>も。 [MIME形式]で定義された<TOKEN>。 ; 「Codecsパラメタ価値」. 」 予約されています。 階層構造デリミタとして

   cod-fancy   := "codecs*" ":=" encodedv

「タラ空想:=「コーデック*」」: 」 =encodedv

   encodedv    := fancy-sing / fancy-list

-歌うように思っているencodedv:=/高級リスト

   fancy-sing  := [charset] "'" [language] "'" id-encoded
               ; Parsers MAY ignore <language>
               ; Parsers MAY support only US-ASCII and UTF-8

:=[charset]を空想して歌ってください、「'、「[言語]、「'「イドでコード化」にされる' パーサは<言語>を無視するかもしれません。 パーサは米国-ASCIIとUTF-8だけをサポートするかもしれません。

   fancy-list  := DQUOTE [charset] "'" [language] "'" id-list DQUOTE
               ; Parsers MAY ignore <language>
               ; Parsers MAY support only US-ASCII and UTF-8

高級リスト:=DQUOTE[charset]、「'、「[言語] 「'「イドリストDQUOTE」' パーサは<言語>を無視するかもしれません。 パーサは米国-ASCIIとUTF-8だけをサポートするかもしれません。

   id-list     := id-encoded *( "," id-encoded )

イドリスト:=は*をイドでコード化しました。(「」、イドでコード化される、)

   id-encoded  := encoded-elm *( "." encoded-elm )
               ; "." reserved as hierarchy delimiter

イドでコード化された:=コード化されたニレ*、(「. 」 コード化されたニレ、)、。 「」、階層構造デリミタとして、予約されます。

   encoded-elm := 1*octet-fancy

コード化されたニレ:=1*八重奏空想

   octet-fancy := ext-octet / attribute-char
               ; <ext-octet> and <attribute-char> defined in
               ; [MIME-Coding]

属性八重奏空想:=ext-八重奏/炭。 中で定義された<のext八重奏の>と<属性炭の>。 [MIMEコード化]

   DQUOTE      := %x22 ; " (double quote)

DQUOTE:=%x22。 " (二重引用文)

Gellens, et al.             Standards Track                     [Page 6]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[6ページ]。

   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基地のメディアFile Formatファミリーで値を定義するだけです。 また、他のファイル形式はコーデック命名を定義するかもしれません。

3.2.  ISO File Format Name Space

3.2. 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基地のメディアFile Formatに関しては、Codecsパラメタ価値の最初の要素は登録されるとしてMP4 Registration Authority[MP4-レッジ]によるサンプルの記述のエントリーの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 File Formatが道のサンプルエントリーの数を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番目の要素はMP4 Registration Authority ObjectTypeIndication(OTI)の16進表現です、[MP4-レッジ]と[MP41]で指定されるように(修正を含んでいて)。 [MP4-レッジ]がこれらの値があるここで省略されて、したがって、含意される主な"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番目の要素は10進数として言い表された[MP4A](修正を含んでいる)で定義されるようにオーディオの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番目の要素は10進数として言い表された[MP4V](修正を含んでいる)で定義されるようにビデオProfileLevelIndicationを特定します。

   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-4Visual Simple Profile Level0には値9があるので、MPEG-4Visual Simple Profile Level0のための完全なストリングは"mp4v.20.9""でしょう。

Gellens, et al.             Standards Track                     [Page 7]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[7ページ]。

3.3.  ISO Syntax

3.3. ISO構文

   id-simple   :=/ id-iso

イド簡単なイド:=/iso

   id-encoded  :=/ id-iso

イドでコード化されたイド:=/iso

   id-iso      := iso-gen / iso-mpega / iso-mpegv

イド-iso:=は/iso-mpega/iso-mpegvにiso情報を得ます。

   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

:=cpid*(コード化された要素/ニレ)にiso情報を得てください。 <要素>は<と共にコーデック簡単な>を使用しました。 <のコード化されたニレ>は<と共にコーデック高級な>を使用しました。 ; 「BNFが可能にすることに注意してください、」 . 」 <要素>の中で。 「<のコード化されたニレ>、しかし」、」、予約されている、。 階層構造デリミタ

   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(/「B」/DIGIT/「C」/「D」/「E」/「F」)。 省略された主な"0x"

   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

4.  Use in Additional Media Types

4. 追加メディアで、タイプを使用してください。

   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ファイル形式のために、新しいドキュメントは、追加詳細を指定することによって、これをアップデートするかもしれません。

Gellens, et al.             Standards Track                     [Page 8]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[8ページ]。

   For non-ISO formats, a new document MAY update this one by specifying
   the name space for the media type(s).

非ISO形式のために、新しいドキュメントは、メディアタイプにスペースという名前を指定することによって、これをアップデートするかもしれません。

5.  Examples

5. 例

   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ビデオ)コンテントタイプと等しいです: オーディオ/3gpp。 コーデックはsamr(AMRオーディオ)コンテントタイプと等しいです: ビデオ/3gpp。 コーデックは「s263、samr」(H.263ビデオプラスAMRオーディオ)コンテントタイプと等しいです: オーディオ/3gpp2。 コーデックはmp4a.の1E(13kオーディオ)のコンテントタイプと等しいです: ビデオ/3gpp2。 コーデックは「mp4v.20.9、mp4a. E1"」と等しいです。(MPEG-4Visual Simple Profile Level0足す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).

以下に注意してください。 OTIは「関連Amendment(s)とCorrigendum(a)を含んでいます」値20([MP4-レッジ]の「0×20」)が、言う。 「実際のオブジェクト・タイプは、[MP4V]で定義されて、[MP4V]の指定されるとしてのDecoderSpecificInfoで伝えられます、Annex K.。」(参照は適応しました)

6.  Additional Media Feature Details

6. 追加メディアは詳細を特徴とします。

   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.

そのような付加的な機能が含まれているとき、[満足している特徴]のヘッダーはそうする便利な方法を提供します。

7.  IANA Considerations

7. IANA問題

   The IANA has added "codecs" as an optional parameter to the media
   types listed in Section 3, with a reference to this document.

メディアタイプへの任意のパラメタがセクション3にリストアップされたようにIANAは「コーデック」を加えました、このドキュメントの参照で。

8.  Security Considerations

8. セキュリティ問題

   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パラメタ自体はそれが使用されているメディアタイプのどれかのセキュリティ問題を変更しません。 各オーディオとビデオメディアタイプには、それ自身の適用し続けているセキュリティ問題のセットがあります、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

不正確なCodecsパラメタで、それをレンダリングしないことができないかもしれないか、それはできるデバイスにメディア内容を送らないかもしれないデバイスでメディア内容を受け取るかもしれません。

Gellens, et al.             Standards Track                     [Page 9]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[9ページ]。

   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パラメタは何人かのタイプのサービス不能攻撃ができます。 しかしながら、これは偶然に最も起こりそうです、トランジットにおけるメディアデータを変更できる攻撃者がまさしくcontent typeヘッダーのCodecsパラメタよりむしろメディア形式自体、またはcontent typeヘッダーさえ変更することによって、より多くの害を引き起こす場合があったとき。

9.  Acknowledgements

9. 承認

   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を見直して、改良しました。

10.  Normative References

10. 引用規格

   [Content-Features] Klyne, G., "Indicating Media Features for MIME
                      Content", RFC 2912, September 2000.

「MIME内容のためのメディア機能を示す」という[満足している特徴]Klyne、G.、RFC2912、2000年9月。

   [KEYWORDS]         Bradner, S., "Key words for use in RFCs to
                      Indicate Requirement Levels", BCP 14, RFC 2119,
                      March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.ムーア、「パラメタ値とコード化されたWord拡大をまねてください」 「文字コード、言語、および続刊」、RFC2231、11月1997日

   [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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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.ハーディー、「メディアはタグ登録手順を特徴とする」BCP31、RFC2506、1999年3月。

   [MP4-Reg]          MP4REG, The MPEG-4 Registration Authority, URL:
                      <http://www.mp4ra.org>.

[MP4-レッジ]MP4REG、MPEG-4登録局、URL: <http://www.mp4ra.org>。

11.  Informative References

11. 有益な参照

   [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はスピーチデータのための形式とメディアタイプをファイルする」RFC3625、2003年9月。

Gellens, et al.             Standards Track                    [Page 10]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[10ページ]。

   [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-形式]t26.244、第三世代パートナーシッププロジェクト(3GPP)、「終わりから終わりに対するパケットわかりやすい切り換えられたストリーミングのサービス」。 「3GPPファイル形式(3GP)」、URL: <html http://www.3gpp.org/ftp/仕様/インフォメーション/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/公共の_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/IEC14496-1:2004、「情報技術(視聴覚のオブジェクトのコード化)第1部:」 「システム。」

   [MP4A]             ISO/IEC 14496-3:2001, "Information technology--
                      Coding of audio-visual objects--Part 3:  Audio".

[MP4A]ISO/IEC14496-3: 2001 「情報技術(視聴覚のオブジェクトのコード化)は3を分けます」。 「オーディオ。」

   [MP4V]             ISO/IEC 14496-2:2004, "Information technology--
                      Coding of audio-visual objects--Part 2:  Visual".

[MP4V]ISO/IEC14496-2:2004、「情報技術(視聴覚のオブジェクトのコード化)第2部:」 「視覚です」。

Authors' Addresses

作者のアドレス

   Randall Gellens
   QUALCOMM Incorporated
   5775 Morehouse Drive
   San Diego, CA  92121
   USA

ランドル・Gellensのクアルコムの法人組織の5775モアハウス・Driveカリフォルニア92121サンディエゴ(米国)

   EMail: randy@qualcomm.com

メール: randy@qualcomm.com

   David Singer
   Apple Computer, Inc.
   One Infinite Loop, MS:302-3MT
   Cupertino  CA 95014
   USA

デヴィッド歌手アップル・コンピューターInc.1無限ループ、MS: 302-3 MTカルパチーノカリフォルニア95014米国

   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エリクソン単位でマルチメディアTechnologies SE-164 80ストックホルム(スウェーデン)について研究してください。

   EMail: Per.Frojdh@ericsson.com
   Phone: +46 8 7190000

メール: Per.Frojdh@ericsson.com 電話: +46 8 7190000

Gellens, et al.             Standards Track                    [Page 11]

RFC 4281                  The Codecs Parameter             November 2005

Gellens、他 規格はコーデックパラメタ2005年11月にRFC4281を追跡します[11ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Gellens, et al.             Standards Track                    [Page 12]

Gellens、他 標準化過程[12ページ]