SPEERMINT WG A. Houri
Internet-Draft IBM
Intended status: Informational E. Aoki
Expires: January 6, 2008 AOL LLC
S. Parameswar
Microsoft Corporation
July 5, 2007
Presence & Instant Messaging Peering Use Cases
draft-ietf-speermint-consolidated-presence-im-usecases-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 6, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The document describes several use cases of peering of non-VoIP
services between two or more Service Providers (SP). 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 the document is to drive
Houri, et al. Expires January 6, 2008 [Page 1]
Internet-Draft Presence & IM Peering Use Cases July 2007
requirements for peering between domains that provide the non-VoIP
based collaboration services and presence and Instant Messaging (IM)
in particular.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Simple Interdomain Subscription . . . . . . . . . . . . . . 3
2.2. List Based Interdomain Subscription . . . . . . . . . . . . 3
2.3. Authorization Migration . . . . . . . . . . . . . . . . . . 4
2.4. Page Mode IM . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Session Based IM . . . . . . . . . . . . . . . . . . . . . 5
2.6. Other Services . . . . . . . . . . . . . . . . . . . . . . 5
2.7. Federation & Clearing House . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Houri, et al. Expires January 6, 2008 [Page 2]
Internet-Draft Presence & IM Peering Use Cases July 2007
1. Introduction
The document uses the terminology as defined in [2] unless otherwise
stated.
Real Time Collaboration (RTC) services 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 PSTN that enabled global reachabilty). 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 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 Voice over IP (VoIP) Real Time Collaboration (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 [3].
2. Use Cases
2.1. Simple Interdomain Subscription
Assume two Peer Networks [2], peer network A and peer network B. User
Alice@example.com wants to subscribe to user Bob@.example.net and get
his presence information. In order to do so, Alice@
domainA.example.com may connect directly to example.net and subscribe
to Bob's presence information. However, peer network B is not
willing to support subscriptions from any user in the network and is
willing only to support its users and users that are coming from
other peer networks that peer network B trusts.
In reality what will happen is that peer network A will connect to
peer network B and will send Alice's subscription on Bob to peer
network B. When peer network B has new information on Bob it will
send notifications to peer network A that 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] [4]
Houri, et al. Expires January 6, 2008 [Page 3]
Internet-Draft Presence & IM Peering Use Cases July 2007
There are two sub use cases here:
o The list that Alice subscribes to is a list that is configured by
the administrator and it is used to host the names of a group of
specific people, e.g. the support group of a company.
o A private group of Alice's friends and the reason that Alice will
be using the list instead of doing separate subscriptions is to
save on the number of SUBSCRIBE [6] sessions.
2.3. Authorization Migration
If many users from one Peer Network watch presentities [5] in another
Peer Network, it may be possible that many watchers [5] from one Peer
Network will subscribe to the same user in the other Peer Network.
However, due to privacy constraints, each Peer Network will have to
send multiple copies of the watched presence document. The privacy
constraints enable a user to provide different presence documents to
friends, co-workers etc. 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 to be responsible to send
the right values to the right watchers according to the privacy
definitions of the watched users who were delegated to it from the
Peer Network where the watched user resides.
Instead of sharing privacy between the Peer Networks, it is also
possible to send different copies of the presence document with a
list of the watchers that the presence document is intended to. For
example, if there is a set of watchers in the other Peer Network that
may see the location of the presentity and another set of users in
the other Peer Network that may not see the location information, two
presence documents will be sent, each one associated with a list of
users 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.
2.4. Page Mode IM
In this use case a user from one peer network sends a page mode [7]
IM to a user on another peer network. As with subscription, the
message will pass between the users through the Signaling path Border
Houri, et al. Expires January 6, 2008 [Page 4]
Internet-Draft Presence & IM Peering Use Cases July 2007
Elements (SBE) [2] of the peer networks.
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. The session establishment and the messages will pass
between the users through the SBEs [2] of the peer networks.
2.6. Other Services
In addition to VoIP sessions which are out of scope for this document
only presence and IM are nearing standardization completion. In
addition to presence and IM, there are many other services that are
being standardized or may be implemented using minimal extensions to
existing standards. These include:
o N-way chat - Enable a multi-participant chat that will include
users from multiple peer networks.
o File transfer - Send files from a user in one peer network to a
user in another peer network.
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 standardized by the IETF
and will not be included the requirements draft 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 peeering also for future services.
2.7. Federation & Clearing House
Federation as defined in [2] enables peering between multiple Peer
Networks. One enablement of a federation can be via a central server
that provides services to the Peer Networks or using a peer to peer
model that enables many Peer Networks to connect to each other via
the peer to peer network. These services can be an N-way chat
server, security, lawful interception, logging and more. This type
of federation is known also known as a "clearing house".
Non-VoIP services as being usually more text based and consuming less
bandwidth may benefit from having a central service that will do
central services as logging for them. For example, instead of
requiring each Peer- Network to log all messages that are being sent
Houri, et al. Expires January 6, 2008 [Page 5]
Internet-Draft Presence & IM Peering Use Cases July 2007
to the other Peer-Network, this service can be done by the clearing
house.
3. IANA Considerations
This document has no actions for IANA.
4. Security Considerations
This document discusses use cases for peering between Peer Networks.
It is very clear that the protocols that will enable and make such
peering easier will have significant security considerations. The
solutions for the security issues is out of scope for this document
but here are some examples of security issues that are implied by
this document:
When a message is received from a user on another Peer Network,
the receiving user, should trust that the other Peer Network have
authenticated the user and it is really the user he or she claim
to be.
In order to enable peering between big Peer Networks there are
some optimizations that will require users of one Peer Network to
trust the other Peer Network with respect to their privacy.
5. Acknowledgments
We would like to thank Jonathan Rosenberg, Rohan Mahy, Jason
Livingood, Alexander Mayhorfer, Henry Sinnreich and Mohamed Boucadir
for their valuable input.
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[2] Malas, D. and D. Meyer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-07 (work in progress),
June 2007.
[3] Uzelac, A., "VoIP SIP Peering Use Cases",
Houri, et al. Expires January 6, 2008 [Page 6]
Internet-Draft Presence & IM Peering Use Cases July 2007
draft-ietf-speermint-voip-consolidated-usecases-02 (work in
progress), June 2007.
[4] Camarillo, G. and A. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-06 (work in progress),
September 2006.
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[7] Campbell, B., 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., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-19 (work in progress),
February 2007.
Authors' Addresses
Avshalom Houri
IBM
Science Park Building 18/D
Rehovot,
Israel
Email: avshalom@il.ibm.com
Houri, et al. Expires January 6, 2008 [Page 7]
Internet-Draft Presence & IM Peering Use Cases July 2007
Edwin Aoki
AOL LLC
360 W. Caribbean Drive
Sunnyvale, CA 94089
USA
Email: aoki@aol.net
Sriram Parameswar
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: Sriram.Parameswar@microsoft.com
Houri, et al. Expires January 6, 2008 [Page 8]
Internet-Draft Presence & IM Peering Use Cases July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Houri, et al. Expires January 6, 2008 [Page 9]
