Presence and Instant Messaging Peering Use Cases
Service provider cooperation in real-time collaboration.
Houri, A., Aoki, E., and S. Parameswar, "Presence and Instant Messaging Peering Use Cases", RFC 5344, DOI 10.17487/RFC5344, October 2008, <https://www.rfc-editor.org/info/rfc5344>.
@misc{rfc5344,
series = {Request for Comments},
number = 5344,
howpublished = {RFC 5344},
publisher = {RFC Editor},
doi = {10.17487/RFC5344},
url = {https://www.rfc-editor.org/info/rfc5344},
author = {A. Houri and E. Aoki and S. Parameswar},
title = {{Presence and Instant Messaging Peering Use Cases}},
pagetotal = 9,
year = 2008,
month = oct,
} RFC text
Contents
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
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.
2.2. List-Based Interdomain Subscription
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].
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 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 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.
2.3. Authorization Migration
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].
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
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 File transfer - send files from a user in one Peer Network to a
user in another Peer Network. See [5] for more details.
o 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 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.
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.
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 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".
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.
3. Security Considerations
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:
o All communication channels between Peer Networks and between each
Peer Network and the Clearing House have their authenticity and
confidentiality protected.
o The other Peer Network is really the Peering Network that it
claims to be.
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 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 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.
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.
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
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.
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
Full Copyright Statement
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.
AI ELI5
On this page
§1Presence and Messaging Across Networks
Real-Time Collaboration (RTC) services—presence and instant messaging—have become essential for Internet users. While users within a single organization use one provider's service, users increasingly need to interact with those on other providers' networks, similar to how phone networks interconnect globally. This RFC describes use cases for how service providers can peer their presence and instant messaging services so their users can collaborate across provider boundaries.
The document captures how presence and instant messaging are currently used within enterprises and operator domains, describing practical scenarios that drive requirements for secure peering. It focuses on non-VoIP services (VoIP peering is addressed separately) and does not propose new protocols, but rather documents the situations that any future peering protocol will need to handle.
Different companies run chat services. This document describes situations where people on one company's service need to talk to people on another company's service, to help those companies figure out how to let that happen.
§2Core Peering Scenarios
Simple Interdomain Subscription is the most basic case: a user (Alice@example.com) on one provider wants to subscribe to the presence of a user (Bob@example.net) on another. Instead of Alice connecting directly to Bob's provider, Alice's provider connects to Bob's provider and forwards the subscription request, then passes back notifications when Bob's status changes. This requires a trust relationship where each provider accepts subscriptions only from its own users or from other trusted providers.
List-Based Subscription extends this: Alice can subscribe to a presence list representing multiple users. These lists may be personal (created and maintained by Alice), public (created by an administrator for groups like a support team), or ad-hoc (temporary lists for conference participants or game players). Cross-provider list subscriptions require providers to resolve and handle lists that span their boundaries.
Pager Mode Instant Messaging allows users to send standalone IM messages across providers. This is simpler than session-based messaging because it does not require a back-and-forth conversation session; each message stands alone.
Session-Based Instant Messaging creates a conversation session using the Message Session Relay Protocol (MSRP), allowing multiple exchanges between users on different providers. Sessions are stateful and require more coordination than pager-mode messages.
Beyond presence and basic messaging, the RFC mentions potential services including N-way chat (multi-participant conversations across providers), file transfer (sending files between users on different networks), and document sharing.
Users might want to: check if a friend on another service is online, send one-off messages, have back-and-forth conversations, talk in group chats, or share files. Each needs different kinds of connections between providers.
§3Authorization and Privacy Across Providers
A critical issue for cross-provider peering is authorization migration. When many users from Provider A watch users in Provider B, a naive approach sends separate presence documents to each user, respecting their privacy rules. However, if Alice and Bob both watch Carol on Provider B, Provider B must send two copies of Carol's presence (filtered for Alice and Bob respectively), creating redundant traffic.
To make this efficient, providers can agree to share privacy information. Provider B sends a single, full copy of Carol's presence document to Provider A, and Provider A becomes responsible for filtering it according to Carol's delegated privacy rules before sending results to its users. This optimization requires both providers to trust each other with sensitive privacy information.
An alternative approach sends multiple copies of the presence document, each tagged with the list of watchers it is intended for, without fully sharing privacy policies. For example, Provider B might send one document showing Carol's location (for users allowed to see it) and another without location information (for users not allowed to see it), each with an associated watcher list.
Privacy protection is essential: users must trust that their presence information is not revealed to unauthorized parties and that sensitive information like block lists remains confidential when passed between providers.
If many people on one service watch the same person on another, sending them all the person's status separately wastes bandwidth. Providers can agree to share privacy rules, but this requires them to trust each other with sensitive information.
§4Federation Models and Clearing Houses
Federation enables peering between multiple service providers. It can be organized in two ways: peer-to-peer (each provider connects directly to others) or through a central hub called a Clearing House.
A Clearing House is a central service that provides a hub for multiple providers. It offers several functions: authorized interconnection that lets each provider securely verify the identity of other providers; central logging (instead of each provider logging all cross-provider messages, the Clearing House does it centrally); lawful interception services; and support for multi-party services like N-way chat across multiple providers.
Text-based services like presence and messaging consume less bandwidth than VoIP, making them particularly suited to Clearing House models. A central service can efficiently handle logging and other functions that would be expensive if duplicated across many providers. The Clearing House becomes a trusted intermediary in the federation, responsible for accurate forwarding of presence updates and messages.
Providers can connect directly to each other, or they can all connect to one central hub. The hub can be trusted to log messages, verify which providers are real, and handle complex features like group conversations involving multiple services.
§5Security and Trust Requirements
Peering between providers raises several security requirements. Providers must verify:
- All communication channels between providers are authenticated and encrypted.
- Each provider is actually who it claims to be.
- The other provider is trustworthy and will not leak information to third parties.
- The other provider will not modify or falsify presence or messaging data except as allowed by authorization policies.
- Any Clearing House involved is similarly secure.
Users themselves have additional concerns. Presence contains more sensitive information than email addresses; users need assurance their presence is seen only by authorized viewers. Privacy violations could be severe: for example, if a user discovers they are on a friend's block list through information leakage.
The optimization of sharing privacy policies between providers (Section 3) heightens these concerns. The RFC acknowledges these security issues but notes that the document itself does not propose solutions. However, any protocol enabling the peering scenarios described here must address these security requirements comprehensively. Security is not an optional add-on but fundamental to making cross-provider peering acceptable to both administrators and users.
When messages and presence pass between services, they must be encrypted, service providers must trust each other, and users must be sure their private information stays private. The biggest risk is accidentally revealing who someone is blocked by or other sensitive details.