Network Working Group A. Houri
Request for Comments: 5344 IBM
Category: Informational E. Aoki
AOL LLC
S. Parameswar
Microsoft Corporation
October 2008
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语音）服务对等的几个用例。这些服务提供商在他们之间创建对等关系，从而使他们的用户能够与其他服务提供商网络上的用户协作。本文档的目标是推动提供基于非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
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服务的对等网络之间的安全和更容易的对等。[2]中描述了VoIP RTC服务的用例。
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.
假设有两个对等网络，对等网络A和对等网络B。用户Alice@example.com（托管在对等网络A中）希望订阅用户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将Alice的订阅发送给Bob。当对等网络B有关于Bob的新信息时，它将向对等网络A发送通知，后者将通知传递给Alice。
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].
这类似于简单的域间订阅用例，除了在这种情况下Alice订阅表示对等网络B[9][3]中用户列表的统一资源标识符（URI）[8]。
There are several types of lists that Alice may subscribe to:
Alice可以订阅几种类型的列表：
o Personal group - a list that is created and maintained by Alice and includes Alice's watch list.
o 个人组-由Alice创建和维护的列表，包括Alice的观察列表。
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 特设小组-一个短暂的列表，通常是在Alice正在进行的某些活动的上下文中创建的。特设小组可以由Alice或某些应用程序创建。典型的例子可能是与Alice一起参加会议或游戏的人员名单。
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]，则来自一个对等网络的多个观看者[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].
可能看不到位置信息，将发送两个状态文档——每个文档都与应该接收它的观察者列表相关联。一个状态文档将包含位置信息并与可能看到它的用户列表相关联，而另一个状态文档将不包含位置信息并与可能看不到位置信息的用户列表相关联。见[11]。
In this use case, a user from one Peer Network sends a pager mode [7] IM to a user on another Peer Network.
在此用例中，来自一个对等网络的用户向另一个对等网络上的用户发送寻呼机模式[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.
在此用例中，来自一个对等网络的用户与来自另一个对等网络的用户创建消息会话中继协议（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会话（不在本文档范围内）之外，只有presence和IM已被批准为RFC。除了presence和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]中定义的联合支持多个对等网络之间的对等。联邦可以通过为对等网络提供集线器的中央服务来实现，或者，对等网络可以以对等方式彼此连接。这种集线器类型的联邦应该提供的最重要的服务之一是授权互连，它使每个对等网络能够安全地识别其他对等网络。可能提供的其他服务包括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:
当对等网络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 如果有第三方（如清算所）参与两个对等网络之间的连接，则该元素也是安全的。
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节），隐私问题就更难了。我们可以想象，如果一个对等网络的用户能够看到隐私信息并得知他/她被列在好友的阻止列表中，会发生什么样的惨败。
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对等用例”，正在进行的工作，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列表服务的框架和安全考虑”，正在进行的工作，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月。
[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）提供/应答机制”，正在进行的工作，2008年5月。
[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 27782000年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 34282002年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）：通用语法”，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.，“消息会话中继协议（MSRP）”，RFC 49752007年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科学园，以色列雷霍沃特
EMail: avshalom@il.ibm.com
EMail: avshalom@il.ibm.com
Edwin Aoki AOL LLC 401 Ellis Street Mountain View, CA 94043 USA
Edwin Aoki AOL LLC美国加利福尼亚州埃利斯街山景城401号，邮编94043
EMail: aoki@aol.net
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美国
EMail: Sriram.Parameswar@microsoft.com
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.