Network Working Group O. Levin
Request for Comments: 4488 Microsoft Corporation
Category: Standards Track May 2006
Suppression of Session Initiation Protocol (SIP)
REFER Method Implicit Subscription
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request.
RFC 3515で定義されたセッション開始プロトコル（SIP）が自動的にREFERによって要求されたトランザクションを実行するには、受信者の状況についてREFER要求を送信側に通知するために使用され、通常短命イベントサブスクリプションを確立拡張を参照してください。これらの通知は、すべてのケースで必要とされていません。この仕様は、REFER要求に含めることができる新たなSIPの拡張ヘッダフィールドを使用してイベント・サブスクリプションおよびその後の通知を自動的に確立することを防止する方法を提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Preventing Forking of REFER Requests . . . . . . . . . . . . . 4
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7
The REFER specification [3] specifies that every REFER creates an implicit subscription between the REFER-Issuer and the REFER-Recipient.
REFER仕様[3]すべてのREFERは、REFER発行者およびREFER-受信者間の暗黙のサブスクリプションを作成することを指定します。
This document defines a new SIP header field: "Refer-Sub" meaningful within a REFER transaction only. This header field, when set to "false", specifies that a REFER-Issuer requests that the REFER-Recipient doesn't establish an implicit subscription and the resultant dialog.
この文書は、新しいSIPヘッダフィールドを定義しています。「を参照してください-SUB」有意義REFERトランザクション内のみ。 「偽」に設定され、このヘッダフィールドは、REFER発行者はREFER-受信者は、暗黙的なサブスクリプションと結果のダイアログを確立しないことを要求していることを指定します。
This document defines a new option tag: "norefersub". This tag, when included in the Supported header field, indicates that a User Agent (UA) is capable of accepting a REFER request without creating an implicit subscription when acting as a REFER-Recipient.
「norefersub」：この文書は、新しいオプションタグを定義します。 Supportedヘッダーフィールドに含まれるこのタグは、ユーザエージェント（UA）は、REFER受信者として動作する場合、暗黙的なサブスクリプションを作成することなく、REFER要求を受け入れることができることを示しています。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
To simplify discussions of the REFER method and its extensions, the three terms below are being used throughout the document:
REFERメソッドの議論とその拡張機能を簡素化するために、以下の3つの用語は、文書全体で使用されています：
o REFER-Issuer: the UA issuing the REFER request
O REFER発行者を：UAは、REFERリクエストを発行します
o REFER-Recipient: the UA receiving the REFER request
O REFER-受信者：UAは、REFERリクエストを受信します
o REFER-Target: the UA designated in the Refer-To Uniform Resource Identifier (URI)
O REFER-Targetの：UAが参照からのURI（Uniform Resource Identifier）で指定
The REFER specification mandates that every REFER creates an implicit subscription between the REFER-Issuer and the REFER-Recipient. This subscription results in at least one NOTIFY being sent from the REFER-Recipient to the REFER-Issuer. The REFER-Recipient may choose to cancel the implicit subscription with this NOTIFY. The REFER-Issuer may choose to cancel this implicit subscription with an explicit SUBSCRIBE (Expires: 0) after receipt of the initial NOTIFY.
すべてのREFERは、REFER発行者およびREFER-受信者間の暗黙のサブスクリプションを作成し、仕様の義務を参照してください。少なくとも一つのこのサブスクリプションの結果は、REFER発行者を参照してください-受信者から送信されて通知します。 REFER-受信者は、このNOTIFYとの暗黙のサブスクリプションをキャンセルすることもできます。 REFER発行者は、SUBSCRIBE、明示的にこの暗黙のサブスクリプションをキャンセルすることもできます（有効期限：0）初期の受領後NOTIFY。
One purpose of requiring the implicit subscription and initial NOTIFY is to allow for the situation where the REFER request gets forked and the REFER-Issuer needs a way to see the multiple dialogs that may be established as a result of the forked REFER. This is the same approach used to handle forking of SUBSCRIBE [4] requests. Where the
一つの暗黙のサブスクリプションを必要とすることを目的と最初のNOTIFYリクエストがフォークとREFER発行者を取得しますREFER状況を可能にすることであるフォークREFERの結果として確立することができる複数のダイアログを参照する方法が必要です。これは、SUBSCRIBE [4]リクエストのフォークを処理するために使用されるのと同じアプローチです。どこ
REFER-Issuer explicitly specifies that forking not occur, the requirement that an implicit subscription be established is unnecessary.
REFER発行者が明示的に発生していないフォーク、暗黙のサブスクリプションを確立することが必要条件が不要であることを指定します。
Another purpose of the NOTIFY is to inform the REFER-Issuer of the progress of the SIP transaction that results from the REFER at the REFER-Recipient. In the case where the REFER-Issuer is already aware of the progress of the requested operation, such as when the REFER-Issuer has an explicit subscription to the dialog event package at the REFER-Recipient, the implicit subscription and resultant NOTIFY traffic related to the REFER can create an unnecessary network overhead.
NOTIFYのもう一つの目的は、REFER-受信者のREFERの結果でSIPトランザクションの進行のREFER-発行者に通知することです。 REFER発行者は、このようなREFER発行者はREFER-受信者の対話イベントパッケージへの明示的なサブスクリプションを持っているときのように、要求された操作の進行状況をすでに認識している場合は、暗黙のサブスクリプションおよび結果は、トラフィックに関連するNOTIFY不要なネットワークのオーバーヘッドを作成することができます参照してください。
This document defines a new SIP header field: "Refer-Sub". This header field is meaningful and MAY be used with a REFER request and the corresponding 2XX response only. This header field set to "false" specifies that a REFER-Issuer requests that the REFER-Recipient doesn't establish an implicit subscription and the resultant dialog. Note that when using this extension, the REFER remains a target refresh request (as in the default case -- when the extension is not used).
「参照の-SUB」：この文書は、新しいSIPヘッダフィールドを定義します。このヘッダーフィールドは、有意義であり、REFERリクエストのみ対応2xx応答と共に使用することができます。 「偽」に設定され、このヘッダフィールドは、REFER発行者はREFER-受信者は、暗黙的なサブスクリプションと結果のダイアログを確立しないことを要求していることを指定します。この拡張機能を使用する場合、REFERが（ - 拡張を使用しない場合、デフォルトの場合のように）ターゲットリフレッシュ要求のままであることに注意してください。
This document adds the following entry to Table 2 of [2]. The additions to this table are also provided for extension methods at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way:
この文書では、[2]の表2に次のエントリを追加します。このテーブルへの追加は、この文書の発行時に拡張メソッドのために提供されます。これは、読者への礼儀として提供され、どのような方法で規範的ではありません。
Header field where proxy ACK BYE CAN INV OPT REG MSG
ヘッダフィールドプロキシACK BYE CAN INV OPT REG MSG
Refer-Sub R, 2xx - - - - - - -
参照サブR、2XX - - - - - - -
Header field where SUB NOT REF INF UPD PRA PUB
SUB INF UPD PRAのPUBをREFませヘッダフィールド
Refer-Sub R, 2xx - - o - - - -
参照サブR、2XX - - O - - - -
The Refer-Sub header field MAY be encrypted as part of end-to-end encryption.
参照のサブヘッダフィールドは、エンドツーエンド暗号化の一部として暗号化されてもよいです。
The syntax of the header field follows the BNF defined below:
ヘッダフィールドの構文は、以下に定義BNFに従います。
Refer-Sub = "Refer-Sub" HCOLON refer-sub-value *(SEMI exten) refer-sub-value = "true" / "false" exten = generic-param
参照-SUB = "参照-SUB" HCOLON参照サブ値*（SEMI EXTEN）参照サブ値= "真" / "偽" EXTEN = GENERIC-PARAM
where the syntax of generic-param is defined in [2].
ジェネリック-PARAMの構文は[2]で定義されます。
The "Refer-Sub" header field set to "false" MAY be used by the REFER-Issuer only when the REFER-Issuer can be certain that the REFER request will not be forked.
「偽」に設定「を参照してください-SUB」ヘッダフィールドは、REFER-発行者はREFER要求は二股されないことを特定することができる場合にのみ、REFER-発行者によって使用されてもよいです。
If the REFER-Recipient supports the extension and is willing to process the REFER transaction without establishing an implicit subscription, it MUST insert the "Refer-Sub" header field set to "false" in the 2xx response to the REFER-Issuer. In this case, no implicit subscription is created. Consequently, no new dialog is created if this REFER was issued outside any existing dialog.
REFER-受信者が拡張をサポートし、暗黙のサブスクリプションを確立することなくREFERトランザクションを処理するために喜んであれば、それはREFER発行者への2xx応答では「偽」に設定する「を参照してください-SUB」ヘッダフィールドを挿入しなければなりません。この場合、暗黙のサブスクリプションが作成されません。このREFERは、既存ダイアログ外で発行された場合その結果、新しいダイアログが作成されません。
If the REFER-Issuer inserts the "Refer-Sub" header field set to "false", but the REFER-Recipient doesn't grant the suggestion (i.e., either does not include the "Refer-Sub" header field or includes the "Refer-Sub" header field set to "true" in the 2xx response), an implicit subscription is created as in the default case.
REFER-発行者は「false」に設定「を参照してください-SUB」ヘッダフィールドを挿入するが、REFER受信者、すなわち提案（付与しない、のいずれか「を参照してください-SUB」ヘッダフィールドを含んでいないか、「含まれている場合サブ参照2xx応答に 『真」に設定されたヘッダフィールド』）、暗黙的なサブスクリプションは、デフォルトの場合のように作成されます。
This document also defines a new option tag, "norefersub". This tag, when included in the Supported header field, specifies that a User Agent (UA) is capable of accepting a REFER request without creating an implicit subscription when acting as a REFER-Recipient.
この文書は、新しいオプションタグ、「norefersub」を定義します。 Supportedヘッダーフィールドに含まれるこのタグは、ユーザエージェント（UA）は、REFER受信者として動作する場合、暗黙的なサブスクリプションを作成することなく、REFER要求を受け付けることが可能であることを指定します。
The REFER-Issuer can know the capabilities of the REFER-Recipient from the presence of the option tags in the Supported header field of the dialog initiating request or response. Another way of learning the capabilities would be by using presence, such as defined in [6]. However, if the capabilities of the REFER-Recipient are not known, using the "norefersub" tag with the Require header field is NOT RECOMMENDED. This is due to the fact that in the event the REFER-Recipient doesn't support the extension, in order to fall back to the normal REFER, the REFER-Issuer will need to issue a new REFER transaction thus resulting in additional round-trips.
REFER発行者は、要求または応答を開始]ダイアログボックスの[サポートされているヘッダフィールドのオプションタグの存在からREFER-受信者の能力を知ることができます。機能を学習する別の方法は、[6]で定義されるように、プレゼンスを使用してだろう。 REFER-受信者の能力はRequireヘッダーフィールドと「norefersub」タグを使用して、知られていない場合は、推奨されません。これは、イベントにREFER-受信者がREFER正常に戻ってフォールするためには、拡張子をサポートしていないという事実によるものである、REFER発行者は、新たなREFERトランザクションは、このように追加のラウンドトリップが生じ発行する必要があります。 。
As described in Section 8.2.2.3 in [2], a REFER-Recipient will reject a REFER request containing a Require: norefersub header field with a 420 (Bad Extension) response unless it supports this extension. Note that Require: norefersub can be present with a Refer-Sub: false header field.
それは、この拡張をサポートしない限り、420（悪い拡張）応答でnorefersubヘッダーフィールド：セクション8.2.2.3に記載されているように、[2]、REFER受信者は、要求を含むREFER要求を拒否します。 norefersubが参照サブと共に存在することができる：必要音符偽ヘッダーフィールド。
The REFER specification allows for the possibility of forking a REFER request that is sent outside of an existing dialog. In addition, a proxy may fork an unknown method type. Should forking occur, the sender of the REFER with "Refer-Sub" will not be aware as only a single 2xx response will be forwarded by the forking proxy. As a result, the responsibility is on the issuer of the REFER with "Refer-Sub" to ensure that no forking will result.
REFER仕様は、既存のダイアログの外部に送信されるREFERリクエストをフォークする可能性を可能にします。また、プロキシは未知のメソッドタイプをフォークしてもよいです。唯一の2XX応答がフォークプロキシによって転送されるように発生フォークべきで、「参照してください-SUB」とREFERの送信者は認識しません。その結果、責任は一切フォークが生じないようにするために「を参照してください-SUB」とREFERの発行者です。
If a REFER request to a given Request-URI might fork, the REFER-Issuer SHOULD NOT include the "Refer-Sub" header field. The REFER-Issuer SHOULD use standardized mechanisms for ensuring the REFER request does not fork. In absence of any other mechanism, the Request-URI of the REFER request SHOULD have Globally Routable User Agent URI (GRUU) properties according to the definitions of [5] as those properties ensure the request will not fork.
所与のRequest-URIを参照要求フォーク可能性がある場合、REFER-発行者は、「参照のサブ」ヘッダフィールドを含むべきではありません。 REFER-発行者はREFER要求フォークないを確保するための標準化されたメカニズムを使用すべきです。任意の他の機構が存在しない場合には、REFER要求のリクエストURIは、[5]これらの特性として要求フォークません保証の定義に従ってグローバルにルーティング可能なユーザエージェントURI（GRUU）特性を有するべきです。
An example of REFER that suppresses the implicit subscription is shown below. Note that the conventions used in the SIP Torture Test Messages [7] document are reused, specifically the <allOneLine> tag.
それは暗黙のサブスクリプションを抑制REFERの例を以下に示します。 SIP調教テストメッセージで使用される規則は、[7]文書は、具体的には、<allOneLine>タグに再利用されることに留意されたいです。
REFER sip:pc-b@example.com SIP/2.0 Via: SIP/2.0/TCP issuer.example.com;branch=z9hG4bK-a-1 From: <sip:a@example.com>;tag=1a <allOneLine> To: sip:b@example.com;opaque=urn:uuid:f8 1d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a </allOneLine> Call-ID: 1@issuer.example.com CSeq: 234234 REFER Max-Forwards: 70 Refer-To: <sip:c@example.com;method=INVITE> Refer-Sub: false Supported: norefersub Contact: sip:a@issuer.example.com Content-Length: 0
SIP参照：pc-b@example.com SIP / 2.0経由：SIP / 2.0 / TCP issuer.example.com;分岐= z9hG4bK-1：<SIP：a@example.com>;タグ= 1A <allOneLine >から：SIP：b@example.com;不透明= URN：UUID：F8 1d4fae-7dec-11D0-a765-00a0c91e6bf6;グリッド= 99A </ allOneLine>コールID：1@issuer.example.comのCSeq：234234が参照マックス・フォワード：70参照してください-TO：<SIP：c@example.com;方法= INVITE>参照してください-SUBを：偽サポート：norefersubお問い合わせ：SIP：a@issuer.example.comのContent-Length：0
This document registers a new SIP header field "Refer-Sub". This header field is only meaningful for the REFER request defined in RFC 3515 [3] and the corresponding response. The following information has been added to the SIP Header field sub-registry in the SIP Parameters Registry:
この文書は、新しいSIPヘッダフィールド「を参照してください-SUB」を登録します。このヘッダーフィールドは、RFC 3515 [3]及び対応する応答で定義されたREFER要求のためにのみ有効です。以下の情報は、SIPパラメータレジストリ内のSIPヘッダーフィールドのサブレジストリに追加されました：
o Header Name: Refer-Sub
Oヘッダー名：参照してください-SUB
o Compact Form: None
Oコンパクト形：なし
o Reference: RFC 4488
Oリファレンス：RFC 4488
This document also registers a new SIP option tag, "norefersub", adding it to the SIP Option Tags sub-registry in the SIP Parameters Registry. The required information for this registration, as specified in RFC 3261 [2], is:
また、このドキュメントでは、SIPパラメータレジストリ内のSIPオプションタグのサブレジストリに追加し、新しいSIPオプションタグ、「norefersub」を登録します。この登録に必要な情報、RFC 3261で指定されるように、[2]、です。
o Name: norefersub
O名：norefersub
o Description: This option tag specifies a User Agent ability of accepting a REFER request without establishing an implicit subscription (compared to the default case defined in RFC 3515 [3]).
O説明：このオプションタグは暗黙の購読を確立することなく要求をREFER（RFC 3515で定義されたデフォルトの場合に比べて[3]）を受け付けるユーザエージェントの能力を指定します。
The purpose of this SIP extension is to modify the expected behavior of the REFER-Recipient. The change in behavior is for the REFER-Recipient not to establish a dialog and not to send NOTIFY messages back to the REFER-Issuer. As such, a malicious inclusion of a "Refer-Sub" header field set to "false" reduces the processing and state requirements on the recipient. As a result, its use in a denial-of-service attack seems limited.
このSIP拡張の目的は、REFER-受信者の期待される動作を変更することです。行動の変化は、REFER-受信者のためのダイアログを確立しないと、バックREFER発行者へのNOTIFYメッセージを送信することではありません。このように、「偽」に設定「を参照してください-SUB」ヘッダフィールドの悪意のある包含は、レシピエントの処理及び状態の要件を低減します。その結果、サービス拒否攻撃におけるその使用が制限されたようです。
On the other hand, by inserting a "Refer-Sub" header field set to "false", a man-in-the-middle (MitM) can potentially exploit the mechanism for easier (than an interception) suppression of the notifications from the REFER-Receiver without the REFER-Issuer noticing it. Also, by removing a "Refer-Sub" header field set to "false", a MitM can cause the REFER-Receiver to generate notifications over the implicit dialog that otherwise had been suppressed by the REFER-Issuer.
一方、MITM（中間者）は、潜在的にからの通知の抑制（傍受より）容易にするためのメカニズムを利用することができる、「偽」に設定「を参照してください-SUB」ヘッダフィールドを挿入することによりREFER-ReceiverをREFER発行者がそれに気付かず。また、「偽」に設定する「を参照してください-SUB」ヘッダフィールドを削除することによって、のMitMは、そうでない場合はREFER発行者により抑制されたことを暗黙のダイアログ上で通知を生成するREFER-Receiverを引き起こす可能性があります。
To protect against these kinds of MitM attacks, integrity protection should be used. For example, the REFER-Issuer could use S/MIME as discussed in RFC 3261 [2] to protect against these kinds of attacks.
MITM攻撃のこれらの種類から保護するために、完全性保護を使用する必要があります。 RFC 3261で説明したように、例えば、REFER-発行者は、攻撃のこれらの種類から保護する[2] S / MIMEを使用することができます。
The SIP community would like to thank Sriram Parameswar for his ideas, originally presented in "Suppressing Refer Implicit Subscription" (October 2002), which served as the basis for this specification.
SIPコミュニティはもともと、この仕様の基礎を務めた「抑止参照してください暗黙の契約」（2002年10月）で提示、彼のアイデアをスリラムParameswarに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] 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.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[3] R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月、火花。
[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2005.
[5]ローゼンバーグ、J.、進歩、2005年10月に作品 "セッション開始プロトコル（SIP）におけるグローバルにルーティング可能なユーザエージェント（UA）のURI（GRUU）の取得と使用" を参照してください。
[6] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, January 2006.
[6] Lonnfors、M.とK.キス、進歩、2006年1月に、ワーク「プレゼンス情報データフォーマット（PIDF）にセッション開始プロトコル（SIP）ユーザエージェントの機能拡張」。
[7] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[7]、火花R.、編、Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）調教テストメッセージ"、RFC 4475、2006年5月。
Author's Address
著者のアドレス
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
oriTレヴィンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: 425-722-2225 EMail: oritl@microsoft.com
電話：425-722-2225 Eメール：oritl@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。