[要約] RFC 5285は、RTPヘッダー拡張の一般的なメカニズムを提供するための仕様です。その目的は、RTPパケットに追加の情報を含めるための柔軟性と拡張性を提供することです。
Network Working Group D. Singer
Request for Comments: 5285 Apple, Inc.
Category: Standards Track H. Desineni
Qualcomm
July 2008
A General Mechanism for RTP Header Extensions
RTPヘッダー拡張機能の一般的なメカニズム
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session.
このドキュメントは、RTP（リアルタイムトランスポートプロトコル）のヘッダー拡張機能を使用する一般的なメカニズムを提供します。各RTPパケットで少数の小さな拡張機能を使用するオプションが提供されます。ここでは、可能な拡張機能のユニバースが大きく、登録が分離されています。セッションで使用されている実際の拡張機能は、そのセッションのセットアップ情報で知られています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 5
4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 6
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . . 7
6. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Identifier Space for IANA to Manage . . . . . . . . . . . 13
9.2. Registration of the SDP extmap Attribute . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
The RTP specification [RFC3550] provides a capability to extend the RTP header. It defines the header extension format and rules for its use in Section 5.3.1. The existing header extension method permits at most one extension per RTP packet, identified by a 16-bit identifier and a 16-bit length field specifying the length of the header extension in 32-bit words.
RTP仕様[RFC3550]は、RTPヘッダーを拡張する機能を提供します。セクション5.3.1で使用するヘッダー拡張形式とルールを定義します。既存のヘッダー拡張法は、32ビット単語でヘッダー拡張の長さを指定する16ビット識別子と16ビットの長さフィールドによって識別されるRTPパケットごとに最大1つの拡張機能を許可します。
This mechanism has two conspicuous drawbacks. First, it permits only one header extension in a single RTP packet. Second, the specification gives no guidance as to how the 16-bit header extension identifiers are allocated to avoid collisions.
このメカニズムには、2つの顕著な欠点があります。まず、単一のRTPパケットでヘッダー拡張機能を1つだけ許可します。第二に、仕様は、衝突を回避するために16ビットヘッダー拡張識別子がどのように割り当てられるかについてのガイダンスを提供しません。
This specification removes the first drawback by defining a backward-compatible and extensible means to carry multiple header extension elements in a single RTP packet. It removes the second drawback by defining that these extension elements are named by URIs, defining an IANA registry for extension elements defined in IETF specifications, and a Session Description Protocol (SDP) method for mapping between the naming URIs and the identifier values carried in the RTP packets.
この仕様は、単一のRTPパケットに複数のヘッダー拡張要素を運ぶために、後方互換と拡張可能な手段を定義することにより、最初の欠点を削除します。これらの拡張要素がURISによって名前が付けられ、IETF仕様で定義された拡張要素のIANAレジストリを定義することと、セッション説明プロトコル（SDP）メソッドを定義することにより、2番目の欠点を削除します。RTPパケット。
This header extension applies to RTP/AVP (the Audio/Visual Profile) and its extensions.
このヘッダー拡張機能は、RTP/AVP（オーディオ/ビジュアルプロファイル）とその拡張機能に適用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The goal of this design is to provide a simple mechanism whereby multiple identified extensions can be used in RTP packets, without the need for formal registration of those extensions but nonetheless avoiding collision.
この設計の目標は、これらの拡張機能の正式な登録を必要とせずに、RTPパケットで複数の識別された拡張機能を使用できる簡単なメカニズムを提供することです。
This mechanism provides an alternative to the practice of burying associated metadata into the media format bit stream. This has often been done in media data sent over fixed-bandwidth channels. Once this is done, a decoder for the specific media format is required to extract the metadata. Also, depending on the media format, the metadata may need to be added at the time of encoding the media so that the bit-rate required for the metadata is taken into account. But the metadata may not be known at that time. Inserting metadata at a later time can require a decode and re-encode to meet bit-rate requirements.
このメカニズムは、関連するメタデータをメディア形式のビットストリームに埋める実践に代わるものを提供します。これは、固定帯域幅チャネルを介して送信されたメディアデータでしばしば行われています。これが完了したら、メタデータを抽出するために特定のメディア形式のデコーダーが必要です。また、メディア形式に応じて、メタデータがメタデータに必要なビットレートが考慮されるようにメディアをエンコードする時点でメタデータを追加する必要がある場合があります。しかし、その時点ではメタデータは知られていないかもしれません。後でメタデータを挿入するには、ビットレートの要件を満たすためにデコードと再エンコードが必要になる場合があります。
In some cases, a more appropriate, higher-level mechanism may be available, and if so, it should be used. For cases where a higher-level mechanism is not available, it is better to provide a mechanism at the RTP level than have the metadata be tied to a specific form of media data.
場合によっては、より適切な高レベルのメカニズムが利用可能になる場合があり、もしそうなら、それを使用する必要があります。高レベルのメカニズムが利用できない場合は、メタデータを特定の形式のメディアデータに結び付けるよりも、RTPレベルでメカニズムを提供する方が良いです。
The following design is fit into the "header extension" of the RTP extension, as described above.
上記のように、次の設計はRTP拡張の「ヘッダー拡張」に適合します。
The presence and format of this header extension and its contents are negotiated or defined out-of-band, such as through signaling (see below for SDP signaling). The value defined for an RTP extension (defined below for the one-byte and two-byte header forms) is only an architectural constant (e.g., for use by network analyzers); it is the negotiation/definition (e.g., in SDP) that is the definitive indication that this header extension is present.
このヘッダー拡張機能とその内容の存在と形式は、シグナリングを介して交渉または定義されています（SDPシグナリングについては以下を参照）。RTP拡張機能（1バイトおよび2バイトのヘッダー形式で以下で定義されている）で定義された値は、アーキテクチャの定数のみです（たとえば、ネットワークアナライザーで使用する場合）。このヘッダー拡張が存在するという決定的な兆候であるのは、交渉/定義（SDPなど）です。
This specification inherits the requirement from the RTP specification that the header extension "is designed so that the header extension may be ignored". To be specific, header extensions using this specification MUST only be used for data that can safely be ignored by the recipient without affecting interoperability, and MUST NOT be used when the presence of the extension has changed the form or nature of the rest of the packet in a way that is not compatible with the way the stream is signaled (e.g., as defined by the payload type). Valid examples might include metadata that is additional to the usual RTP information.
この仕様は、ヘッダー拡張機能が「ヘッダー拡張機能が無視されるように設計されている」というRTP仕様から要件を継承します。具体的には、この仕様を使用したヘッダー拡張機能は、相互運用性に影響を与えることなく受信者が安全に無視できるデータにのみ使用する必要があり、拡張機能の存在がパケットの残りの部分の形または性質を変更した場合は使用しないでください。ストリームの通知方法と互換性がない方法（例えば、ペイロードタイプで定義されている）。有効な例には、通常のRTP情報に追加のメタデータが含まれる場合があります。
The RTP header extension is formed as a sequence of extension elements, with possible padding. Each extension element has a local identifier and a length. The local identifiers may be mapped to a larger namespace in the negotiation (e.g., session signaling).
RTPヘッダー拡張は、可能なパディングを備えた拡張要素のシーケンスとして形成されます。各拡張要素には、ローカル識別子と長さがあります。ローカル識別子は、ネゴシエーションのより大きな名前空間にマッピングされる場合があります（セッション信号など）。
As is good network practice, data should only be transmitted when needed. The RTP header extension should only be present in a packet if that packet also contains one or more extension elements, as defined here. An extension element should only be present in a packet when needed; the signaling setup of extension elements indicates only that those elements may be present in some packets, not that they are in fact present in all (or indeed, any) packets.
良いネットワークの練習と同様に、データは必要なときにのみ送信する必要があります。ここで定義されているように、そのパケットにも1つ以上の拡張要素が含まれている場合、RTPヘッダー拡張機能はパケットにのみ存在する必要があります。拡張要素は、必要に応じてパケットにのみ存在する必要があります。拡張要素の信号セットアップは、これらの要素が一部のパケットに存在する可能性があることのみを示しています。
Each extension element in a packet has a local identifier (ID) and a length. The local identifiers present in the stream MUST have been negotiated or defined out-of-band. There are no static allocations of local identifiers. Each distinct extension MUST have a unique ID. The value 0 is reserved for padding and MUST NOT be used as a local identifier.
パケット内の各拡張要素には、ローカル識別子（ID）と長さがあります。ストリームに存在するローカル識別子は、交渉または帯域外で定義されている必要があります。ローカル識別子の静的割り当てはありません。それぞれの異なる拡張子には一意のIDが必要です。値0はパディング用に予約されており、ローカル識別子として使用してはなりません。
There are two variants of the extension: one-byte and two-byte headers. Since it is expected that (a) the number of extensions in any given RTP session is small and (b) the extensions themselves are small, the one-byte header form is preferred and MUST be supported by all receivers. A stream MUST contain only one-byte or two-byte headers: they MUST NOT be mixed within a stream. Transmitters SHOULD NOT use the two-byte form when all extensions are small enough for the one-byte header form.
拡張機能には、1バイトと2バイトのヘッダーの2つのバリエーションがあります。（a）特定のRTPセッションの拡張機能の数は小さく、（b）拡張自体が小さいことが予想されるため、1バイトのヘッダーフォームが優先され、すべてのレシーバーがサポートする必要があります。ストリームには、1バイトまたは2バイトのヘッダーのみを含める必要があります。ストリーム内で混合してはなりません。送信機は、すべての拡張機能が1バイトヘッダーフォームに十分小さい場合は、2バイトフォームを使用しないでください。
A sequence of extension elements, possibly with padding, forms the header extension defined in the RTP specification. There are as many extension elements as fit into the length as indicated in the RTP header extension length. Since this length is signaled in full 32- bit words, padding bytes are used to pad to a 32-bit boundary. The entire extension is parsed byte-by-byte to find each extension element (no alignment is required), and parsing stops at the earlier of the end of the entire header extension, or, in one-byte headers, on encountering an identifier with the reserved value of 15.
おそらくパディングを備えた拡張要素のシーケンスは、RTP仕様で定義されたヘッダー拡張機能を形成します。RTPヘッダー拡張長に示されているように、長さに適合すると同じ数の拡張要素があります。この長さは完全な32ビットの単語で通知されるため、パディングバイトは32ビットの境界までパッドを使用して使用されます。拡張機能全体がバイトごとに解析され、各拡張子要素を見つける（アライメントは不要）、ヘッダー拡張機能全体の端の早い時期に、または1バイトのヘッダーで、識別子に遭遇すると解析停止が停止します。予約額15。
In both forms, padding bytes have the value of 0 (zero). They may be placed between extension elements, if desired for alignment, or after the last extension element, if needed for padding. A padding byte does not supply the ID of an element, nor the length field. When a padding byte is found, it is ignored and the parser moves on to interpreting the next byte.
どちらの形式でも、パディングバイトの値は0（ゼロ）です。これらは、拡張要素の間に、アライメントのために必要な場合、またはパディングに必要な場合は最後の拡張要素の後に配置することができます。パディングバイトは、要素のIDも長さフィールドも供給しません。パディングバイトが見つかると、それは無視され、パーサーは次のバイトの解釈に移動します。
Note carefully that the one-byte header form allows for data lengths between 1 and 16 bytes, by adding 1 to the signaled length value (thus, 0 in the length field indicates 1 byte of data follows). This allows for the important case of 16-byte payloads. This addition is not performed for the two-byte headers, where the length field signals data lengths between 0 and 255 bytes.
1バイトヘッダーフォームは、信号の長さ値に1を追加することにより、1〜16バイトのデータ長を可能にすることに注意してください（したがって、長さフィールドの0は、1バイトのデータが続くことを示します）。これにより、16バイトのペイロードの重要なケースが可能になります。この追加は、長さのフィールドがデータの長さを0〜255バイトに信号する2バイトヘッダーに対しては実行されません。
Use of RTP header extensions will reduce the efficiency of RTP header compression, since the header extension will be sent uncompressed unless the RTP header compression module is updated to recognize the extension header. If header extensions are present in some packets, but not in others, this can also reduce compression efficiency by requiring an update to the fixed header to be conveyed when header extensions start or stop being sent. The interactions of the RTP header extension and header compression is explored further in [RFC2508] and [RFC3095].
RTPヘッダー拡張機能の使用は、RTPヘッダー圧縮モジュールが更新されて拡張ヘッダーを認識しない限り、ヘッダー拡張機能が非圧縮されないため、RTPヘッダー圧縮の効率を低下させます。一部のパケットにはヘッダー拡張機能が存在するが、他のパケットには存在しない場合、ヘッダー拡張機能の開始または送信を停止するときに、固定ヘッダーの更新を必要とすることにより、圧縮効率を低下させることができます。RTPヘッダーエクステンションとヘッダー圧縮の相互作用は、[RFC2508]および[RFC3095]でさらに調査されています。
In the one-byte header form of extensions, the 16-bit value required by the RTP specification for a header extension, labeled in the RTP specification as "defined by profile", takes the fixed bit pattern 0xBEDE (the first version of this specification was written on the feast day of the Venerable Bede).
拡張機能の1バイトヘッダー形式では、RTP仕様に「プロファイルで定義されている」とラベル付けされたヘッダー拡張機能のRTP仕様で必要な16ビット値は、固定ビットパターン0xBede（この仕様の最初のバージョンを取得します。由緒あるベッドのeast宴の日に書かれました）。
Each extension element starts with a byte containing an ID and a length:
各拡張要素は、IDと長さを含むバイトから始まります。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| ID | len |
+-+-+-+-+-+-+-+-+
The 4-bit ID is the local identifier of this element in the range 1-14 inclusive. In the signaling section, this is referred to as the valid range.
4ビットIDは、範囲1〜14を含むこの要素のローカル識別子です。信号セクションでは、これは有効な範囲と呼ばれます。
The local identifier value 15 is reserved for future extension and MUST NOT be used as an identifier. If the ID value 15 is encountered, its length field should be ignored, processing of the entire extension should terminate at that point, and only the extension elements present prior to the element with ID 15 considered.
ローカル識別子値15は、将来の拡張のために予約されており、識別子として使用してはなりません。ID値15が発生した場合、その長さフィールドは無視する必要があり、拡張機能全体の処理はその時点で終了し、ID 15が考慮される要素の前に存在する拡張要素のみが終了するはずです。
The 4-bit length is the number minus one of data bytes of this header extension element following the one-byte header. Therefore, the value zero in this field indicates that one byte of data follows, and a value of 15 (the maximum) indicates element data of 16 bytes. (This permits carriage of 16-byte values, which is a common length of labels and identifiers, while losing the possibility of zero-length values -- which would often be padded anyway.) An example header extension, with three extension elements, some padding, and including the required RTP fields, follows:
4ビットの長さは、1バイトヘッダーに続くこのヘッダー拡張要素のデータバイトの1つを差し引いた数字です。したがって、このフィールドの値ゼロは、1バイトのデータが続くことを示し、15（最大）の値は16バイトの要素データを示します。（これにより、16バイトの値のキャリッジが可能になります。これは、一般的な長さのラベルと識別子であり、ゼロの長さの値の可能性を失います。パディング、および必要なRTPフィールドを含むと、次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | data | ID | L=1 | data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...data | 0 (pad) | 0 (pad) | ID | L=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the two-byte header form, the 16-bit value required by the RTP specification for a header extension, labeled in the RTP specification as "defined by profile", is defined as shown below.
2バイトヘッダーフォームでは、RTP仕様に「プロファイルで定義された」とラベル付けされたヘッダー拡張機能のRTP仕様で必要な16ビット値は、以下に示すように定義されています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x100 |appbits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The appbits field is 4 bits that are application-dependent and may be defined to be any value or meaning, and are outside the scope of this specification. For the purposes of signaling, this field is treated as a special extension value assigned to the local identifier 256. If no extension has been specified through configuration or signaling for this local identifier value 256, the appbits field SHOULD be set to all 0s by the sender and MUST be ignored by the receiver.
Appbitsフィールドは、アプリケーションに依存する4ビットであり、任意の価値または意味であると定義される場合があり、この仕様の範囲外です。シグナリングの目的で、このフィールドは、ローカル識別子256に割り当てられた特別な拡張値として扱われます。送信者と受信機によって無視されなければなりません。
Each extension element starts with a byte containing an ID and a byte containing a length:
各拡張要素は、IDを含むバイトと長さを含むバイトから始まります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 8-bit ID is the local identifier of this element in the range 1-255 inclusive. In the signaling section, the range 1-256 is referred to as the valid range, with the values 1-255 referring to extension elements, and the value 256 referring to the 4-bit field 'appbits' (above).
8ビットIDは、範囲1〜255を含むこの要素のローカル識別子です。信号セクションでは、範囲1〜256は有効な範囲と呼ばれ、値1-255は拡張要素を参照し、値256は4ビットフィールド「アプリット」（上記）を参照しています。
The 8-bit length field is the length of extension data in bytes not including the ID and length fields. The value zero indicates there is no data following.
8ビットの長さフィールドは、IDおよび長さフィールドを含まないバイトの拡張データの長さです。値ゼロは、フォローしたデータがないことを示します。
An example header extension, with three extension elements, some padding, and including the required RTP fields, follows:
3つの拡張要素、いくつかのパディング、および必要なRTPフィールドを含む3つの拡張要素を備えたヘッダー拡張の例が続きます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | 0x00 | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=0 | ID | L=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | 0 (pad) | ID | L=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The indication of the presence of this extension, and the mapping of local identifiers used in the header extension to a larger namespace, MUST be performed out-of-band, for example, as part of a SIP offer/ answer exchange using SDP. This section defines such signaling in SDP.
この拡張機能の存在の兆候と、ヘッダー拡張機能でより大きな名前空間に使用されるローカル識別子のマッピングは、たとえば、SDPを使用したSIPオファー/回答交換の一部として、帯域外で実行する必要があります。このセクションでは、SDPのこのようなシグナル伝達を定義します。
A usable mapping MUST use IDs in the valid range, and each ID in this range MUST be used only once for each media (or only once if the mappings are session level). Mappings that do not conform to these rules MAY be presented, for instance, during offer/answer negotiation as described in the next section, but remapping to conformant values is necessary before they can be applied.
使用可能なマッピングは有効な範囲でIDを使用する必要があり、この範囲の各IDは各メディアに対して1回だけ使用する必要があります（またはマッピングがセッションレベルである場合は1回だけ）。これらのルールに準拠していないマッピングは、たとえば、次のセクションで説明されているオファー/回答の交渉中に提示される場合がありますが、適用する前にコンフォーマント値への再マッピングが必要です。
Each extension is named by a URI. That URI MUST be absolute, and precisely identifies the format and meaning of the extension. URIs that contain a domain name SHOULD also contain a month-date in the form mmyyyy. The definition of the element and assignment of the URI MUST have been authorized by the owner of the domain name on or very close to that date. (This avoids problems when domain names change ownership.) If the resource or document defines several extensions, then the URI MUST identify the actual extension in use, e.g., using a fragment or query identifier (characters after a '#' or '?' in the URI).
各拡張機能はURIによって名前が付けられています。そのURIは絶対的でなければならず、拡張機能の形式と意味を正確に識別します。ドメイン名を含むurisは、mmyyyyの形式の月の日付も含める必要があります。URIの要素と割り当ての定義は、その日付または非常に近いドメイン名の所有者によって承認されている必要があります。（これにより、ドメイン名が所有権を変更すると問題が回避されます。）リソースまたはドキュメントがいくつかの拡張機能を定義する場合、URIは使用中の実際の拡張機能を特定する必要があります。たとえば、フラグメントまたはクエリ識別子（「＃」または「？」URI）。
Rationale: the use of URIs provides for a large, unallocated space,
理論的根拠：URISの使用は、大きな未割り当てのスペースを提供します、
and gives documentation on the extension. The URIs are not required to be de-referencable, in order to permit confidential or experimental use, and to cover the case when extensions continue to be used after the organization that defined them ceases to exist.
拡張機能に関するドキュメントを提供します。URIは、機密または実験的使用を許可し、それらを定義した組織が存在しなくなることを停止した後も拡張機能を使用し続ける場合に、リファレンスを解除できる必要はありません。
An extension URI with the same attributes MUST NOT appear more than once applying to the same stream, i.e., at session level or in the declarations for a single stream at media level. (The same extension may, of course, be used for several streams, and may appear differently parameterized for the same stream.)
同じ属性を持つ拡張URIは、同じストリーム、つまりセッションレベルで、またはメディアレベルでの単一のストリームの宣言で1回以上表示されてはなりません。（もちろん、同じ拡張機能はいくつかのストリームに使用される場合があり、同じストリームに対して異なるパラメーター化されているように見える場合があります。）
For extensions defined in RFCs, the URI used SHOULD be a URN starting "urn:ietf:params:rtp-hdrext:" and followed by a registered, descriptive name.
RFCSで定義されている拡張機能の場合、使用されるURIは「urn：ietf：params：rtp-hdrext：」を開始するurnでなければなりません。
The registration requirements are detailed in the IANA Considerations section, below.
登録要件は、以下のIANA考慮事項セクションで詳しく説明されています。
An example (this is only an example), where 'avt-example-metadata' is the hypothetical name of a header extension, might be:
例（これは単なる例です）。「AVT-Example-Metadata」はヘッダー拡張機能の仮説的な名前である可能性があります。
urn:ietf:params:rtp-hdrext:avt-example-metadata
An example name not from the IETF (this is only an example) might be:
IETF（これは単なる例です）からではない例：次の場合は次のとおりです。
http://example.com/082005/ext.htm#example-metadata
The mapping may be provided per media stream (in the media-level section(s) of SDP, i.e., after an "m=" line) or globally for all streams (i.e., before the first "m=" line, at session level). The definitions MUST be either all session level or all media level; it is not permitted to mix the two styles. In addition, as noted above, the IDs used MUST be unique for each stream type for a given media, or for the session for session-level declarations.
マッピングは、メディアストリームごと（SDPのメディアレベルのセクション、つまり「m = "行の後）またはすべてのストリームのグローバル（つまり、セッション時に最初の「m =」ラインの前のグローバルで提供される場合があります。レベル）。定義は、すべてのセッションレベルまたはすべてのメディアレベルのいずれかでなければなりません。2つのスタイルを混ぜることは許可されていません。さらに、上記のように、使用されるIDは、特定のメディアの各ストリームタイプ、またはセッションレベルの宣言のセッションに対して一意でなければなりません。
Each local identifier potentially used in the stream is mapped to a string using an attribute of the form:
ストリームで潜在的に使用される各ローカル識別子は、フォームの属性を使用して文字列にマッピングされます。
a=extmap:<value>["/"<direction>] <URI> <extensionattributes>
where <URI> is a URI, as above, <value> is the local identifier (ID) of this extension and is an integer in the valid range inclusive (0 is reserved for padding in both forms, and 15 is reserved in the one-byte header form, as noted above), and <direction> is one of "sendonly", "recvonly", "sendrecv", or "inactive" (without the quotes).
ここで、<uri>は上記のように、<uri>はこの拡張機能のローカル識別子（ID）であり、有効な範囲内の整数です（0は両方の形式のパディング用に予約されており、15は1つに予約されています - 上記のように、バイテヘッダーフォーム）、および<方向>は、「sendonly」、「recvonly」、「sendrecv」、または "inactive"（引用符なし）の1つです。
The formal BNF syntax is presented in a later section of this specification.
正式なBNF構文は、この仕様の後のセクションに示されています。
Example:
例：
a=extmap:1 http://example.com/082005/ext.htm#ttime
a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short
When SDP signaling is used for the RTP session, it is the presence of the 'extmap' attribute(s) that is diagnostic that this style of header extensions is used, not the magic number indicated above.
SDPシグナル伝達がRTPセッションに使用される場合、このスタイルのヘッダー拡張機能が使用されるのは診断であり、上記のマジック番号ではなく、「extmap」属性の存在です。
The simple signaling described above may be enhanced in an offer/ answer context, to permit:
上記の簡単なシグナル伝達は、許可するために、オファー/回答のコンテキストで強化される場合があります。
o asymmetric behavior (extensions sent in only one direction),
o 非対称の動作（1つの方向にのみ送信される拡張機能）、
o the offer of mutually exclusive alternatives, or
o 相互に排他的な代替品の提供、または
o the offer of more extensions than can be sent in a single session.
o 1回のセッションで送信できるよりも多くの拡張機能の提供。
A direction attribute MAY be included in an extmap; without it, the direction implicitly inherits, of course, from the stream direction, or is "sendrecv" for session-level attributes or extensions of "inactive" streams. The direction MUST be one of "sendonly", "recvonly", "sendrecv", or "inactive". A "sendonly" direction indicates an ability to send; a "recvonly" direction indicates a desire to receive; a "sendrecv" direction indicates both. An "inactive" direction indicates neither, but later re-negotiation may make an extension active.
ExtMapには方向属性が含まれる場合があります。それがなければ、方向はもちろん、ストリーム方向から暗黙的に継承するか、「非アクティブ」ストリームのセッションレベルの属性または拡張に対して「sendrecv」です。方向は、「sendonly」、「recvonly」、「sendrecv」、または "inactive」の1つでなければなりません。「sendonly」方向は、送信する能力を示します。「recvonly」方向は、受け取るという欲求を示します。「sendrecv」方向は両方を示します。「非アクティブな」方向はどちらも示しませんが、後の再交渉は拡張をアクティブにする可能性があります。
Extensions, with their directions, may be signaled for an "inactive" stream. It is an error to use an extension direction incompatible with the stream direction (e.g., a "sendonly" attribute for a "recvonly" stream).
方向を備えた拡張機能は、「非アクティブな」ストリームに合図される場合があります。ストリーム方向（たとえば、「recvonly」ストリームの「sendonly」属性など）と互換性のない拡張方向を使用することはエラーです。
If an offer or answer contains session-level mappings (and hence no media-level mappings), and different behavior is desired for each stream, then the entire set of extension map declarations may be moved into the media-level section(s) of the SDP. (Note that this specification does not permit mixing global and local declarations, to make identifier management easier.)
オファーまたは回答にセッションレベルのマッピングが含まれている場合（したがって、メディアレベルのマッピングはありません）、各ストリームに対して異なる動作が望ましい場合、拡張マップ宣言のセット全体をメディアレベルのセクションに移動できます。SDP。（この仕様では、識別子管理を容易にするために、グローバルとローカルの宣言を混合することを許可していないことに注意してください。）
If an extension map is offered as "sendrecv", explicitly or implicitly, and asymmetric behavior is desired, the SDP may be modified to modify or add direction qualifiers for that extension. If an extension is marked as "sendonly" and the answerer desires to receive it, the extension MUST be marked as "recvonly" in the SDP answer. An answerer that has no desire to receive the extension or does not understand the extension SHOULD remove it from the SDP answer.
拡張マップが「SendRecv」として明示的または暗黙的に提供され、非対称の動作が望ましい場合、SDPを変更してその拡張の方向修飾子を変更または追加することができます。拡張機能が「Sendonly」としてマークされ、Answererがそれを受け取ることを望んでいる場合、拡張機能はSDP回答で「Recvonly」としてマークされなければなりません。拡張機能を受け取りたくない、または拡張機能がSDPの回答からそれを削除することを理解していない回答者。
If an extension is marked as "recvonly" and the answerer desires to send it, the extension MUST be marked as "sendonly" in the SDP answer. An answerer that has no desire to, or is unable to, send the extension SHOULD remove it from the SDP answer.
拡張機能が「Recvonly」としてマークされ、Answererがそれを送信したい場合、拡張機能はSDP回答で「Sendonly」としてマークされなければなりません。拡張機能を削除することを望んでいない、または拡張機能を送信できない回答者。
Local identifiers in the valid range inclusive in an offer or answer must not be used more than once per media section (including the session-level section). A session update MAY change the direction qualifiers of extensions under use. A session update MAY add or remove extension(s). Identifiers values in the valid range MUST NOT be altered (remapped).
オファーまたは回答に含まれる有効な範囲のローカル識別子は、メディアセクション（セッションレベルセクションを含む）ごとに1回以上使用してはなりません。セッションの更新により、使用中の拡張機能の方向予選者が変更される場合があります。セッションの更新では、拡張機能を追加または削除する場合があります。有効な範囲の識別子値を変更する必要はありません（再マップ）。
Note that, under this rule, the same local identifier cannot be used for two extensions for the same media, even when one is "sendonly" and the other "recvonly", as it would then be impossible to make either of them sendrecv (since re-numbering is not permitted either).
この規則の下では、同じメディアの2つの拡張機能に同じローカル識別子を使用できないことに注意してください。1つは「Sendonly」であり、もう1つは「Recvonly」であっても、どちらかをSendRecvにすることは不可能です（再番号は許可されていません）。
If a party wishes to offer mutually exclusive alternatives, then multiple extensions with the same identifier in the (unusable) range 4096-4351 may be offered; the answerer should select at most one of the offered extensions with the same identifier, and remap it to a free identifier in the valid range, for that extension to be usable.
当事者が相互に排他的な代替案を提供したい場合、（使用不可）範囲の同じ識別子を持つ複数の拡張機能が提供される場合があります。Answererは、同じ識別子を使用して提供される拡張機能のせいぜい1つを選択し、その拡張機能を使用できるように、有効な範囲のフリー識別子に再度再検討する必要があります。
Similarly, if more extensions are offered than can be fit in the valid range, identifiers in the range 4096-4351 may be offered; the answerer should choose those that are desired, and remap them to a free identifier in the valid range.
同様に、有効な範囲に収まるよりも多くの拡張機能が提供される場合、範囲4096-4351の識別子が提供される場合があります。応答者は、必要なものを選択し、有効な範囲の無料識別子にそれらを再マップする必要があります。
It is always allowed to place the offered identifier value "as is" in the SDP answer (for example, due to lack of a free identifier value in the valid range). Extensions with an identifier outside the valid range cannot, of course, be used. If required, the offerer or answerer can update the session to make space for such an extension.
SDP回答に提供された識別子値「現状」を常に配置することが許可されています（たとえば、有効な範囲に自由な識別子値がないため）。もちろん、有効な範囲の外側に識別子が有効な範囲外の拡張機能を使用することはできません。必要に応じて、オファーまたは応答者はセッションを更新して、そのような拡張機能のためのスペースを作成できます。
Rationale: the range 4096-4351 for these negotiation identifiers is deliberately restricted to allow expansion of the range of valid identifiers in future.
理論的根拠：これらのネゴシエーション識別子の範囲4096-4351は、将来の有効な識別子の範囲の拡大を可能にするために意図的に制限されています。
Either party MAY include extensions in the stream other than those negotiated, or those negotiated as "inactive", for example, for the benefit of intermediate nodes. Only extensions that appeared with an identifier in the valid range in SDP originated by the sender can be sent.
どちらの当事者も、交渉されたもの以外のストリームに拡張機能を含めることができます。たとえば、中間ノードの利益のために、「非アクティブ」と交渉されたものが含まれます。送信者から発信されたSDPの有効な範囲の識別子で表示された拡張機能のみを送信できます。
Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. all omitted for brevity):
例（ポート番号、RTPプロファイル、ペイロードID、RTPMAPなど。すべてが簡潔に省略）：
The offer:
申し出：
a=extmap:1 URI-toffset
a=extmap:14 URI-obscure
a=extmap:4096 URI-gps-string
a=extmap:4096 URI-gps-binary
a=extmap:4097 URI-frametype
m=video
a=sendrecv
m=audio
a=sendrecv
The answerer is interested in receiving GPS in string format only on video, but cannot send GPS at all. It is not interested in transmission offsets on audio, and does not understand the URI-obscure extension. It therefore moves the extensions from session level to media level, and adjusts the declarations:
Answererは、ビデオでのみ文字列形式でGPSを受信することに関心がありますが、GPSをまったく送信することはできません。オーディオの送信オフセットには関心がなく、URI-Obscure拡張機能を理解していません。したがって、拡張機能をセッションレベルからメディアレベルに移動し、宣言を調整します。
m=video
a=sendrecv
a=extmap:1 URI-toffset
a=extmap:2/recvonly URI-gps-string
a=extmap:3 URI-frametype
m=audio
a=sendrecv
a=extmap:1/sendonly URI-toffset
The syntax definition below uses ABNF according to [RFC5234]. The syntax element 'URI' is defined in [RFC3986] (only absolute URIs are permitted here). The syntax element 'extmap' is an attribute as defined in [RFC4566], i.e., "a=" precedes the extmap definition. Specific extensionattributes are defined by the specification that defines a specific extension name; there may be several.
以下の構文定義は、[RFC5234]に従ってABNFを使用します。構文要素「URI」は[RFC3986]で定義されています（ここでは絶対URIのみが許可されています）。構文要素「extmap」は、[rfc4566]で定義されている属性、つまり "a ="はextmap定義に先行します。特定の拡張機能は、特定の拡張名を定義する仕様によって定義されます。いくつかあるかもしれません。
extmap = mapentry SP extensionname [SP extensionattributes]
extmap = mapentry sp extensionName [sp extensionAttributes]
extensionname = URI
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
mapentry = "extmap:" 1*5DIGIT ["/" direction]
extensionattributes = byte-string
URI = <Defined in RFC 3986>
byte-string = <Defined in RFC 4566>
SP = <Defined in RFC 5234>
DIGIT = <Defined in RFC 5234>
This defines only a place to transmit information; the security implications of the extensions must be discussed with those extensions.
これは、情報を送信する場所のみを定義します。拡張機能のセキュリティへの影響については、それらの拡張機能で議論する必要があります。
Care should be taken when defining extensions. Clearly, they should be solely informative, but even when the information is extracted, should not cause security concerns.
拡張機能を定義する際には注意が必要です。明らかに、それらは単に有益である必要がありますが、情報が抽出された場合でも、セキュリティの懸念を引き起こすべきではありません。
Header extensions have the same security coverage as the RTP header itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is used to protect RTP sessions, the RTP payload may be both encrypted and integrity protected, while the RTP header is either unprotected or integrity protected. Therefore, it is inappropriate to place information in header extensions that cause security problems if disclosed, unless the entire RTP packet is protected by a lower-layer security protocol providing both confidentiality and integrity capability.
ヘッダー拡張機能は、RTPヘッダー自体と同じセキュリティカバレッジを持っています。安全なリアルタイムトランスポートプロトコル（SRTP）[RFC3711]を使用してRTPセッションを保護する場合、RTPペイロードは暗号化され、整合性が保護されている場合がありますが、RTPヘッダーは保護されていないか、完全性保護されています。したがって、RTPパケット全体が機密性と整合性能力の両方を提供する低層セキュリティプロトコルによって保護されていない限り、開示された場合にセキュリティの問題を引き起こすヘッダー拡張機能に情報を配置することは不適切です。
The mapping from the naming URI form to a reference to a specification is managed by IANA. Insertion into this registry is under the requirements of "Expert Review" as defined in [RFC5226].
命名URIフォームから仕様への参照へのマッピングは、IANAによって管理されます。このレジストリへの挿入は、[RFC5226]で定義されている「専門家のレビュー」の要件の下にあります。
The IANA will also maintain a server that contains all of the registered elements in a publicly accessible space.
IANAは、公開されたスペースに登録されたすべての要素を含むサーバーも維持します。
Here is the formal declaration required by the IETF URN Sub-namespace specification [RFC3553].
これは、IETF URNサブネームズスペース仕様[RFC3553]で必要な正式な宣言です。
o Registry name: RTP Compact Header Extensions
o レジストリ名：RTPコンパクトヘッダー拡張機能
o Specification: RFC 5285 and RFCs updating RFC 5285.
o 仕様：RFC 5285およびRFCの更新RFC 5285。
o Information required:
o 必要な情報：
A. The desired extension naming URI
A. URIの命名目的の拡張機能
B. A formal reference to the publicly available specification
B.公開されている仕様への正式な参照
C. A short phrase describing the function of the extension
C.拡張機能の機能を説明する短いフレーズ
D. Contact information for the organization or person making the registration
D.登録を行う組織または人の連絡先情報
For extensions defined in RFCs, the URI is recommended to be of the form urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC number of the RFC documenting the extension.
RFCSで定義されている拡張機能の場合、URIはurn：ietf：params：rtp-hdrext：形式であることをお勧めします。正式な参照は、拡張機能を文書化するRFC番号です。
o Review process: Expert review is required. The expert review should check the following requirements:
o レビュープロセス：専門家のレビューが必要です。専門家のレビューでは、次の要件を確認する必要があります。
1. that the specification is publicly available;
1. 仕様が公開されていること。
2. that the extension complies with the requirements of RTP and this specification, for extensions (notably, that the stream is still decodable if the extension is ignored or not recognized);
2. 拡張機能は、拡張機能とこの仕様に準拠していること（特に、拡張機能が無視されているか認識されていない場合は、ストリームがまだ解読可能であること）。
3. that the extension specification is technically consistent (in itself and with RTP), complete, and comprehensible;
3. 拡張仕様が技術的に一貫していること（それ自体がRTPと）、完全で、理解可能であること。
4. that the extension does not duplicate functionality in existing IETF specifications (including RTP itself), or other extensions already registered;
4. 拡張機能は、既存のIETF仕様（RTP自体を含む）または既に登録されている他の拡張機能で機能を複製していないこと。
5. that the specification contains a security analysis regarding the content of the header extension;
5. 仕様には、ヘッダー拡張機能のコンテンツに関するセキュリティ分析が含まれていること。
6. that the extension is generally applicable, for example point-to-multipoint safe, and the specification correctly describes limitations if they exist; and
6. 拡張機能が一般的に適用可能であること、たとえばポイントツーマルチポイントセーフであり、仕様は存在する場合の制限を正しく説明しています。と
7. that the suggested naming URI form is appropriately chosen and unique.
7. 提案された命名URIフォームが適切に選択され、ユニークであること。
o Size and format of entries: a mapping from a naming URI string to a formal reference to a publicly available specification, with a descriptive phrase and contact information.
o エントリのサイズと形式：命名URI文字列からのマッピングは、説明的なフレーズと連絡先情報を備えた、公開されている仕様への正式な参照へのマッピングです。
o Initial assignments: none.
o 初期割り当て：なし。
This section contains the information required by [RFC4566] for an SDP attribute.
このセクションには、[RFC4566]がSDP属性に必要な情報が含まれています。
o contact name, email address, and telephone number:
o 連絡先名、メールアドレス、電話番号：
D. Singer singer@apple.com +1 408-974-3162
D.シンガーsinger@apple.com 1 408-974-3162
o attribute name (as it will appear in SDP): extmap
o 属性名（SDPに表示されるように）：extmap
o long-form attribute name in English: generic header extension map definition
o 英語のロングフォーム属性名：ジェネリックヘッダー拡張マップ定義
o type of attribute (session level, media level, or both): both
o 属性のタイプ（セッションレベル、メディアレベル、またはその両方）：両方
o whether the attribute value is subject to the charset attribute: not subject to the charset attribute
o 属性値がcharset属性の対象かどうか：charset属性の対象ではありません
o a one-paragraph explanation of the purpose of the attribute: This attribute defines the mapping from the extension numbers used in packet headers into extension names as documented in specifications and appropriately registered.
o 属性の目的の1つのパラグラフの説明：この属性は、パケットヘッダーで使用されている拡張機能番号からのマッピングを、仕様で文書化され、適切に登録されているように拡張名に定義します。
o a specification of appropriate attribute values for this attribute: see RFC 5285.
o この属性の適切な属性値の仕様：RFC 5285を参照してください。
Both Brian Link and John Lazzaro provided helpful comments on an initial draft of this document. Colin Perkins was helpful in reviewing and dealing with the details. The use of URNs for IETF-defined extensions was suggested by Jonathan Lennox, and Pete Cordell was instrumental in improving the padding wording. Dave Oran provided feedback and text in the review. Mike Dolan contributed the two-byte header form. Magnus Westerlund and Tom Taylor were instrumental in managing the registration text.
ブライアンリンクとジョンラザロは、この文書の最初のドラフトについて有益なコメントを提供しました。Colin Perkinsは、詳細のレビューと対処に役立ちました。IETF定義の拡張機能にurnsの使用は、Jonathan Lennoxによって提案され、Pete Cordellはパディングの言葉遣いの改善に尽力しました。デイブ・オランはレビューでフィードバックとテキストを提供しました。マイク・ドーランは2バイトのヘッダーフォームに貢献しました。マグナス・ウェスターランドとトム・テイラーは、登録テキストの管理に貢献しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S。およびV. Jacobson、「低速シリアルリンクのIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T。、およびG. Klyne、「登録プロトコルパラメーターのIETF URNサブネームスペース」、BCP 73、RFC 3553、2003年6月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
Authors' Addresses
著者のアドレス
David Singer Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 USA
David Singer Apple、Inc。1 Infinite Loop Cupertino、CA 95014 USA
Phone: +1 408 996 1010
EMail: singer@apple.com
URI: http://www.apple.com/quicktime
Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego, CA 92126 USA
Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego、CA 92126 USA
Phone: +1 858 845 8996
EMail: hd@qualcomm.com
URI: http://www.qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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://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への情報をお問い合わせください。