Presence and Instant Messaging Peering Use Cases
RFC 5344
Document | Type | RFC - Informational (October 2008; No errata) | |
---|---|---|---|
Authors | Sriram Parameswar , Edwin Aoki , Avshalom Houri | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5344 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Jon Peterson | ||
Send notices to | (None) |
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). 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 Houri, et al. Informational [Page 1] RFC 5344 Presence and IM Peering Use Cases October 2008 1. Introduction This document uses the terminology as defined in [1] unless otherwise stated. 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]. 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. 2. Use Cases 2.1. Simple Interdomain Subscription 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. 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. Houri, et al. Informational [Page 2] RFC 5344 Presence and IM Peering Use Cases October 2008 2.2. List-Based Interdomain Subscription This is similar to the simple interdomain subscription use case,Show full document text