Network Working Group G. Camarillo
Request for Comments: 5367 Ericsson
Updates: 3265 A.B. Roach
Category: Standards Track Tekelec
O. Levin
Microsoft Corporation
October 2008
Subscriptions to Request-Contained Resource Lists
in the Session Initiation Protocol (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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a single SUBSCRIBE dialog.
この文書では、SIP内のリソースのリストにサブスクリプションを作成する方法を指定します。これは、SUBSCRIBEリクエストのボディ内のリソースのリストを含むことによって達成されます。代わりに、加入者が個別に各リソースのSUBSCRIBEリクエストを送信したのは、加入者は、リソースのリストを定義し、それをサブスクライブし、単一SUBSCRIBEダイアログを使用して、リソースの状態の変化に関する通知を取得します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. User Agent Client Procedures ....................................2
3.1. Response Handling ..........................................2
3.2. Subsequent SUBSCRIBE Requests ..............................3
4. URI-List Document Format ........................................3
5. Resource List Server Behavior ...................................4
5.1. Subsequent SUBSCRIBE Requests ..............................4
6. Providing a URI to Manipulate a Resource List ...................4
7. Example .........................................................5
8. Security Considerations .........................................6
9. IANA Considerations .............................................6
9.1. List-Management Purpose Parameter Value ....................6
9.2. recipient-list-subscribe Option-Tag ........................7
10. Acknowledgments ................................................7
11. Normative References ...........................................7
[RFC4662] specifies how to establish subscriptions to a homogeneous resource list in SIP (which is specified in [RFC3261]) and defines the procedures for getting notifications about changes in the state of the associated resources. Yet, list creation is outside the scope of [RFC4662].
[RFC4662]は（[RFC3261]で指定されている）と関連したリソースの状態の変化についての通知を取得するための手順を定義SIPにおける均質リソースリストへのサブスクリプションを確立する方法を指定します。しかし、リストの作成は、[RFC4662]の範囲外です。
This document specifies a way to create a list with a set of resources and subscribe to it using a single SIP request. This is achieved by including the list of resources (as defined in [RFC5363]) in the body of the SUBSCRIBE request.
この文書では、リソースのセットでリストを作成して、単一のSIPリクエストを使用して、それをサブスクライブする方法を指定します。これは、（[RFC5363]で定義されるように）SUBSCRIBEリクエストのボディ内のリソースのリストを含むことによって達成されます。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
A UAC (User Agent Client) that wants to create a resource list and subscribe to it using the mechanism described in this document constructs a SUBSCRIBE request with at least one body, whose disposition is type "recipient-list" as defined in [RFC5363], that contains the URI list. Additionally, the UAC MUST include the 'recipient-list-subscribe' option-tag (which is registered with the IANA in Section 9) in a Require header field. The UAC MUST build the rest of the SUBSCRIBE request following the rules in [RFC3265].
その気質[RFC5363]で定義されるようにタイプ「受信者リスト」であるUACリソースリストを作成し、少なくとも一つの体にSUBSCRIBEリクエストを構築本書で説明されたメカニズムを使用して、それを購読したい（ユーザエージェントクライアント） 、それは、URIのリストが含まれています。また、UACはRequireヘッダーフィールドに（セクション9にIANAに登録されている）、「受信者リストサブスクライブ」オプションタグを含まなければなりません。 UACは、[RFC3265]の規則を次SUBSCRIBEリクエストの残りの部分を構築する必要があります。
The UAC MUST support the "rlmi+xml" format defined in [RFC4662] and signal this by including "rlmi+xml" in the Accept header. The UAC MAY support additional formats and include them in the Accept header field of the SUBSCRIBE request.
UACは、[RFC4662]で定義された「rlmi + XML」フォーマットをサポートし、受け入れヘッダの「rlmi + XML」を含むことによって、これを合図しなければなりません。 UACは、追加のフォーマットをサポートし、SUBSCRIBEリクエストのAcceptヘッダーフィールドでそれらを含むかもしれません。
The status code in the response to the SUBSCRIBE request does not provide any information about whether or not the resource list server was able to successfully subscribe to the URIs in the URI list. The UAC obtains this information in the notifications sent by the server.
SUBSCRIBE要求に応じてステータスコードは、リソースリストサーバが正常にURIリスト内のURIに加入することができたかどうかについての情報を提供していません。 UACは、サーバから送信された通知に、この情報を取得します。
The previous sections have specified how to include a URI list in an initial SUBSCRIBE request to a resource list server in order to subscribe to the state of a set of resources. Once the subscription has been created and a dialog between the UAC and the resource list server has been established, the UAC can send subsequent SUBSCRIBE requests to, for example, extend the duration of the subscription.
前のセクションでは、リソースのセットの状態に加入するために、リソースリストサーバに要求をSUBSCRIBE初期にURIのリストを含める方法を指定しています。サブスクリプションが作成されていて、UACとリソースリストサーバ間の対話が確立されると、UACは、例えば、サブスクリプションの期間を延長するために、後続のSUBSCRIBEリクエストを送信することができます。
At this point, there are no semantics associated with resource-list bodies in subsequent SUBSCRIBE requests (although future extensions can define them). Therefore, UACs SHOULD NOT include resource-list bodies in subsequent SUBSCRIBE requests to a resource list server.
この時点で、その後のSUBSCRIBEリクエストでリソースリスト本体（将来の拡張は、それらを定義することができます）に関連した意味はありません。したがって、求めるUACは、リソースリストサーバへの以降のSUBSCRIBEリクエストでリソースリスト本体を含んではなりません。
Note that a difference between an initial SUBSCRIBE request and subsequent ones is that while the initial request is sent to the public URI of the resource list, subsequent ones are sent to the URI provided by the server when the dialog is established. Therefore, from the UAC's point of view, the resource identified by the former URI supports recipient-list bodies, while the resource identified by the latter does not support them.
初期の違いは、要求とそれに続くものは、最初の要求はリソースリストの公開URIに送信されている間、それ以降のものは、ダイアログが確立されているサーバが提供するURIに送信されていることであるSUBSCRIBEことに注意してください。後者で識別されるリソースは、それらをサポートしていませんがため、ビューのUACの視点から、旧URIで識別されるリソースは、受信者リストの体をサポートしています。
[RFC5363] mandates that each URI-list services specification, such as the subscription service defined here, specifies the default format for the recipient-list bodies used within the particular service.
[RFC5363]例えばここで定義されたサブスクリプションサービスとして各URIリストサービス仕様、義務は、特定のサービス内で使用される受信者リスト体のデフォルトのフォーマットを指定します。
The default format for the recipient-list bodies for the subscription service defined in this document is the resource list format defined in [RFC4826]. UAs (User Agents) generating recipient-list bodies MUST support this format and MAY support other formats. Resource list servers able to handle recipient-list bodies MUST support this format and MAY support other formats.
この文書で定義されたサブスクリプションサービスの受信者リストの体のためのデフォルトの形式は[RFC4826]で定義されたリソースのリスト形式です。受信者リストの体を生成するUA（ユーザエージェント）は、この形式をサポートしなければならないし、他のフォーマットをサポートするかもしれません。受信者リストの遺体を処理することができるリソースリストサーバでは、この形式をサポートしなければならないし、他のフォーマットをサポートするかもしれません。
The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resource list document provides features, such as hierarchical lists and the ability to include entries by reference relative to the XCAP root URI, that are not needed by the subscription service defined here, which only needs to transfer a flat list of URIs between a UA and the resource list server. Therefore, when using the default resource list document, UAs SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref> elements. A resource list server receiving a URI list with more information than what has just been described MAY discard all the extra information.
拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）リソースリストの文書は、このような階層リストなどの機能、およびここで定義されたサブスクリプションサービスによって必要とされていないXCAPルートURIを参照の相対でエントリを含めるする機能を提供します唯一のUAとリソースリストサーバ間のURIのフラットリストを転送する必要があります。従ってデフォルトリソースリスト文書を使用する場合、UAは、フラットリスト（すなわち、無階層リスト）を使用する必要があり、<エントリ-REF>要素を使用しないでください。ただ、すべての余分な情報を捨てるかもしれ記載されているものよりも多くの情報をURIのリストを受信するリソースリストサーバ。
Figure 1 shows an example of a flat list that follows the resource list document.
図1は、リソースリスト文書を以下のフラットリストの一例を示しています。
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <list> <entry uri="sip:bill@example.com" /> <entry uri="sip:joe@example.org" /> <entry uri="sip:ted@example.net" /> </list> </resource-lists>
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス "> <リスト> <エントリURI =" SIP：bill@example.com "/> <エントリURI = "SIP：joe@example.org"/> <エントリーのURI =" SIP： ted@example.net」/> </リスト> </資源リスト>
Figure 1: URI list
図1：URIリスト
Resource list servers that are able to receive and process SUBSCRIBE requests with a recipient-list body SHOULD include a 'recipient-list-subscribe' option-tag in a Supported header field when responding to OPTIONS requests.
OPTIONS要求に応答する際に受信して処理することができますリソースリストサーバは、サポートされているヘッダフィールド内の「受信者リスト-購読」オプションタグを含むべきで、受信者リストのボディを持つSUBSCRIBE要求。
On reception of a SUBSCRIBE request with a URI list, a resource list server that chooses to accept the "rlmi+xml" format MUST comply with [RFC4662] for creating the subscription and reporting the changes in the resources within the created dialog.
URIリストを持つSUBSCRIBEリクエストを受信すると、「rlmi + XML」形式を受け入れることを選択したリソースリストサーバは、サブスクリプションを作成し、作成したダイアログ内のリソースの変更を報告するために、[RFC4662]に準拠しなければなりません。
At this point, there are no semantics associated with resource-list bodies in subsequent SUBSCRIBE requests (although future extensions may define them). Therefore, a resource list server receiving a subsequent SUBSCRIBE request with a resource-list body, following standard SIP procedures, rejects it with a 415 (Unsupported Media Type) response.
この時点で、その後のSUBSCRIBEリクエストでリソースリスト本体（将来の拡張は、それらを定義するかもしれないが）に関連した意味はありません。したがって、標準的なSIPの手順に従ってリソースリスト本体と後続のSUBSCRIBEリクエストを受信したリソースリストサーバは、415（サポートされていないメディアタイプ）応答でそれを拒否する。
A UAC can manipulate a resource list at a resource list server. The resource list server MAY provide a URI to manipulate the resource list associated with a subscription using the Call-Info header field in the NOTIFY request that establishes the subscription. The "purpose" parameter of the Call-Info header field MUST have a value of 'list-management', which we register with the IANA in Section 9. The following is an example of such a header field.
UACは、リソースリストサーバでリソースリストを操作することができます。リソースリストサーバは、サブスクリプションを確立NOTIFYリクエストでのCall-Infoヘッダーフィールドを使用してサブスクリプションに関連付けられたリソースのリストを操作するためのURIを提供することができます。コール-Infoヘッダーフィールドの「目的」のパラメータは、以下のようなヘッダフィールドの一例である第9節でIANAに登録する「リスト管理」の値を持っていなければなりません。
Call-Info: <http://xcap.example.com/your-list.xml> ;purpose=list-management
コール情報：<http://xcap.example.com/your-list.xml>;目的=リストの管理
The lifetime of a resource list to be manipulated by the URI provided by the server is bundled to the lifetime of the subscription. That is, the resource list SHOULD be destroyed when the subscription expires or is otherwise terminated.
リソースリストの寿命は、サブスクリプションの有効期間に同梱されているサーバが提供するURIによって操作されます。これは、サブスクリプションの有効期限が切れるか、そうでない場合は終了したときに、リソースのリストが破壊されるべきです。
Section 7.1 of [RFC3265] does not list the Call-Info header field in the table of header fields that NOTIFY requests can carry. This document updates that table so that the Call-Info header field can be optionally included in NOTIFY requests.
[RFC3265]のセクション7.1は、要求が運ぶことができるNOTIFYヘッダフィールドのテーブルでのCall-Infoヘッダーフィールドは表示されません。この文書では、コール-Infoヘッダーフィールドは、オプションに含まれるNOTIFYリクエストをすることができるように、そのテーブルを更新します。
The following is an example of a SUBSCRIBE request, which carries a URI list in its body, sent by a UAC to a resource list server.
以下は、リソースリストサーバにUACによって送信され、その本体にURIリストを運ぶSUBSCRIBEリクエストの例です。
SUBSCRIBE sip:rls@example.com SIP/2.0 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL Max-Forwards: 70 To: RLS <sip:rls@example.com> From: <sip:adam@example.com>;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 1 SUBSCRIBE Contact: <sip:terminal.example.com> Event: presence Expires: 7200 Require: recipient-list-subscribe Supported: eventlist Accept: application/cpim-pidf+xml Accept: application/rlmi+xml Accept: multipart/related Accept: multipart/signed Accept: multipart/encrypted Content-Type: application/resource-lists+xml Content-Disposition: recipient-list Content-Length: 337
：<rls@example.com一口>：<SIP：アダム：70：RLSブランチ= z9hG4bKwYb6QREiCLマックス・転送し、SIP / 2.0 / TCPのterminal.example.com：rls@example.com SIP / 2.0経由：SIPをSUBSCRIBE @ example.com>;タグ= ie4hbb8tコールID：cdB34qLToC@terminal.example.comのCSeq：1連絡先をSUBSCRIBE：<SIP：terminal.example.com>イベント：存在が有効期限：7200の要求：受信者リストサブスクライブサポート： eventlist受け入れ：アプリケーション/ CPIM-PIDF + xmlのは受け入れ：アプリケーション/ rlmi + xmlの受け入れ：マルチパート/受け入れる関連：マルチパート/署名受け入れ：マルチパート/暗号化されたコンテンツタイプを：アプリケーション/リソース・リスト+ xmlのコンテンツ処分を：受信者リストをコンテンツの長さ：337
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <list> <entry uri="sip:bill@example.com" /> <entry uri="sip:joe@example.org" /> <entry uri="sip:ted@example.net" /> </list> </resource-lists>
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス "> <リスト> <エントリURI =" SIP：bill@example.com "/> <エントリURI = "SIP：joe@example.org"/> <エントリーのURI =" SIP： ted@example.net」/> </リスト> </資源リスト>
Figure 2: SUBSCRIBE request
図2：SUBSCRIBEリクエスト
The Security Considerations section of [RFC4662] discusses security issues related to resource list servers. Resource list servers accepting request-contained URI lists MUST also follow the security guidelines given in [RFC4662].
[RFC4662]のSecurity Considerations部は、リストサーバをリソースに関連するセキュリティの問題について説明します。リクエストに含まれるURIのリストを受け入れるリソースリストサーバは、[RFC4662]で与えられたセキュリティガイドラインに従わなければなりません。
"Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services" [RFC5363] discusses issues related to SIP URI-list services. Given that a resource list server sending SUBSCRIBE requests to a set of users acts as a URI-list service, implementations of resource list servers that handle request-contained URI lists MUST follow the security-related rules in [RFC5363]. These rules include opt-in lists and mandatory authentication and authorization of clients.
[RFC5363]「セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークとセキュリティの考慮事項は、」URIリストサービスをSIPに関連する問題について説明します。ユーザーの集合にSUBSCRIBEリクエストを送信リソースリストサーバはURIリストサービスとして動作していることを考えると、リクエストに含まれるURIのリストを扱うリソースリストサーバの実装は、[RFC5363]でセキュリティ関連の規則に従わなければなりません。これらのルールは、オプトインリストと必須の認証とクライアントの承認が含まれています。
The following sections describe the IANA registration of the 'list-management' value for the "purpose" parameter of the Call-Info header field and the 'recipient-list-subscribe' SIP option-tag.
次のセクションでは、コール-Infoヘッダーフィールドの「目的」パラメータと「受信者リスト-購読」SIPオプションタグのための「リスト管理」の値のIANA登録を記述する。
This document defines the 'list-management' value for the "purpose" parameter of the Call-Info header field. A reference to this RFC (in double brackets) has been added to the existing "purpose" Call-Info parameter entry in the SIP Parameters registry, which currently looks as follows:
この文書では、コール-Infoヘッダーフィールドの「目的」パラメータに「リスト管理」の値を定義します。 （二重括弧内）は、このRFCを参照するには、次のように現在に見えるSIPパラメータレジストリ内の既存の「目的」コール情報パラメータエントリに追加されました：
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Call-Info purpose Yes [RFC3261]
This document defines the SIP option tag "recipient-list-subscribe".
この文書は、SIPオプションタグ「受信者リストは、サブスクライブ」を定義します。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
次の行は、SIPパラメータレジストリの「オプションタグ」セクションに追加されました。
+--------------------------+----------------------------+-----------+
| Name | Description | Reference |
+--------------------------+----------------------------+-----------+
| recipient-list-subscribe | This option tag is used to | [RFC5367] |
| | ensure that a server can | |
| | process the recipient-list | |
| | body used in a SUBSCRIBE | |
| | request. | |
+-------------------------------------------------------+-----------+
Cullen Jennings and Jonathan Rosenberg provided useful comments on this document.
カレン・ジェニングスとジョナサンローゼンバーグはこのドキュメントの役に立つコメントを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC4662] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662]ローチ、A.B.、キャンベル、B.、およびJ.ローゼンバーグ、 "リソースリストのためのAセッション開始プロトコル（SIP）イベント通知拡張"、RFC 4662、2006年8月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]ローゼンバーグ、J.、 "リソース・リストを表すための拡張マークアップ言語（XML）フォーマット"、RFC 4826、2007年5月。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]キャマリロ、G.およびA.B.ローチ、RFC 5363、2008年10月「セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークとセキュリティの考慮事項」。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Adam Roach Tekelec 17210 Campbell Rd Ste 250 Dallas, TX 75252 USA
アダムローチTekelec 17210キャンベルRdのスイート250、ダラス、TX 75252 USA
EMail: Adam.Roach@tekelec.com
メールアドレス：Adam.Roach@tekelec.com
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052
oriTレヴィンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: oritl@microsoft.com
メールアドレス：oritl@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。