[要約] RFC 4488は、SIP REFERメソッドの暗黙的な購読の抑制に関する規格です。その目的は、REFERメソッドの乱用を防ぎ、ユーザーのプライバシーとネットワークの負荷を軽減することです。
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
セッション開始プロトコル（SIP）の抑制メソッド暗黙のサブスクリプション
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).
Copyright（c）The Internet Society（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）参照拡張機能は、紹介が要求するトランザクションを実行する際にレシーバーのステータスに関する紹介要求を送信するために使用される通常の短命のイベントサブスクリプションを自動的に確立します。これらの通知は、すべての場合に必要ではありません。この仕様は、参照要求に含まれる可能性のある新しい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.
参照仕様[3]は、すべての紹介がrefer-Issuerとrefer-recipientの間に暗黙的なサブスクリプションを作成することを指定します。
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ヘッダーフィールドを定義します。「リファレンスサブ」は、紹介トランザクション内でのみ意味があります。このヘッダーフィールドは、「false」に設定された場合、参照イッサーが参照受信者が暗黙的なサブスクリプションと結果のダイアログを確立しないことを要求することを指定します。
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」を定義します。このタグは、サポートされているヘッダーフィールドに含まれている場合、ユーザーエージェント（UA）が、参照レシピエントとして機能するときに暗黙のサブスクリプションを作成せずに紹介要求を受け入れることができることを示します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
To simplify discussions of the REFER method and its extensions, the three terms below are being used throughout the document:
参照方法とその拡張機能の議論を簡素化するために、以下の3つの用語はドキュメント全体で使用されています。
o REFER-Issuer: the UA issuing the REFER request
o Refer-Issuer：referied requersリクエストを発行するUA
o REFER-Recipient: the UA receiving the REFER request
o Refer-Recipient：referime requertを受信しているUA
o REFER-Target: the UA designated in the Refer-To Uniform Resource Identifier (URI)
o 参照標的：紹介するユニフォームリソース識別子（URI）に指定されたUA
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-IssuerとRefer-Recipientの間に暗黙のサブスクリプションを作成することを義務付けています。このサブスクリプションの結果、少なくとも1つの通知がrefer-RecipientからRefer-Issuerへの送信されます。refer-Recipientは、このNotifyを使用して暗黙のサブスクリプションをキャンセルすることを選択できます。Refer-Issuerは、最初の通知を受け取った後、明示的なサブスクライブ（有効期限：0）でこの暗黙のサブスクリプションをキャンセルすることを選択できます。
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 REFER-Issuer explicitly specifies that forking not occur, the requirement that an implicit subscription be established is unnecessary.
暗黙のサブスクリプションと初期通知を要求する目的の1つは、参照要求が分岐し、参照イッサーがフォークされた紹介の結果として確立される可能性のある複数のダイアログを見る方法を必要とする状況を可能にすることです。これは、購読[4]リクエストのフォークを処理するために使用されるのと同じアプローチです。Refer-Issuerがフォーキングが発生しないことを明示的に指定している場合、暗黙のサブスクリプションが確立されるという要件は不要です。
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のもう1つの目的は、Refer-Recipientでの紹介から生じるSIPトランザクションの進捗状況を参照権を通知することです。Refer-IssuerがRefer-IssuerがRefer-Recipientでダイアログイベントパッケージの明示的なサブスクリプションを持っている場合など、リクエストされた操作の進捗状況を紹介する操作の進捗状況をすでに認識している場合、紹介は、不要なネットワークオーバーヘッドを作成できます。
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).
このドキュメントでは、新しいSIPヘッダーフィールド「リファレンスサブ」を定義します。このヘッダーフィールドは意味があり、参照要求と対応する2xx応答のみで使用できます。「false」に設定されたこのヘッダーフィールドは、Refer-Issuerが参照受信者が暗黙のサブスクリプションと結果のダイアログを確立しないことを要求することを指定します。この拡張機能を使用する場合、参照はターゲット更新要求のままであることに注意してください（デフォルトの場合のように - 拡張機能が使用されていない場合）。
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がinv opt reg msgができるヘッダーフィールド
Refer-Sub R, 2xx - - - - - - -
Header field where SUB NOT REF INF UPD PRA PUB
sub not not ref ref inf upd pra pub
Refer-Sub 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
where the syntax of generic-param is defined in [2].
ジェネリックパラムの構文は[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.
「false」に設定された「リファレンスサブ」ヘッダーフィールドは、refer-Issuerが参照リクエストがフォークされないことを確認できる場合にのみ、参照イッサーが使用できます。
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-Recipientが拡張機能をサポートし、暗黙的なサブスクリプションを確立せずに紹介トランザクションを処理することをいとわない場合、参照イッサーへの2XX応答で「false」に設定された「リファレンス」ヘッダーフィールドを挿入する必要があります。この場合、暗黙のサブスクリプションは作成されません。したがって、この参照が既存のダイアログ外で発行された場合、新しいダイアログは作成されません。
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-Issuerが「false」に設定された「リファレンスサブ」ヘッダーフィールドを挿入しますが、参照受信者は提案を許可していません（つまり、「リファレンスサブ」ヘッダーフィールドは含まれていないか、「」が含まれます。リファレンスサブ「ヘッダーフィールドは、2xx応答で「true」に設定されています）、デフォルトの場合のように暗黙のサブスクリプションが作成されます。
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」も定義されています。このタグは、サポートされているヘッダーフィールドに含まれている場合、ユーザーエージェント（UA）が参照レシピエントとして機能するときに暗黙のサブスクリプションを作成せずに紹介要求を受け入れることができることを指定します。
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-Issuerは、リクエストまたは応答を開始するダイアログのサポートされているヘッダーフィールドにオプションタグの存在からの参照レシピエントの機能を知ることができます。能力を学習する別の方法は、[6]で定義されているような存在を使用することです。ただし、参照受信者の機能が不明な場合は、「NoreferSub」タグを使用して要求ヘッダーフィールドを使用することは推奨されません。これは、refer-Recipientが拡張機能をサポートしていない場合、通常の紹介に戻るために、紹介者は新しい紹介トランザクションを発行する必要があるため、追加のラウンドトリップが発生する必要があります。。
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.
[2]のセクション8.2.2.3で説明されているように、参照受信者は、この拡張機能をサポートしない限り、420（悪い拡張）応答を備えたNorefersubヘッダーフィールドを含む紹介要求を拒否します。必要な注意：norefersubには、リファレンスサブ：falseヘッダーフィールドが存在する可能性があります。
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.
参照仕様により、既存のダイアログの外部で送信される紹介要求を分岐する可能性があります。さらに、プロキシは未知のメソッドタイプを分岐する場合があります。フォーキングが発生した場合、「参照サブ」を含む参照の送信者は、フォーキングプロキシによって単一の2xx応答のみが転送されるため、認識されません。その結果、責任は「参照」の発行者であり、フォーキングが生じないことを確認するために。
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.
指定されたリクエスト-URIへの紹介要求がフォークする可能性がある場合、Refer-Issuerには「リファレンスサブ」ヘッダーフィールドを含めるべきではありません。紹介者は、参照要求がフォークされないようにするために標準化されたメカニズムを使用する必要があります。他のメカニズムがない場合、参照要求のリクエスト-RIには、[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.
暗黙のサブスクリプションを抑制する参照の例を以下に示します。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
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ヘッダーフィールド「リファレンスサブ」を登録します。このヘッダーフィールドは、RFC 3515 [3]で定義されている参照要求と対応する応答にとってのみ意味があります。以下の情報は、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: o Name: norefersub
このドキュメントは、新しいSIPオプションタグ「NoreferSub」を登録し、SIPパラメータレジストリのSIPオプションタグサブレジストリに追加します。RFC 3261 [2]で指定されているように、この登録に必要な情報は次のとおりです。
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 説明：このオプションタグは、暗黙のサブスクリプションを確立せずに参照要求を受け入れるユーザーエージェントの能力を指定します（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拡張の目的は、参照受信者の予想される動作を変更することです。行動の変更は、紹介者がダイアログを確立しないことであり、通知メッセージを参照イッサーに送り返さないことです。そのため、「false」に設定された「リファレンスサブ」ヘッダーフィールドを悪意のある包含により、受信者の処理と状態の要件が減少します。その結果、サービス拒否攻撃での使用は限られているようです。
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.
一方、「false」に設定された「リファレンスサブ」ヘッダーフィールドを挿入することにより、中間者（MITM）は、メカニズムを潜在的に（インターセプトよりも）通知の通知の抑制を容易にするために潜在的に活用できます。refer-Issuerがそれに気付かないrefer-Receiver。また、「false」に設定された「リファレンスサブ」ヘッダーフィールドを削除することにより、MITMにより、Refer-Receiverは、それ以外の場合はRefer-Issuerによって抑制された暗黙のダイアログ上の通知を生成する可能性があります。
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攻撃から保護するには、整合性保護を使用する必要があります。たとえば、Refer-Issuerは、RFC 3261 [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月）である（2002年10月）、この仕様の基礎となった「暗黙のサブスクリプション」（2002年10月）で提示された彼のアイデアについて、Sriram Parameswarに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[3] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach、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] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェント（UA）URIS（GRUU）を取得および使用している」、2005年10月、進行中の作業。
[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。and K. Kiss、「セッション開始プロトコル（SIP）ユーザーエージェント機能存在情報データ形式（PIDF）への拡張機能」、2006年1月、進行中の作業。
[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] Sparks、R.、ed。、Hawrylyshen、A.、Johnston、A.、Rosenberg、J。、およびH. Schulzrinne、「セッション開始プロトコル（SIP）拷問テストメッセージ」、RFC 4475、2006年5月。
Author's Address
著者の連絡先
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Orit Levin Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
Phone: 425-722-2225 EMail: oritl@microsoft.com
電話：425-722-2225メール：oritl@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。