Network Working Group W. Marshall, Ed.
Request for Comments: 3313 AT&T
Category: Informational January 2003
Private Session Initiation Protocol (SIP) Extensions
for Media Authorization
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes the need for Quality of Service (QoS) and media authorization and defines a Session Initiation Protocol (SIP) extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains.
このドキュメントでは、サービスの品質（QoS）とメディアの認可の必要性を説明し、コールシグナリングとのQoSアドミッション制御を統合し、サービス拒否攻撃を回避するのを助けるために使用することができ、セッション開始プロトコル（SIP）の拡張を定義します。この拡張機能を使用するには、管理ドメイン内、またはQoSを承認するSIPプロキシ、およびQoSを提供する基盤となるネットワークのポリシー制御、両方がその行政に所属する以前に合意された政策と管理ドメインの連合の間でのみ適用されますドメインまたはドメインのフェデレーション。
Table of Contents
目次
1. Scope of Applicability......................................... 2
2. Conventions Used in this Document.............................. 3
3. Background and Motivation...................................... 3
4. Overview....................................................... 4
5. Changes to SIP to Support Media Authorization.................. 4
5.1 SIP Header Extension....................................... 5
5.2 SIP Procedures............................................. 5
5.2.1 User Agent Client (UAC)................................ 6
5.2.2 User Agent Server (UAS)................................ 6
5.2.3 Originating Proxy (OP)................................. 7
5.2.4 Destination Proxy (DP)................................. 7
6. Examples....................................................... 8
6.1 Requesting Bandwidth via RSVP Messaging.................... 8
6.1.1 User Agent Client Side................................. 8
6.1.2 User Agent Server Side................................. 10
7. Advantages of the Proposed Approach............................ 12
8. Security Considerations........................................ 13
9. IANA Considerations............................................ 13
10. Notice Regarding Intellectual Property Rights................. 13
11. Normative References.......................................... 14
12. Informative References........................................ 14
13. Contributors.................................................. 15
14. Acknowledgments............................................... 15
15. Editor's Address.............................................. 15
16. Full Copyright Statement...................................... 16
This document defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains. Furthermore, the mechanism is generally incompatible with end-to-end encryption of message bodies that describe media sessions.
この文書では、コールシグナリングでのQoSアドミッション制御を統合し、サービス拒否攻撃から保護を助けるために使用することができるSIPの拡張機能を定義します。この拡張機能を使用するには、管理ドメイン内、またはQoSを承認するSIPプロキシ、およびQoSを提供する基盤となるネットワークのポリシー制御、両方がその行政に所属する以前に合意された政策と管理ドメインの連合の間でのみ適用されますドメインまたはドメインのフェデレーション。また、機構は、メディアセッションを記述したメッセージボディのエンド・ツー・エンドの暗号化一般互換性がありません。
This is in contrast with general Internet principles, which separate data transport from applications. Thus, the solution described in this document is not applicable to the Internet at large. Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and can accept the limitations that result, to warrant informational publication of this mechanism. An example deployment would be a closed network, which emulates a traditional circuit switched telephone network. This document specifies a private header, facilitating use in these specialized configurations.
これは、アプリケーションからのデータ転送を分離し、一般的なインターネットの原則、とは対照的です。したがって、この文書で説明するソリューションは、大規模で、インターネットには適用されません。これらの制限にもかかわらず、上記の仮定を満たしており、このメカニズムの情報掲載を保証するために、結果としての限界を受け入れることができ便利な専門的な展開は十分にあります。例の展開は、従来の回線交換電話網エミュレート閉じたネットワーク、だろう。この文書では、これらの特殊な構成で使用を容易に、プライベートヘッダを指定します。
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 RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
Current IP telephony systems assume a perfect world in which there is either an unlimited amount of bandwidth, or network layer Quality of Service (QoS) is provided without any kind of policy control. However, the reality is that end-to-end bandwidth is not unlimited and uncontrolled access to QoS, in general, is unlikely. The primary reason for this is that QoS provides preferential treatment of one flow, at the expense of another. Consequently, it is important to have policy control over whether a given flow should have access to QoS. This will not only enable fairness in general, but can also prevent denial of service attacks.
現在のIPテレフォニーシステムがあるのいずれかである無制限の帯域幅の量、またはサービスのネットワーク層の品質（QoS）のポリシー制御のいずれかの種類なしで提供されている完璧な世界を想定しています。しかし、現実には、エンド・ツー・エンドの帯域幅がQoSへの無制限かつ制御されていないアクセスではないということです、一般的には、ほとんどありません。その主な理由は、QoSは、他を犠牲にして、一つのフローの優遇措置を提供することです。したがって、所定のフローがQoSへのアクセス権を持っている必要があるかどうかを超えるポリシー制御を有することが重要です。これは、一般的に公平性を可能にしますだけでなく、サービス拒否（DoS）攻撃を防ぐことができます。
In this document, we are concerned with providing QoS for media streams established via the Session Initiation Protocol (SIP) [3]. We assume an architecture that integrates call signaling with media authorization, as illustrated in the Figure below. The solid lines (A and B) show interfaces, whereas the dotted line (C) illustrates the QoS enabled media flow:
この文書では、我々は、セッション開始プロトコル（SIP）を介して確立されたメディアストリームのQoSを提供することに関係している[3]。私たちは、下の図に示すように、メディア認証とシグナリングのコールを統合アーキテクチャを前提としています。破線（C）は、QoSの有効メディアフローを示し、一方、実線（A及びB）を表示するインターフェース、：
+---------+
| Proxy |
+--------->| |
| +---------+
| ^
A)| B) |
| { }
| |
| v
v +------+
+------+ C) | Edge |
| UA |........|router|......
+------+ +------+
Figure 1 - Basic Architecture
図1 - 基本アーキテクチャ
In this architecture, we assume a SIP UA connected to a QoS enabled network with an edge router acting as a Policy Enforcement Point (PEP) [6]. We further assume that a SIP UA that wishes to obtain QoS initiates sessions through a proxy which can interface with the QoS policy control for the data network being used. We will refer to such a proxy as a QoS enabled proxy. We assume that the SIP UA needs to present an authorization token to the network in order to obtain Quality of Service (C). The SIP UA obtains this authorization token via SIP (A) from the QoS enabled proxy by means of an extension SIP header, defined in this document. The proxy, in turn, communicates either directly with the edge router or with a Policy Decision Point (PDP - not shown) [6] in order to obtain a suitable authorization token for the UA.
このアーキテクチャでは、我々は、[6]ポリシー実行ポイント（PEP）として機能するエッジルータとネットワークを有効にしたQoSに接続されたSIP UAをとります。我々はさらに、QoSがデータネットワークのためのQoSポリシー制御とインターフェースすることができ、プロキシを介してセッションを開始し得ることを望むSIP UAが使用されていると仮定する。私たちは、QoS対応プロキシなどのプロキシを参照します。私たちは、SIP UAは、サービス品質（C）を得るために、ネットワークへの認証トークンを提示する必要があることを前提としています。 SIP UAは、この文書で定義された拡張SIPヘッダを用いてプロキシを使用可能なQoS、からSIP（A）を介して、この認証トークンを取得します。プロキシは、今度は、直接エッジルータと又はポリシー決定ポイント（PDP - 図示せず）に連通する[6]ためにUAに適した認証トークンを取得します。
Examples of access data networks, where such a QoS enabled proxy could be used, include DOCSIS based cable networks and 3rd generation (3G) wireless networks.
プロキシを有効にこのようなQoSが使用できるアクセス・データ・ネットワークの例には、DOCSISベースのケーブル・ネットワーク及び第3世代（3G）無線ネットワークを含みます。
A session that needs to obtain QoS for the media streams in accordance with our basic architecture described above goes through the following steps.
上記の私たちの基本的なアーキテクチャに基づいてメディアストリームのためのQoSを取得する必要があるセッションは、次の手順を経ます。
The SIP UA sends an INVITE to the QoS enabled proxy, which for each resulting dialog includes one or more media authorization tokens in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response for the dialog. When the UA requests QoS, it includes the media authorization tokens with the resource reservation.
SIP UAは、各表示されたダイアログのための一個の以上（100を除く）のすべての信頼性のない暫定応答におけるメディアの認証トークン、最初の信頼性の1xxまたは2XX応答、およびのためにその信頼性の高い応答のすべての再送を含む、プロキシを有効にしたQoSにINVITEを送信しますダイアログ。 UAは、QoSを要求すると、それはリソース予約とメディアの認証トークンが含まれています。
A SIP UA may also receive an INVITE from its QoS enabled proxy which includes one or more media authorization tokens. In that case, when the UA requests QoS, it includes the media authorization tokens with the resource reservation. The resource reservation mechanism is not part of SIP and is not described within the scope of this document.
SIP UAはまた、1つ以上のメディア許可トークンを含む、そのQoSの有効プロキシからINVITEを受信することができます。 UAは、QoSを要求したときにその場合には、それはリソース予約とメディアの認証トークンが含まれています。リソース予約メカニズムは、SIPの一部ではなく、本文書の範囲内に記載されていません。
This document defines a private SIP header extension to support a media authorization scheme. In this architecture, a QoS enabled SIP proxy supplies the UA with one or more authorization tokens which are to be used in QoS requests. The extension defined allows network QoS resources to be authorized by the QoS enabled SIP proxy.
この文書では、メディアの認可スキームをサポートするために、民間のSIPヘッダ拡張を定義します。このアーキテクチャでは、QoSの有効なSIPプロキシは、QoS要求で使用される1つの以上の認証トークンとUAを提供しています。定義された拡張機能は、ネットワークのQoSリソースは、SIPプロキシを有効にしたQoSによって認可することができます。
A new P-Media-Authorization general header field is defined. The P-Media-Authorization header field contains one or more media authorization tokens which are to be included in subsequent resource reservations for the media flows associated with the session, that is, passed to an independent resource reservation mechanism, which is not specified here. The media authorization tokens are used for authorizing QoS for the media stream(s). The P-Media-Authorization header field is described by the following ABNF [4]:
新しいP-メディア認可一般ヘッダフィールドが定義されています。 Pメディア-Authorizationヘッダフィールドは、メディアをセッションに関連付けられたフローのための後続のリソース予約に含まれるべきである1つの以上のメディア認証トークンが含まれている、すなわち、ここで指定されていない独立したリソース予約機構に渡されます。メディア認証トークンは、メディアストリーム（S）のためのQoSを承認するために使用されています。 Pメディア-Authorizationヘッダフィールドは以下のABNFによって記載されている[4]。
P-Media-Authorization = "P-Media-Authorization" HCOLON P-Media-Authorization-Token *(COMMA P-Media-Authorization-Token)
P-メディア承認= "P-メディア-認証" HCOLONのP-メディア-認証トークン*（COMMA P-メディア-認証トークン）
P-Media-Authorization-Token = 1*HEXDIG
P-メディア-認証トークン= 1 * HEXDIG
Table 1 below is an extension of tables 2 and 3 in [3] for the new header field defined here. For informational purposes, this table also includes relevant entries for standards track extension methods published at the time this document was published. The INFO, PRACK, UPDATE, and SUBSCRIBE and NOTIFY methods are defined respectively in [11], [9], [12], and [10].
1以下の表は、ここで定義された新しいヘッダフィールドの[3]の表2および3の拡張です。情報提供の目的のために、この表には、この文書が公開された時点で公開されている標準トラック拡張メソッドに関連するエントリが含まれています。 INFO、PRACK、UPDATE、およびSUBSCRIBE及びNOTIFYメソッドはでそれぞれ定義されている[11]、[9]、[12]及び[10]。
Where proxy ACK BYE CAN INV OPT REG P-Media-Authorization R ad o - - o - - P-Media-Authorization 2xx ad - - - o - - P-Media-Authorization 101-199 ad - - - o - -
どこプロキシACK BYE CAN INV OPT REG P-メディア・認可のR広告O - - - O - P-メディア-認証2xxの広告 - - - - O - P-メディア・認可の101から199の広告 - - - ○ - -
Where proxy INF PRA UPD SUB NOT P-Media-Authorization R ad - o o - - P-Media-Authorization 2xx ad - o o - -
プロキシINF PRA UPDのSUB、NOT P-メディア・認可のR広告 - 〇〇 - - P-メディア・認証の2xx広告 - 〇〇 - -
Table 1: Summary of header fields.
表1：ヘッダフィールドの要約。
The P-Media-Authorization header field can be used only in SIP requests or responses that can carry a SIP offer or answer. This naturally keeps the scope of this header field narrow.
P-メディア-AuthorizationヘッダフィールドはSIPの申し出または回答を運ぶことができるSIP要求または応答で使用することができます。これは当然、狭いこのヘッダフィールドの範囲を保持します。
This section defines SIP [3] procedures for usage in media authorization compatible systems, from the point of view of the authorizing QoS.
このセクションでは、認可のQoSの観点から、メディア許可互換システムでの使用のためのSIP [3]の手順を規定します。
The initial SIP INVITE message, mid-call messages that result in network QoS resource changes, and mid-call changes in call destination should be authorized. These SIP messages are sent through the QoS enabled proxies to receive this authorization. In order to authorize QoS, the QoS enabled SIP proxy MAY need to inspect message bodies that describe the media streams (e.g., SDP). Hence, it is recommended (as may be appropriate within the applicability scope in Section 1 of this document) that such message bodies not be encrypted end-to-end.
最初のSIPは、ネットワークQoSリソースの変更につながるメッセージ、通話中INVITEメッセージ、および通話先で通話中の変更が許可されなければなりません。これらのSIPメッセージは、この承認を受けるためにプロキシを有効なQoSを経由して送信されます。 QoSを許可するために、SIPプロキシを有効QoSはメディアストリーム（例えば、SDP）を記述したメッセージボディを検査する必要があるかもしれません。したがって、このようなメッセージ本体は、エンドツーエンド暗号化されていないことを（このドキュメントのセクション1における適用性の範囲内で適切であり得るように）が推奨されます。
The P-Media-Authorization-Token, which is contained in the P-Media-Authorization header, is included for each dialog in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response for the dialog sent by the QoS enabled SIP proxy to the UAC.
Pメディア-Authorizationヘッダに含まれるP-メディア許可トークンは、（100を除く）のすべての信頼できない暫定応答内の各ダイアログ、最初の信頼1XXまたは2XX応答、およびその信頼性のすべての再送のために含まれていますUACにSIPプロキシ有効なQoSにより送信されたダイアログの応答。
The UAC should use all the P-Media-Authorization-Tokens from the most recent request/response that contained the P-Media-Authorization header when requesting QoS for the associated media stream(s). This applies to both initial and subsequent refresh reservation messages (for example, in an RSVP-based reservation system). A reservation function within the UAC should convert each string of hex digits into binary, and utilize each result as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token). These Policy-Elements would typically contain the authorizing entity and credentials, and be used in an RSVP request for media data stream QoS resources.
UACは、関連付けられたメディア・ストリーム（S）のためのQoSを要求するときにP-メディア-Authorizationヘッダを含んでいた最新の要求/応答からすべてのP-メディア許可トークンを使用する必要があります。これは、（例えば、RSVPベースの予約システムにおける）両方の初期および後続のリフレッシュ予約メッセージに適用されます。 UAC内予約機能バイナリに進数字の各文字列を変換し、RFC 2750で定義されるように、ポリシー要素として各結果を利用すべきである[5]（長さを除くが、各トークンに含まれるp型を含みます） 。これらのポリシー要素は、典型的に認可実体と認証情報を含むことになり、メディアデータストリームのQoSリソースのためのRSVP要求で使用すること。
The User Agent Server receives the P-Media-Authorization-Token in an INVITE (or other) message from the QoS enabled SIP proxy. If the response contains a message body that describes media streams for which the UA desires QoS, it is recommended (as may be appropriate within the applicability scope in Section 1 of this document) that this message body not be encrypted end-to-end.
ユーザエージェントサーバは、SIPプロキシ有効なQoSからのINVITE（または他の）メッセージ内のP-メディア-認証トークンを受け取ります。応答は、UAは、QoSを希望するメディアストリームを記述するメッセージボディが含まれている場合、それは推奨されている（このドキュメントのセクション1における適用性の範囲内で適切であるかもしれない）、このメッセージ本体は、エンドツーエンドの暗号化されないこと。
The UAS should use all the P-Media-Authorization-Tokens from the most recent request/response that contained the P-Media-Authorization header when requesting QoS for the associated media stream(s). This applies both to initial and subsequent refresh reservation messages (for example, in an RSVP-based reservation system). A reservation function within the UAS should convert each string of hex digits into binary, and utilize each result as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token). These Policy-Elements would typically contain the authorizing entity and credentials, and be used in an RSVP request for media data stream QoS resources.
UASは、関連付けられたメディア・ストリーム（S）のためのQoSを要求するときにP-メディア-Authorizationヘッダを含んでいた最新の要求/応答からすべてのP-メディア許可トークンを使用する必要があります。これは、（例えば、RSVPベースの予約システムに）初期及び後続のリフレッシュ予約メッセージの両方に適用されます。 UAS内予約機能バイナリに進数字の各文字列を変換し、RFC 2750で定義されるように、ポリシー要素として各結果を利用すべきである[5]（長さを除くが、各トークンに含まれるp型を含みます） 。これらのポリシー要素は、典型的に認可実体と認証情報を含むことになり、メディアデータストリームのQoSリソースのためのRSVP要求で使用すること。
When the originating QoS enabled proxy (OP) receives an INVITE (or other) message from the UAC, the proxy authenticates the caller, and verifies that the caller is authorized to receive QoS.
発信QoSの対応プロキシ（OP）は、UACからINVITE（または他の）メッセージを受信すると、プロキシは、発信者を認証し、発呼者がQoSを受信することを許可されていることを検証します。
In cooperation with an originating Policy Decision Point (PDP-o), the OP obtains and/or generates one or more media authorization tokens. These contain sufficient information for the UAC to get the authorized QoS for the media streams. Each media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token), and then converted to a string of hex digits to form a P-Media-Authorization-Token. The proxy's resource management function may inspect message bodies that describe the media streams (e.g., SDP), in both requests and responses in order to decide what QoS to authorize.
発信ポリシー決定ポイント（PDP-O）と協働して、OPは、取得および/または1つ以上のメディア認証トークンを生成します。これらは、UACは、メディアストリームのための認可QoSを取得するための十分な情報が含まれています。各メディア許可トークンは、RFC 2750で定義されるように[5]（長さを除くが、各トークンに含まれるp型を含む）、ポリシー要素としてフォーマットし、次にPを形成する桁の16進文字列に変換されます。 - メディア - 認証トークン。プロキシのリソース管理機能は、QoSを許可するかを決定するために、両方の要求と応答に、メディアストリーム（例えば、SDP）を記述したメッセージボディを検査することができます。
For each dialog that results from the INVITE (or other) message received from the UAC, the originating proxy must add a P-Media-Authorization header with the P-Media-Authorization-Token in all unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable response the proxy sends to the UAC, if that response may result in network QoS changes. A response with an SDP may result in such changes.
UACから受信したINVITE（または他の）メッセージから生じる各ダイアログのために、発信プロキシは（100を除く）すべての信頼できない暫定的な応答でP-メディア許可トークンとP-メディア-Authorizationヘッダを追加する必要があり、最初の信頼性の1xxまたは2XX応答、およびその応答は、ネットワークのQoS変化をもたらす可能性がある場合、プロキシは、UACに送信する信頼性の高い応答のすべての再送。 SDPとの反応は、このような変化をもたらし得ます。
The Destination QoS Enabled Proxy (DP) verifies that the called party is authorized to receive QoS.
先のQoS対応プロキシ（DP）は、着信側がQoSを受け取ることを許可されていることを確認します。
In cooperation with a terminating Policy Decision Point (PDP-t), the DP obtains and/or generates a media authorization token that contains sufficient information for the UAS to get the authorized QoS for the media streams. The media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5] (excluding Length, but including P-Type which is included in each token), and then converted to a string of hex digits to form a P-Media-Authorization-Token. The proxy's resource management function may inspect message bodies that describe the media streams (e.g., SDP), in both requests and responses in order to decide what QoS to authorize.
終端ポリシー決定ポイント（PDP-T）と共同で、DPは、取得および/またはUASはメディアストリームのための認可QoSを取得するための十分な情報が含まれているメディアの認証トークンを生成します。メディア許可トークンは、RFC 2750で定義されるように[5]（長さを除くが、各トークンに含まれるp型を含む）、ポリシー要素としてフォーマットし、次にPを形成する桁の16進文字列に変換されます。 - メディア - 認証トークン。プロキシのリソース管理機能は、QoSを許可するかを決定するために、両方の要求と応答に、メディアストリーム（例えば、SDP）を記述したメッセージボディを検査することができます。
The Destination Proxy must add the P-Media-Authorization header with the P-Media-Authorization-Token in the INVITE (or other) request that it sends to the UAS if that message may result in network QoS changes. A message with an SDP body may result in such changes.
宛先プロキシは、メッセージがネットワークのQoS変化をもたらす可能性がある場合、それはUASに送信するINVITE（または他の）要求にP-メディア許可トークンとP-メディア-Authorizationヘッダを追加する必要があります。 SDPボディのメッセージは、そのような変化をもたらし得ます。
Below we provide an example of how the P-Media-Authorization header field can be used in conjunction with the Resource Reservation Protocol (RSVP) [7]. The example assumes that an offer arrives in the initial INVITE and an answer arrives in a reliable provisional response [9], which contains an SDP description of the media flow.
下に我々は、P-メディア-Authorizationヘッダフィールドは、[7]リソース予約プロトコル（RSVP）と組み合わせて使用することができる方法の例を提供します。例では、オファーがINVITE最初に到着することを前提と答えがメディアフローのSDP記述を含む信頼できる暫定的な応答[9]に到着します。
Figure 2 presents a high-level overview of a basic call flow with media authorization from the viewpoint of the UAC. Some policy interactions have been omitted for brevity.
図2は、UACの観点からメディアの権限を持つ基本的なコールフローの高レベルの概要を提示します。いくつかの政策対話は、簡潔にするため省略されています。
When a user goes off-hook and dials a telephone number, the UAC collects the dialed digits and sends the initial (1)INVITE message to the originating SIP proxy.
ユーザがオフフックに移行し、電話番号をダイヤルすると、UACは、ダイヤルされた数字を収集し、発信SIPプロキシに初期（1）INVITEメッセージを送信します。
The originating SIP proxy (OP) authenticates the user/UAC and forwards the (2)INVITE message to the proper SIP proxy.
発信SIPプロキシ（OP）は、ユーザ/ UACを認証し、（2）適切なSIPプロキシにINVITEメッセージを転送します。
Assuming the call is not forwarded, the terminating end-point sends a (3)18x response to the initial INVITE via OP. Included in this response is an indication of the negotiated bandwidth requirement for the connection (in the form of an SDP description [8]).
コールが転送されないと仮定すると、終端エンドポイントは、最初に（3）18X応答OPを介してINVITEを送信します。この応答に含まれる（SDP記述の形で[8]）の接続のためのネゴシエート帯域幅要件の指標です。
When OP receives the (3)18x, it has sufficient information regarding the end-points, bandwidth and characteristics of the media exchange. It initiates a Policy-Setup message to PDP-o, (4)AuthProfile.
OP（3）18Xを受信すると、エンドポイント、帯域幅、およびメディア交換の特性に関する十分な情報を有しています。これはPDP-Oへのポリシーセットアップメッセージ、（4）AuthProfileを開始します。
The PDP-o stores the authorized media description in its local store, generates an authorization token that points to this description, and returns the authorization token to the OP, (5)AuthToken.
PDP-O格納そのローカルストアに許可メディア記述は、この記述を指す認証トークンを生成し、そして、OP〜（5）を持つAuthToken許可トークンを返します。
UAC ER-o PDP-o OP
|(1)INVITE | | | Client Authentication
|------------------------------------------->| and Call Authoriz.
| | | | (2)INVITE
| | | |-------------->
| | | | (3)18x
| | |(4)AuthProfile |<--------------
| | |<--------------|
| | |(5)AuthToken |
| | |-------------->| Auth. Token put into
| | | (6)18x | P-Media-Authorization
|<-------------------------------------------| header extension.
|---(7)PRACK-------------------------------->|
| |--(8)PRACK---->
| |<-(9)200 (PRACK)
|<--(10)200 (PRACK)--------------------------|
| | | |
|Copies the RSVP policy object |
|from the P-Media-Authorization |
|(11)RSVP-PATH | |
|----------->| (12)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (13)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(14)RSVP-PATH
| |------------------------------------------------>
| | | |(15)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
|(16)RSVP-RESV | |
|----------->| (17)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (18)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(19)RSVP-RESV
| |--------------------------------------------------->
| | | |(20)RSVP-RESV
|<----------------------------------------------------------------
| | | |
Figure 2 - Media Authorization with RSVP (UAC)
図2 - RSVPとメディア認可（UAC）
The OP includes the authorization token in the P-Media-Authorization header extension of the (6)18x message.
OPは、（6）18XメッセージのP-MEDIA-Authorizationヘッダの拡張で許可トークンを含みます。
Upon receipt of the (6)18x message, the UAC stores the media authorization token from the P-Media-Authorization header. Also, the UAC acknowledges the 18x message by sending a (7)PRACK message, which is responded to with (10) 200.
（6）18Xメッセージを受信すると、UACは、P-メディア-Authorizationヘッダからメディア許可トークンを格納します。また、UACは（10）200で応答される（7）PRACKメッセージを送信することにより、18Xメッセージを肯定応答します。
Before sending any media, the UAC requests QoS by sending an (11)RSVP-PATH message, which includes the previously stored P-Media-Authorization-Token as a Policy-Element.
任意のメディアを送信する前に、UACは、ポリシー要素として予め記憶されたP-メディア許可トークンを含む（11）RSVP-PATHメッセージを送信することによって、QoSを要求します。
ER-o, upon receipt of the (11)RSVP-PATH message, checks the authorization through a PDP-o COPS message exchange, (12)REQ. PDP-o checks the authorization using the stored authorized media description that was linked to the authorization token it returned to OP. If authorization is successful, PDP-o returns an "install" Decision, (13)DEC.
ER-oは、（11）RSVP-PATHメッセージを受信すると、PDP-Oを許可は、メッセージ交換、（12）REQをCOPSチェックします。 PDP-Oは、OPに返さ認証トークンにリンクされた格納された許可メディア記述を使用して、許可をチェックします。認証が成功した場合、PDP-Oは、「インストール」の決定、（13）12を返します。
ER-o checks the admissibility for the request, and if admission succeeds, it forwards the (14)RSVP-PATH message.
ER-Oは、要求のための許容をチェックし、入院が成功した場合、それは（14）RSVP-PATHメッセージを転送します。
Once UAC receives the (15)RSVP-PATH message from UAS, it sends the (16)RSVP-RESV message to reserve the network resources.
UACがUASから（15）RSVP-PATHメッセージを受信すると、それはネットワークリソースを予約する（16）RSVP-RESVメッセージを送信します。
ER-o, upon receiving the (16)RSVP-RESV message checks the authorization through a PDP-o COPS message exchange, (17)REQ. PDP-o checks the authorization using the stored authorized media description that was linked to the authorization token it returned to OP. If authorization is successful, PDP-o returns an "install" Decision, (18)DEC.
（16）RSVP-RESVメッセージを受信するとER-Oは、PDP-Oを許可は、メッセージ交換、（17）REQをCOPSチェックします。 PDP-Oは、OPに返さ認証トークンにリンクされた格納された許可メディア記述を使用して、許可をチェックします。認証が成功した場合は、PDP-oが「インストール」の決定、（18）12月を返します。
ER-o checks the admissibility for the request, and if admission succeeds, it forwards the (19)RSVP-RESV message.
ER-Oは、要求のための許容をチェックし、入院が成功した場合、それは（19）RSVP-RESVメッセージを転送します。
Upon receiving the (20)RSVP-RESV message, network resources have been reserved in both directions.
（20）RSVP-RESVメッセージを受信すると、ネットワークリソースは、両方向に予約されています。
Figure 3 presents a high-level overview of a call flow with media authorization from the viewpoint of the UAS. Some policy interactions have been omitted for brevity.
図3は、UASの観点からメディアの権限を持つコールフローの高レベルの概要を提示します。いくつかの政策対話は、簡潔にするため省略されています。
Since the destination SIP proxy (DP) has sufficient information regarding the endpoints, bandwidth, and characteristics of the media exchange, it initiates a Policy-Setup message to the terminating Policy Decision Point (PDP-t) on receipt of the (1)INVITE.
先SIPプロキシ（DP）は、十分なエンドポイントに関する情報、帯域幅、およびメディア交換の特性を有しているので、（1）INVITEを受信する終端ポリシー決定ポイント（PDP-T）へのポリシーセットアップメッセージを開始します。
UAS ER-t PDP-t DP
| | | | (1)INVITE
| | | |<--------------
| | | | Proxy Authentication
| | | (2)AuthProfile| and Call Authoriz.
| | |<--------------|
| | | (3)AuthToken |
| | |-------------->| Auth. Token put into
| | | (4)INVITE | P-Media-Authorization
|<------------------------------------------| header extension
| (5)18x | | |
|------------------------------------------>| (6)18x
|Copies the RSVP policy object |-------------->
|from the P-Media-Authorization |
|(7)RSVP-PATH | |
|---------->| (8)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (9)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(10)RSVP-PATH
| |-------------------------------------------------->
| | | |(11)RSVP-PATH
|<--------------------------------------------------------------
|Copies the RSVP policy object |
|from the P-Media-Authorization |
| (12)RSVP-RESV | |
|---------->| | |
| | (13)REQ | |
| |-------------->| Using the Auth-Token and Authorized
| | (14)DEC | Profile that is set by the SIP Proxy
| |<--------------| the PDP makes the decision
| | | |(15)RSVP-RESV
| |--------------------------------------------------->
| | | |(16)RSVP-RESV
|<---------------------------------------------------------------
| | | |<-(17)PRACK---------
|<--(18)PRACK ------------------------------|
|---(19)200 (PRACK) ----------------------->|
| | | |--(20)200 (PRACK)-->
| | | |
Figure 3 - Media Authorization with RSVP (UAS)
図3 - RSVPとメディア許可（UAS）
PDP-t stores the authorized media description in its local store, generates an authorization token that points to this description, and returns the authorization token to DP. The token is placed in the (4)INVITE message and forwarded to the UAS.
PDP-Tストアそのローカルストア内の許可メディア記述は、この記述を指す認証トークンを生成し、DPに認証トークンを返します。トークンは、（4）INVITEメッセージに入れ、UASに転送されます。
Assuming that the call is not forwarded, the UAS sends a (5)18x response to the initial INVITE message, which is forwarded back to UAC. At the same time, the UAS sends a (7)RSVP-PATH message which includes the previously stored P-Media-Authorization-Token as a Policy-Element.
コールが転送されないと仮定すると、UASは、バックUACに転送され、初期INVITEメッセージ、〜（5）18X応答を送信します。同時に、UASは、ポリシー要素として予め記憶されたP-メディア許可トークンを含む（7）RSVP-PATHメッセージを送信します。
ER-t, upon receiving the (7)RSVP-PATH message checks the authorization through a PDP-t COPS message exchange. PDP-t checks the authorization using the stored authorized media description that was linked to the authorization token it returned to DP. If authorization is successful, PDP-t returns an "install" Decision, (9)DEC.
（7）RSVP-PATHメッセージを受信するとER-tは、メッセージ交換をCOPS PDP-Tを介して権限をチェックします。 PDP-Tは、DPに戻っ認証トークンにリンクされた格納された許可メディア記述を使用して、許可をチェックします。認証が成功した場合は、PDP-tが「インストール」の決定、（9）12月を返します。
ER-t checks the admissibility for the request, and if admission succeeds, it forwards the (10)RSVP-PATH message.
ER-Tは要求に対する許容性をチェックし、入院が成功した場合、それは（10）RSVP-PATHメッセージを転送します。
Once the UAS receives the (11)RSVP-PATH message, it sends the (12)RSVP-RESV message to reserve the network resources.
UASは、（11）RSVP-PATHメッセージを受信すると、それはネットワークリソースを予約する（12）RSVP-RESVメッセージを送信します。
ER-t, upon reception of the (12)RSVP-RESV message, checks the authorization through a PDP-t COPS message exchange. PDP-t checks the authorization using the stored authorized media description that was linked to the authorization token that it returned to DP. If authorization is successful, PDP-t returns an "install" Decision, (14)DEC.
ER-Tは、（12）RSVP-RESVメッセージを受信すると、メッセージ交換をCOPS PDP-Tを介して権限をチェックします。 PDP-Tは、DPに戻すことを許可トークンにリンクされた格納された許可メディア記述を使用して、許可をチェックします。認証が成功した場合は、PDP-tが「インストール」の決定、（14）12月を返します。
ER-t checks the admissibility for the request and if admission succeeds, it forwards the (15)RSVP-RESV message.
ER-Tは要求に対する許容性をチェックし、入院が成功した場合、それは（15）RSVP-RESVメッセージを転送します。
Upon receiving the (16)RSVP-RESV message, network resources have been reserved in both directions.
（16）RSVP-RESVメッセージを受信すると、ネットワークリソースは、両方向に予約されています。
For completeness, we show the (17)PRACK message for the (5) 18x response and the resulting (19) 200 response acknowledging the PRACK.
完全性のために、我々は、（5）18X応答のため（17）、PRACKメッセージおよびPRACKを承認得られた（19）200応答を示します。
The use of media authorization makes it possible to control the usage of network resources. In turn, this makes IP Telephony more robust against denial of service attacks and various kinds of service frauds. By using the authorization capability, the number of flows, and the amount of network resources reserved can be controlled, thereby making the IP Telephony system dependable in the presence of scarce resources.
メディア認証を使用すると、ネットワークリソースの使用を制御することが可能となります。ターンでは、これは、サービス拒否攻撃やサービス詐欺の様々な種類の拒否に対するIPテレフォニーをより堅牢になります。承認機能を使用して、フローの数、および予約済みのネットワークリソースの量は、それによって希少資源の存在下での信頼性のIPテレフォニーシステムを作り、制御することができます。
In order to control access to QoS, a QoS enabled proxy should authenticate the UA before providing it with a media authorization token. Both the method and policy associated with such authentication are outside the scope of this document, however it could, for example, be done by using standard SIP authentication mechanisms, as described in [3].
QoSのへのアクセスを制御するためには、プロキシを有効にQoSは、メディア許可トークンでそれを提供する前に、UAを認証する必要があります。方法と、認証に関連付けられたポリシーの両方はで説明したように、しかし、それは、例えば、標準的なSIP認証メカニズムを使用して行うことができ、この文書の範囲外である[3]。
Media authorization tokens sent in the P-Media-Authorization header from a QoS enabled proxy to a UA MUST be protected from eavesdropping and tampering. This can, for example, be done through a mechanism such as IPSec or TLS. However, this will only provide hop-by-hop security. If there is one or more intermediaries (e.g., proxies), between the UA and the QoS enabled proxy, these intermediaries will have access to the P-Media-Authorization header field value, thereby compromising confidentiality and integrity. This will enable both theft-of-service and denial-of-service attacks against the UA. Consequently, the P-Media-Authorization header field MUST NOT be available to any untrusted intermediary in the clear or without integrity protection. There is currently no mechanism defined in SIP that would satisfy these requirements. Until such a mechanism exists, proxies MUST NOT send P-Media-Authorization headers through untrusted intermediaries, which might reveal or modify the contents of this header. (Note that S/MIME-based encryption in SIP is not available to proxy servers, as proxies are not allowed to add message bodies.)
UAにプロキシを有効にしたQoSからP-MEDIA-Authorizationヘッダーで送信されたメディア認証トークンは、盗聴や改ざんから保護されなければなりません。これは、例えば、IPSecまたはTLSなどの機構を介して行うことができます。しかし、これが唯一のホップバイホップのセキュリティを提供します。一つ以上の仲介者（例えば、プロキシ）が存在する場合、UAプロキシを有効にしたQoSとの間に、これらの媒体は、それによって機密性と完全性を損なう、P-メディア-Authorizationヘッダフィールド値にアクセスする必要があります。これは、サービスの盗難やUAに対するサービス拒否攻撃の両方を有効にします。その結果、P-メディア-Authorizationヘッダフィールドは、明確にまたは完全性保護なしに信頼されていないの仲介に利用可能にすることはできません。これらの要求を満足させるSIPで定義されたメカニズムは現在ありません。そのような機構が存在するまで、プロキシはこのヘッダの内容を明らかにするまたは変更可能性のある、信頼できない媒体を介してP-メディア認可ヘッダを送ってはいけません。 （プロキシがメッセージ本文を追加することはできませんとしてSIPでそのS / MIMEベースの暗号化は、プロキシサーバには使用できません。）
QoS enabled proxies may need to inspect message bodies describing media streams (e.g., SDP). Consequently, such message bodies should not be encrypted. In turn, this will prevent end-to-end confidentiality of the said message bodies, which lowers the overall security possible.
プロキシ有効QoSは、メディアストリーム（例えば、SDP）を記述したメッセージボディを検査する必要があるかもしれません。したがって、このようなメッセージ本文を暗号化するべきではありません。ターンでは、これは可能な全体的なセキュリティが低下したメッセージ本文のエンドツーエンドの機密性を、防ぐことができます。
This document defines a new private SIP header for media authorization, "P-Media-Authorization". This header has been registered by the IANA in the SIP header registry, using the RFC number of this document as its reference.
この文書では、メディアの認可、「P-メディア-認証」のための新しいプライベートSIPヘッダーを定義します。このヘッダは、参照としてこの文書のRFC番号を使用して、SIPヘッダレジストリにIANAによって登録されています。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[5]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[6] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[6] Yavatkar、R.、Pendarakis、D.とR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[7]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[9] RFC 3262、2002年6月ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[10] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[10]ローチ、A. B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[11] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[11]ドノバン、S.、 "SIP INFOメソッド"、RFC 2976、2000年10月。
[12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002.
[12]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年9月。
The following people contributed significantly and were co-authors on earlier versions of this document:
次の人は、このドキュメントの以前のバージョンの共著者に多大な貢献をしていました：
Bill Marshall (AT&T), K. K. Ramakrishnan (AT&T), Ed Miller (Terayon), Glenn Russell (CableLabs), Burcak Beser (Juniper Networks), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen (Cisco), John Pickens (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks), Doc Evans (Arris), and Keith Kelly (NetSpeak).
ビル・マーシャル（AT＆T）、KKラマクリシュナン（AT＆T）、エド・ミラー（Terayon）、グレン・ラッセル（CableLabsに）、Burcak Beser（ジュニパーネットワークス）、マイク・Mannette（3Com社）、クルト・スタインブレナー（3Com社）、デイヴ・オラン（シスコ）、フレミングアンドレア（シスコ）、ジョン・ピケンズ（COM21）、Poornima Lalwaney（ノキア）、ジョン・フェロー（カッパーマウンテンネットワーク）、ドック・エバンス（ARRIS）、キース・ケリー（NetSpeak）。
The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The contributors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent Cable Communications. Dean Willis and Rohan Mahy provided valuable feedback as well.
PacketCableのプロジェクトにおける分散型コールシグナリングの仕事は、多くの異なる企業を代表する多数の人々の仕事です。貢献者は認識し、彼らの支援のために次のことを感謝したいと思います：ジョン・ホイーラー、モトローラ。デビッド・ボードマン、ダニエル・ポール、ARRISインタラクティブ。ビル・ブラム、ジェイストラター、ジェフOllis、クライヴHolborow、モトローラ。ダグNewlin、グイド・シュスター、Ikhlaqシドゥ、3Com社。ジリ・マトゥーセック、ベイネットワーク。 Farzi Khazai、ノーテル。ジョン・チャップマン、ビルGuckel、マイケルRamalho、シスコ;チャックKalmanek、ダグNortz、ジョンLawser、ジェームズ・チェン、桐-ハイシャオ、Parthoミシュラ、AT＆T; Telcordia Technologies社;そしてルーセントケーブルコミュニケーションズ。ディーンウィリス、ローハンマーイは同様に貴重なフィードバックを提供します。
Bill Marshall AT&T Florham Park, NJ 07932
ビル・マーシャルAT＆Tフローラムパーク、NJ 07932
EMail: wtm@research.att.com
メールアドレス：wtm@research.att.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。