[要約] RFC 5344は、プレゼンスとインスタントメッセージングのピアリングの使用例に関する情報を提供する。その目的は、異なるドメイン間でのプレゼンス情報とインスタントメッセージングの相互運用性を向上させることである。
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).
このドキュメントでは、2つ以上のサービスプロバイダー間の非VOIP（Voice over IP）サービスの覗き見のいくつかのユースケースについて説明します。これらのサービスプロバイダーは、自分自身の間にピアリング関係を作成するため、ユーザーが他のサービスプロバイダーネットワークでユーザーと協力できるようになります。このドキュメントのターゲットは、非VOIPベースのコラボレーションサービスに存在感、特にインスタントメッセージング（IM）を提供するドメイン間のピアリングの要件を促進することです。
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.
Peer Network AとPeer Network B.ユーザーAlice@example.com（Peer Network Aでホスト）、2つのピアネットワーク、ユーザーbob@example.net（ピアネットワークBでホスト）を購読し、彼の存在情報を取得すると仮定します。そうするために、alice@example.comはexample.netに直接接続し、Bobの存在情報を購読することができます。ただし、ピアネットワークBは、ユーザーがユーザーまたはピアネットワークBが信頼する他のピアネットワークから来ている場合にのみ、サブスクリプションを受け入れ、IMSをルーティングします。
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.
現実には、ピアネットワークAがピアネットワークBに接続し、ピアネットワーク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].
これは、アリスがピアネットワークB [9] [3]のユーザーのリストを表すユニフォームリソース識別子（URI）[8]をサブスクライブするこの場合を除き、単純なドメイン間サブスクリプションユースケースに似ています。
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 Ad -Hoc Group-短命で、通常、アリスが行っている活動のコンテキストで作成されるリスト。アドホックグループは、アリスまたはいくつかのアプリケーションによって作成される場合があります。典型的な例は、会議やゲームにアリスに参加する人々のリストかもしれません。
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.
あるピアネットワークの多くのユーザーが別のピアネットワークでプレゼンテーションを監視している場合、あるピアネットワークの多くのウォッチャー[6]が他のピアネットワークで同じユーザーを購読する可能性があります。ただし、ユーザーがさまざまなウォッチャーに異なる存在ドキュメントを提供できるようにするプライバシーの制約により、各ピアネットワークは監視されたプレセンスドキュメントの複数のコピーを送信する必要があります。ピアネットワーク間に複数のコピーを送信する必要性は非常に非効率的であり、ピアネットワーク間で冗長トラフィックを引き起こします。
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].
ピアネットワーク間で監視されているユーザーのプライバシーポリシーを共有する代わりに、プレゼンスドキュメントのさまざまなコピーをWatchersドキュメントのリストで送信することもできます。たとえば、1つのピアネットワークに、プレゼンテーションの場所を確認する可能性のあるウォッチャーのセットと、位置情報が表示されない同じピアネットワークの別のユーザーセットがある場合、2つのプレゼンスドキュメントが送信されます。それを受け取るべきウォッチャーのリスト付き。1つのプレゼンスドキュメントには位置情報が含まれ、それを見る可能性のあるユーザーのリストに関連付けられ、もう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.
このユースケースでは、1つのピアネットワークのユーザーが、別のピアネットワーク上のユーザーにポケットベルモード[7] IMを送信します。
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.
このユースケースでは、1つのピアネットワークのユーザーが、別のピアネットワークのユーザーとのメッセージセッションリレープロトコル（MSRP）[10]セッションを作成します。
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:
このドキュメントの範囲外のVoIPセッションに加えて、存在感とIMのみがRFCとして批准されています。存在感とIMに加えて、標準化されている、または既存の標準への最小限の拡張機能を使用して実装される可能性のある他の多くのサービスがあります。これらには以下が含まれます：
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-Way Chat-複数のピアネットワークのユーザーを含むマルチ参加者のテキストチャットを有効にします。詳細については、[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 ファイル転送 - あるピアネットワーク内のユーザーから別のピアネットワークのユーザーにファイルを送信します。詳細については、[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]で定義されているフェデレーションにより、複数のピアネットワーク間でピアリングが可能になります。連合は、ピアネットワークのハブを提供する中央サービスによって実施される場合があります。あるいは、ピアネットワークはピアツーピアの方法で互いに接続する場合があります。このハブタイプの連邦が提供する最も重要なサービスの1つは、各ピアリングネットワークが他のピアリングネットワークを安全に識別できるようにする許可された相互接続です。提供される可能性のあるその他のサービスには、n-wayチャットサーバー、合法的な傍受、ロギングなどが含まれます。このハブタイプの連合は、「クリアリングハウス」としても知られています。
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:
ピアネットワークAピアAピアネットワークBを使用すると、各ピアネットワークの管理者が検証するためのメカニズムが必要なセキュリティの問題がいくつかあります。
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.
ジョナサン・ローゼンバーグ、ジョン・ピーターソン、ロハン・マヒー、ジェイソン・リビングウッド、アレクサンダー・メイロファー、ジョセフ・サロウィー、ヘンリー・シン・レイヒ、モハメド・ブーカディールの貴重な意見に感謝します。
[1] Malas, D. and D. Meyer, "SPEERMINT Terminology", Work in Progress, February 2008.
[1] Malas、D。およびD. Meyer、「Speermint用語」、2008年2月に進行中の作業。
[2] Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", Work in Progress, May 2008.
[2] Uzelac、A。およびY. Lee、「Voip Sip Peering Use Case」、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] Camarillo、G。およびA. Roach、「セッション開始プロトコル（SIP）URI-Listサービスのフレームワークとセキュリティ上の考慮事項」、2007年11月、進行中の作業。
[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] Niemi、A.、Garcia-Martin、M.、およびG. Sandbakken、「メッセージセッションリレープロトコル（MSRP）を使用したマルチパーティインスタントメッセージ（IM）セッション」、2008年2月、Work in Progress。
[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] Garcia-Martin、M.、Isomaki、M.、Camarillo、G.、Loreto、S。、およびP. Kyzivat、「セッション説明プロトコル（SDP）はファイル転送を有効にするためのオファー/回答メカニズム」、進行中の作業、5月2008年。
[6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[6] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、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] Campbell、B.、Ed。、Rosenberg、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Roach、A.、Campbell、B。、およびJ. Rosenberg、「セッション開始プロトコル（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] Campbell、B.、ed。、Mahy、R.、ed。、およびC. Jennings、ed。、「The Message Session Relay Protocol（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] Rosenberg、J.、Donovan、S。、およびK. McMurry。「ビュー共有でフェデレーションプレゼンスを最適化する」、2008年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Avshalom Houri IBM 3 Pekris Street Science Park Rehovot, Israel
Avshalom Houri ibm 3 Pekris Street Science Park Rehovot、イスラエル
EMail: avshalom@il.ibm.com
Edwin Aoki AOL LLC 401 Ellis Street Mountain View, CA 94043 USA
Edwin Aoki AOL LLC 401 Ellis Street Mountain View、CA 94043 USA
EMail: aoki@aol.net
Sriram Parameswar Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Sriram Parameswar Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
EMail: Sriram.Parameswar@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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への情報をお問い合わせください。