RFC 5344

Presence and Instant Messaging Peering Use Cases

📅 published October 2008, from ietf

RFC 5344: Presence and Instant Messaging Peering Use Cases 💖

Okay bestie, let's get into it 🦋 Here's the title block first, so you know who's behind this and what kind of doc it is:

  • RFC number: 5344
  • Title: Presence and Instant Messaging Peering Use Cases
  • Authors: A. Houri (IBM), E. Aoki (AOL LLC), S. Parameswar (Microsoft Corporation)
  • Category: Informational
  • Date: October 2008
  • Group: Network Working Group
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🌸

Status of This Memo 📜

This memo is just here to share information with the Internet community. It is not a standard of any kind 🙈 And distribution is totally unlimited, so go wild 🌈

Abstract ✨

Okay so this doc describes a bunch of use cases for peering non-VoIP (Voice over IP) services between two or more Service Providers 🎀 Basically, the Service Providers team up, which lets their users chat and collaborate with people on the other provider's network. The goal here is to figure out what peering between domains needs to do for collaboration services that use presence, especially 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

1. Introduction 🌸

This doc uses the terminology defined in [1], unless it says otherwise.

Real Time Collaboration (RTC) services are now as prevalent and essential for people on the Internet as email is 💅 RTC services can be run directly between users in a point-to-point way, but they're often provided for, or on behalf of, a Peer Network of users inside one administrative domain. As these services grow, users increasingly need to talk to people not just in their own Peer Network but in other Peer Networks too 🌍 It's kinda like the old Public Switched Telephony Network (PSTN), which made global reachability possible. In practice, each Peer Network is controlled by some domain, so we need an easier way to set up connectivity between Peer Networks and to manage the relationships between them 🤝

This document describes a set of use cases showing how peering between Peer Networks may be used for non-VoIP RTC services. The point of the use cases is to help identify and capture the requirements that will guide, and eventually enable, secure and easier peering between Peer Networks that provide non-VoIP RTC services 🔐 The use cases for 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 presence and Instant Messaging are currently used within enterprises and operator domains 🧠

2. Use Cases 💖

2.1. Simple Interdomain Subscription ✨

Let's say we have 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. To do that, Alice@example.com could connect directly to example.net and subscribe to Bob's presence information. BUT, Peer Network B only accepts subscriptions and routes IMs when they come from its own users or from other Peer Networks that Peer Network B trusts 🙅‍♀️

What actually happens is that Peer Network A connects to Peer Network B and sends Alice's subscription to Bob via Peer Network B. When Peer Network B gets new information about Bob, it sends notifications to Peer Network A, which then passes them along to Alice 📬

2.2. List-Based Interdomain Subscription 🎀

This is similar to the simple interdomain subscription use case, except this time Alice subscribes to a Uniform Resource Identifier (URI) [8] that represents a list of users in Peer Network B [9] [3] 📋

There are several types of lists Alice might subscribe to:

  • Personal group - a list that Alice creates and maintains, which includes Alice's watch list 💜
  • Public group - a list that an administrator creates and maintains. Public groups usually contain a list of specific people who share some common characteristic, e.g., the support group of a company 🏢
  • Ad-hoc group - a list that's short lived and usually gets created during some activity Alice is doing. An ad-hoc group may be created by Alice or by some application. Typical examples are the list of people who take part with Alice in a conference or a game 🎮

2.3. Authorization Migration 🔄

If lots of users from one Peer Network watch presentities [6] in another Peer Network, it may be possible that many watchers [6] from the first Peer Network subscribe to the same user in the other one 👀 But here's the catch: due to privacy constraints that let a user give different presence documents to different watchers, each Peer Network has to send multiple copies of the watched-presence document. Sending all those copies between the Peer Networks is super inefficient and creates redundant traffic between them 😩

So to make subscriptions between Peer Networks more efficient, Peer Networks need a way to agree to share privacy information between them ✨ That would let them send a single copy (the full copy) of the watched user's presence document, and then the receiving Peer Network handles 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 Peer Networks, it's also possible to send different copies of the presence document, each with a list of the watchers it's intended for. For example, say there's a set of watchers in one Peer Network who may see the location of the presentity, and another set of users in that same Peer Network who may not see the location information. Two presence documents would be sent, each associated with the list of watchers who should receive it. One presence document contains the location information and is associated with the list of users who may see it. The other presence document does not contain the location information and is associated with the list of users who may not see it. See [11] 🗺️

2.4. Pager Mode IM 📟

In this use case, a user from one Peer Network sends a pager mode [7] IM to a user on another Peer Network 💌

2.5. Session Based 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 🧚

2.6. Other Services 🌈

Besides VoIP sessions, which are out of scope for this document, only presence and IM have been ratified as RFCs. On top of presence and IM, there are a bunch of other services that are being standardized or that could be implemented using minimal extensions to existing standards. These include:

  • N-way chat - enables a multi-participant textual chat that includes users from multiple Peer Networks. See [4] for more details 💬
  • File transfer - sends files from a user in one Peer Network to a user in another Peer Network. See [5] for more details 📁
  • Document sharing - sharing and editing a document between users in different Peer Networks 📝
Note: Document sharing is mentioned in this document only for completeness of the use cases. It is not being standardized by the IETF and will not be included in the requirements document that results from this document 🙅‍♀️

The list above is of course not exhaustive, since new developments in the world of non-VoIP RTC will surface new services. Enabling peering between networks for some of these services will create a basis for enabling peering for future services too 🔮

2.7. Federation and Clearing House 👑

A federation, as defined in [1], enables peering between multiple Peer Networks. A federation may be implemented by means of a central service that acts as 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, which lets each Peering Network 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" 🏠

Since non-VoIP services are usually text-based and consume less bandwidth, they may benefit from a central service that handles things like logging for them 📚 For example, instead of requiring each Peer Network to log all messages sent to the other Peer-Network, this service can be done by the Clearing House 🫧

3. Security Considerations 🔐✨

Okay bestie, this part is SO important. When Peer Network A peers with Peer Network B, the admin of each network needs ways to verify a bunch of security stuff 🫶:

  • All communication channels between Peer Networks and between each Peer Network and the Clearing House have their authenticity and confidentiality protected.
  • The other Peer Network is really the Peering Network that it claims to be.
  • 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.
  • 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.
  • 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.

And the stakes are even higher for the users 😭. They'll be super worried about their privacy when their presence info gets sent to the other Peer Network. Like, people are already nervous about handing their email to a third party when they sign up for a domain 💀. Presence has way more sensitive info than that, so the worry is gonna be even bigger 🙈.

The privacy situation gets even trickier because, to make peering scale between big Peer Networks, some optimizations may require migrating users' privacy definitions between Peer Networks (see Section 2.3). Imagine the total fiasco if a user on one Peer Network could peek at their privacy info and find out they're on a close friend's block list 💀🫠. Iconic, but make it make sense 🙃.

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. 🎀

4. Acknowledgments 🙏💖

Huge thank-yous to Jonathan Rosenberg, Jon Peterson, Rohan Mahy, Jason Livingood, Alexander Mayrhofer, Joseph Salowey, Henry Sinnreich, and Mohamed Boucadir for their valuable input 🫶✨. You all are literally the MVPs 👑.

5. Informative References 📚

  • [1] Malas, D. and D. Meyer, "SPEERMINT Terminology", Work in Progress, February 2008.
  • [2] Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", Work in Progress, May 2008.
  • [3] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", Work in Progress, November 2007.
  • [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.
  • [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.
  • [6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
  • [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.
  • [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [9] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
  • [10] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
  • [11] Rosenberg, J., Donovan, S., and K. McMurry. "Optimizing Federated Presence with View Sharing", Work in Progress, July 2008.

Authors' Addresses 💌

Avshalom Houri
IBM
3 Pekris Street
Science Park
Rehovot,
Israel

EMail: avshalom@il.ibm.com

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

EMail: Sriram.Parameswar@microsoft.com

Copyright (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.

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.

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.

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.

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. 💜🌈

📦 where this page comes from