Network Working Group A. Houri
Request for Comments: 5344 IBM
Category: Informational E. Aoki
AOL LLC
S. Parameswar
Microsoft Corporation
October 2008
Presence and Instant Messaging Peering Use Cases
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers. These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM).
この文書では、二つ以上のサービスプロバイダとの間の非のVoIP（ボイスオーバーIP）サービスのピアリングのいくつかのユースケースを説明します。これらのサービスプロバイダは、このように、他のサービスプロバイダーのネットワーク上のユーザーと協力してそのユーザーを有効にする、自分自身とのピアリング関係を作成します。このドキュメントの目標は、特定の、インスタントメッセージング（IM）で、存在と非のVoIPベースのコラボレーションサービスを提供し、ドメイン間のピアリングのための要件を駆動することです。
Table of Contents
目次
1. Introduction ....................................................2
2. Use Cases .......................................................2
2.1. Simple Interdomain Subscription ............................2
2.2. List Based Interdomain Subscription ........................3
2.3. Authorization Migration ....................................3
2.4. Pager Mode IM ..............................................4
2.5. Session Based IM ...........................................4
2.6. Other Services .............................................4
2.7. Federation and Clearing House ..............................5
3. Security Considerations .........................................5
4. Acknowledgments .................................................6
5. Informative References ..........................................6
This document uses the terminology as defined in [1] unless otherwise stated.
[1]で定義されるように、特に明記しない限り、この文書は、用語を使用します。
Real Time Collaboration (RTC) services have become as prevalent and essential for users on the Internet as email. While RTC services can be implemented directly by users in a point-to-point fashion, they are often provided for, or on behalf of, a Peer Network of users within an administrative domain. As the use of these services grows, users increasingly have the need to communicate with users not only within their own Peer Network but with those in other Peer Networks as well (similar to the old Public Switched Telephony Network (PSTN) that enabled global reachability). In practice, each Peer Network is controlled by some domain, and so there is a need to provide for easier establishment of connectivity between Peer Networks and for the management of the relationships between the Peer Networks. This document describes a set of use cases that describe how peering between Peer Networks may be used in non-VoIP RTC services. The use cases are intended to help in identifying and capturing requirements that will guide and then enable a secure and easier peering between Peer Networks that provide non-VoIP RTC services. The use cases for the VoIP RTC services are described in [2].
リアルタイムコラボレーション（RTC）サービスは、電子メールなど、インターネット上のユーザーのためとして普及して不可欠になってきました。 RTCサービスは、ポイントツーポイント方式でユーザーが直接実装することができますが、それらは多くの場合のために、または管理ドメイン内のユーザーのピアネットワークに代わって提供されています。これらのサービスの利用が増えるにつれ、ユーザーがますます自分のピアネットワーク内ではなく、他のピア・ネットワークにおけるものとするだけでなく、ユーザーと通信する必要があります（旧公共と同様にグローバルな到達可能性を有効に電話網（PSTN）） 。実際には、各ピアネットワークは、いくつかのドメインによって制御され、そのピア・ネットワーク間やピア・ネットワークの間の関係を管理するための接続を簡単に確立するために提供する必要がありますさ。この文書では、ピア・ネットワーク間のピアリングは、非VoIPのRTCサービスで使用することができる方法を説明ユースケースのセットを記述します。ユースケースを案内し、その後、非のVoIP RTCサービスを提供するピア・ネットワークの間で安全かつ簡単にピアリングを可能にする要件を特定し、キャプチャを支援することを意図しています。 VoIPのRTCサービスのためのユースケースは、[2]で説明されています。
Note that this document does not define requirements for a new protocol or for protocol extensions. It captures the way that presence and Instant Messaging are currently used within enterprises and operator domains.
このドキュメントは新しいプロトコルまたはプロトコル拡張のための要件を定義していないことに注意してください。これは、プレゼンスとインスタントメッセージングは、現在、企業やオペレータのドメイン内で使用されている方法をキャプチャします。
Assume two Peer Networks, Peer Network A and Peer Network B. User Alice@example.com (hosted in Peer Network A) wants to subscribe to user Bob@example.net (hosted in Peer Network B) and get his presence information. In order to do so, Alice@example.com could connect directly to example.net and subscribe to Bob's presence information. However, Peer Network B is willing to accept subscriptions and route IMs only when they are coming from its users or from other Peer Networks that Peer Network B trusts.
2つのピアネットワークを想定し、ネットワークAをピアとネットワークB.ユーザーAlice@example.com（ピアネットワークAでホストされている）は、ユーザBob@example.net（ピアネットワークBにホストされている）に加入し、彼のプレゼンス情報を取得したいピア。そうするためには、Alice@example.comはexample.netのとボブのプレゼンス情報を購読する直接接続することができます。しかし、ネットワークBは、サブスクリプションと、彼らはそのユーザーまたはネットワークB信託ピア他のピア・ネットワークから来ているだけルートのIM受け入れる意志があるピア。
In reality, what will happen is Peer Network A will connect to Peer Network B and send Alice's subscription to Bob via Peer Network B. When Peer Network B has new information on Bob, it will send notifications to Peer Network A, which will pass them to Alice.
ピアネットワークBがボブに新しい情報を持っている場合は実際には、それがネットワークAをピアに通知を送信しますネットワークBをピアに接続し、ピアネットワークBを介してボブにアリスのサブスクリプションを送信するネットワークAをピアされた何が起こるか、それはそれらを通過しますアリスへ。
This is similar to the simple interdomain subscription use case, except in this case Alice subscribes to a Uniform Resource Identifier (URI) [8] that represents a list of users in Peer Network B [9] [3].
これは、[3]この場合、アリスは、ユニフォームリソース識別子（URI）に加入を除き、単純なドメイン間サブスクリプション使用の場合と同様である[8]ピアネットワークB内のユーザーのリストを表している[9]。
There are several types of lists that Alice may subscribe to:
アリスはに加入することができるリストのいくつかの種類があります。
o Personal group - a list that is created and maintained by Alice and includes Alice's watch list.
O個人的なグループ - 作成および維持アリスでアリスのウォッチリストが含まれているリスト。
o Public group - a list that is created and maintained by an administrator. Public groups usually contain a list of specific people that have some common characteristic, e.g., support group of a company.
O公共のグループ - 管理者によって作成され、維持されているリスト。公開グループは、通常、会社のいくつかの共通の特性、例えば、サポートグループを持っている特定の人のリストが含まれています。
o Ad-hoc group - a list that is short lived and is usually created in the context of some activity that Alice is doing. An ad-hoc group may be created by Alice or by some application. Typical examples may be the list of people that participate with Alice in a conference or a game.
Oアドホックグループ - 短命であり、通常はアリスがやっている一部のアクティビティのコンテキストで作成されたリスト。アドホックグループは、アリスによってまたはいくつかのアプリケーションによって作成することができます。典型的な例は、会議やゲームにアリスとの参加者のリストとすることが可能です。
If many users from one Peer Network watch presentities [6] in
another Peer Network, it may be possible that many watchers [6]
from one Peer Network will subscribe to the same user in the other
Peer Network. However, due to privacy constraints that enable a
user to provide different presence documents to different
watchers, each Peer Network will have to send multiple copies of
the watched-presence document. The need to send multiple copies
between the Peer Networks is very inefficient and causes redundant
traffic between the Peer Networks.
In order to make the subscription between Peer Networks more efficient there needs to be a way to enable Peer Networks to agree to share privacy information between them. This will enable sending a single copy (the full copy) of the presence document of the watched user and letting the receiving Peer Network be responsible for sending the right values to the right watchers according to the delegated privacy policies of the watched users.
ピア・ネットワーク間のサブスクリプションをより効率的にするために、それらの間のプライバシー情報を共有することに同意するピアネットワークを有効にする方法が必要です。これは見たユーザーのプレゼンス文書の単一のコピー（完全コピー）を送信側と受信側のピアネットワークを見たユーザーの委任プライバシーポリシーに従って右ウォッチャーに正しい値を送信するための責任を負いせることが可能になります。
Instead of sharing the watched user's privacy policies between the Peer Networks, it is also possible to send different copies of the presence document with a list of the watchers the presence document is intended for. For example, if there is a set of watchers in one Peer Network that may see the location of the presentity and another set of users in the same Peer Network that may not see the location information, two presence documents will be sent--each associated with a list of watchers that should receive it. One presence document will contain the location information and will be associated with a list of users that may see it, and the other presence document will not contain the location information and will be associated with a list of users that may not see the location information. See [11].
ピア・ネットワーク間の注目ユーザーのプライバシーポリシーを共有するのではなく、プレゼンス文書がために意図されウォッチャーのリストに存在する文書の異なるコピーを送信することも可能です。プレゼンティティの位置と位置情報が表示されないことがあり、同じピアネットワーク内のユーザーの別のセットを見ることができる1つのピアネットワークにおけるウォッチャーのセットがある場合、例えば、二つのプレゼンスドキュメントが送信されます - それぞれが関連しますそれを受けるべきウォッチャーのリストを。一のプレゼンス文書は、位置情報を含むであろうし、それを見ることができるユーザのリストに関連付けされ、他のプレゼンス文書は、位置情報が含まれず、位置情報が表示されないことがあり、ユーザーのリストに関連付けられます。 [11]を参照してください。
In this use case, a user from one Peer Network sends a pager mode
[7] IM to a user on another Peer Network.
In this use case, a user from one Peer Network creates a Message
Session Relay Protocol (MSRP) [10] session with a user from
another Peer Network.
In addition to VoIP sessions, which are out of scope for this
document, only presence and IM have been ratified as RFCs. In
addition to presence and IM, there are many other services that
are being standardized or that may be implemented using minimal
extensions to existing standards. These include:
o N-way chat - enable a multi-participant textual chat that will include users from multiple Peer Networks. See [4] for more details.
O Nウェイチャット - 複数のピア・ネットワークからのユーザーが含まれるマルチ参加者テキストチャットを可能にします。詳細については、[4]を参照してください。
o File transfer - send files from a user in one Peer Network to a user in another Peer Network. See [5] for more details.
Oファイル転送 - 別のピアネットワーク内のユーザーに1つのピアネットワークのユーザーからファイルを送信します。詳細については、[5]を参照してください。
o Document sharing - sharing and editing a document between users in different Peer Networks.
共有と異なるピア・ネットワークにおけるユーザ間で文書を編集する - ドキュメントの共有をO。
Note: Document sharing is mentioned in this document only for completeness of use cases. It is not being standardized by the IETF and will not be included in the requirements document that will result from this document.
注意：ドキュメントの共有のみの使用例完全を期すために、この文書に記載されています。これは、IETFによって標準化されていないと、この文書からなります要件文書には含まれません。
The list above is of course not exhaustive, as new developments in the world of non-VoIP RTC will surface new services. Enabling peering between networks for some of the services will create a basis for enabling peering for future services also.
非VoIPのRTCの世界に新たな展開が新たなサービスを表面化するよう上記のリストには、もちろん網羅しているわけではありません。サービスの一部のためのネットワーク間のピアリングを有効にすると、将来のサービスのためにピアリング有効にするための基礎を作成します。
A federation as defined in [1] enables peering between multiple Peer Networks. A federation may be implemented by means of a central service providing a hub for the Peer Networks or, alternatively, Peer Networks may connect to each other in a peer-to-peer fashion. One of the most important services that this hub type of federation should provide is authorized interconnection that enables each Peering Network to securely identify other Peering Networks. Other services that might be provided include an N-way chat server, lawful interception, logging, and more. This hub type of federation is also known as a "Clearing House".
[1]複数のピアネットワーク間のピアリング可能で定義されているフェデレーション。フェデレーションは、ピアネットワークは、ピアツーピア方式で互いに接続することができる、あるいは、ピアネットワークのハブを提供中央サービスによって実現てもよいです。提供しなければならないフェデレーションのこのハブタイプがしっかりと他のピアリング・ネットワークを識別するために、各ピアリング・ネットワークを可能に相互接続を許可されている最も重要なサービスの一つ。提供される可能性がありますその他のサービスには、Nウェイチャットサーバ、合法的傍受、ログ記録、およびそれ以上を含みます。フェデレーションのこのハブタイプは「クリアリングハウス」として知られています。
As non-VoIP services are usually text-based and consume less bandwidth, they may benefit from having a central service that will do central services such as logging for them. For example, instead of requiring each Peer Network to log all messages that are being sent to the other Peer-Network, this service can be done by the Clearing House.
非VoIPサービスは、通常はテキストベースであり、少ない帯域幅を消費したように、彼らは、そのような彼らのためにログインするように、中央のサービスを行います中央サービスを持っていることから利益を得ることができます。たとえば、代わりに他のピア・ネットワークに送信されているすべてのメッセージをログに記録する各ピアネットワークを必要とするのは、このサービスは、クリアリングハウスで行うことができます。
When Peer Network A peers with Peer Network B, there are several security issues for which the administrator of each Peer Network will need mechanisms to verify:
ピアネットワークBとネットワークAピアピアする場合、それぞれの管理者は、ネットワークを検証する仕組みが必要になりますピアいるいくつかのセキュリティ問題があります。
o All communication channels between Peer Networks and between each Peer Network and the Clearing House have their authenticity and confidentiality protected.
ピアネットワークの間で、各ピアネットワークとクリアリングハウスとの間にOすべての通信チャネルは、その信憑性と機密性を保護しています。
o The other Peer Network is really the Peering Network that it claims to be.
O他のピアネットワークは、それがあることを主張することは本当にピアリング・ネットワークです。
o The other Peer Network is secure and trustworthy, such that information that is passed to it will not reach a third party. This includes information about specific users as well as information about the authorization policies associated with user information.
O他のピアネットワークは、それに渡された情報が第三者に到達しないように、安全で信頼できます。これは、特定のユーザーだけでなく、ユーザー情報に関連付けられた認証ポリシーに関する情報についての情報を含んでいます。
o The other Peer Network is secure and trustworthy, such that it will not modify or falsify data that it presents to its users except as required by the authorization policy provided.
他のピアネットワークoを、安全で信頼できる、それが提供する承認ポリシーによって要求される場合を除き、そのユーザーに提示するデータを変更したり、改ざんしないようなものです。
o If there is a third party (e.g., a Clearing House) involved in the connection between the two Peering Networks that element is also secure.
第三者がある場合はO（例えば、クリアリングハウス）の要素も安全である2ピアリング・ネットワーク間の接続に関わります。
The same issues of security are even more important from the point of view of the users of the Peer Networks. Users will be concerned about how their privacy is being adhered to when their presence information is sent to the other Peer Network. Users today are concerned about providing their email address to a third party when they register to a domain; presence contains much more sensitive information, and the concern of users here will be even greater.
セキュリティの同じ問題がさらに重要ピア・ネットワークの利用者の視点からです。ユーザーは、プライバシーが自分のプレゼンス情報を他のピアネットワークに送信されたときに接着されているかを心配になります。ユーザーは本日、彼らがドメインに登録したときに第三者に自分のメールアドレスを提供する懸念があります。存在は、より多くの機密情報が含まれており、ここでユーザーの関心はさらに大きくなります。
The privacy issue is even harder when we take into account that, in order to enable scalable peering between big Peer Networks, there are some optimizations that may require migration of the privacy definitions of users between Peer Network (see Section 2.3). We can imagine the fiasco that would ensue if a user of one Peer Network were able to see the privacy information and learn he/she is listed in the block list of a close friend.
我々は（2.3節を参照してください）大きなピア・ネットワーク間のスケーラブルなピアリングを有効にするために、ピアネットワーク間のユーザーのプライバシーの定義の移行を必要とするかもしれないいくつかの最適化がある、ということを考慮に入れたときにプライバシーの問題はさらに困難です。私たちは、1つのピアネットワークのユーザは、プライバシー情報を参照し、彼/彼女は親友のブロックリストに記載されて学ぶことができた場合の結果として起きるでしょう失態を想像することができます。
This document discusses use cases for peering between Peer Networks. It is out of the scope of this document to provide solutions for security. Nevertheless, it is obvious that the protocols that will enable the use cases described here will have to provide for the security considerations also described here.
この文書では、ピア・ネットワーク間のピアリングのためのユースケースについて説明します。これは、セキュリティのためのソリューションを提供するために、この文書の範囲外です。それにもかかわらず、ここで説明するユースケースを可能にするプロトコルはまた、ここで説明するセキュリティ上の配慮のために提供しなければならないことは明らかです。
We would like to thank Jonathan Rosenberg, Jon Peterson, Rohan Mahy, Jason Livingood, Alexander Mayrhofer, Joseph Salowey, Henry Sinnreich, and Mohamed Boucadir for their valuable input.
私たちは、彼らの貴重な入力のためのジョナサン・ローゼンバーグ、ジョン・ピーターソン、ロハンマーイ、ジェイソンLivingood、アレクサンダーMayrhofer、ジョセフSalowey、ヘンリーSinnreich、およびモハメドBoucadirに感謝したいと思います。
[1] Malas, D. and D. Meyer, "SPEERMINT Terminology", Work in Progress, February 2008.
[1]マラス、D.とD.マイヤー、 "SPEERMINT用語"、進歩、2008年2月に作業。
[2] Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", Work in Progress, May 2008.
[2] Uzelac、A.、およびY.リー、 "VoIPのSIPピアリングユースケース"、進歩、2008年5月での作業。
[3] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", Work in Progress, November 2007.
[3]、進歩、2007年11月に作業カマリロ、G.およびA.ローチ、「セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークおよびセキュリティに関する注意事項」を。
[4] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP)", Work in Progress, February 2008.
[4]ニエミ、A.、ガルシア・マーチン、M.、およびG. Sandbakken、 "メッセージセッションリレープロトコル（MSRP）を使用してマルチパーティインスタントメッセージ（IM）セッション"、進歩、2008年2月に作業。
[5] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", Work in Progress, May 2008.
[5]ガルシア - マーチン、M.、Isomaki、M.、カマリロ、G.、ロレート、S.、およびP. Kyzivat、 "ファイル転送を可能にするセッション記述プロトコル（SDP）オファー/アンサーメカニズム" で働きます進歩、2008年5月。
[6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[6日目、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[7] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[7]キャンベル、B.、編。、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[8]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[9] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[9]ローチ、A.、キャンベル、B.、およびJ.ローゼンバーグ、 "リソースリストのAのセッション開始プロトコル（SIP）イベント通知拡張"、RFC 4662、2006年8月を。
[10] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[10]キャンベル、B.、エド。、マーイ、R.、エド。、およびC.ジェニングス、エド。、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年9月。
[11] Rosenberg, J., Donovan, S., and K. McMurry. "Optimizing Federated Presence with View Sharing", Work in Progress, July 2008.
[11]ローゼンバーグ、J.、ドノバン、S.、およびK.マクマリー。 、進歩、2008年7月にワーク「ビューの共有と連携プレゼンスの最適化」。
Authors' Addresses
著者のアドレス
Avshalom Houri IBM 3 Pekris Street Science Park Rehovot, Israel
AvshalomフーリーIBM 3 Pekrisストリートサイエンスパークレホヴォト、イスラエル
EMail: avshalom@il.ibm.com
メールアドレス：avshalom@il.ibm.com
Edwin Aoki AOL LLC 401 Ellis Street Mountain View, CA 94043 USA
エドウィン・青木AOL LLC 401エリスストリートマウンテンビュー、CA 94043 USA
EMail: aoki@aol.net
メールアドレス：aoki@aol.net
Sriram Parameswar Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
98052 USA OFスリラムParameswarマイクロソフト社1つのマイクロソフト道、レドモンド、
EMail: Sriram.Parameswar@microsoft.com
メールアドレス：Sriram.Parameswar@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に情報を記述してください。