SPEERMINT WG                                                    A. Houri
Internet-Draft                                                       IBM
Intended status: Standards Track                                 E. Aoki
Expires: August 29, 2007                                         AOL LLC
                                                           S. Parameswar
                                                  Microsoft  Corporation
                                                       February 25, 2007

                        Presence & IM Use Cases

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 29, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Houri, et al.            Expires August 29, 2007                [Page 1]

Internet-Draft           Presence & IM Use Cases           February 2007


   The document describes several use cases of peering between two or
   more service providers that provide real time collaboration services
   and presence and IM in particular.  These service providers create a
   peering relationship between themselves thus enabling their users to
   collaborate with users on other communities.  The target of the
   document is to help understanding the requirements for peering
   between domains with regard to real time services

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Simple Interdomain Subscription  . . . . . . . . . . . . .  5
     3.2.  List Interdomain Subscription  . . . . . . . . . . . . . .  5
     3.3.  Authorization Migration  . . . . . . . . . . . . . . . . .  5
     3.4.  Page mode IM . . . . . . . . . . . . . . . . . . . . . . .  6
     3.5.  Session based IM . . . . . . . . . . . . . . . . . . . . .  6
     3.6.  Other services . . . . . . . . . . . . . . . . . . . . . .  6
     3.7.  Federation . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

Houri, et al.            Expires August 29, 2007                [Page 2]

Internet-Draft           Presence & IM Use Cases           February 2007

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [1].

Houri, et al.            Expires August 29, 2007                [Page 3]

Internet-Draft           Presence & IM Use Cases           February 2007

2.  Introduction

   Real Time Collaboration (RTC) services are becoming as prevalent and
   essential for users on the Internet as email.  While RTC services
   can, like email, be implemented directly by users in a point-to-point
   fashion, they are often provided for or on behalf of a community 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 community but with those in other communities
   as well.  In practice, each community is controlled by some
   authority, and so there is a need to provide for easier establishment
   of connectivity between communities, and the management of the inter-
   community link.  This document contains a set of use cases that
   describe how peering between communities may be used.  The use cases
   are intended to help in creating a set of requirements that will
   enable more secure and easier peering between communities that
   provide RTC services.

   This document will use the terminology as defined in [2] unless
   otherwise is stated.

   The following sections provide several use cases followed by a
   discussion on what these use cases may imply regarding the
   functionalities that need to be provided for in order to implement
   those use cases

Houri, et al.            Expires August 29, 2007                [Page 4]

Internet-Draft           Presence & IM Use Cases           February 2007

3.  Use Cases

3.1.  Simple Interdomain Subscription

   Assume that we have two peer networks [2], peer network A and peer
   network B. User Alice@A.com wants to subscribe to user Bob@B.com and
   get his presence information.  In order to do so, Alice@A.com may
   connect directly to B.com 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.

3.2.  List Interdomain Subscription

   This is the same as the simple interdomain subscription use case but
   in this case Alice subscribes to a URI that represents a list of
   users in peer network B [3]

3.3.  Authorization Migration

   if many users from one peering network watch presentities in another
   peering network, it may be possible that many watchers from one
   peering network will subscribe to the same user in the peering
   network.  However, due to privacy constraints, each peering network
   will have to send multiple copies of the watched presence document.
   The privacy constraints enable a user to provide different persence
   document to e.g. friends, co-workers etc.  The need to send multiple
   copies between the peering networks is very inefficient and causes
   redundant traffic between the peering networks.

   In order to make the subscription between peering networks more
   efficient there needs to be a way to enable peering networks to agree
   to share privacy information between them.  This will enabble sending
   a single copy (the full copy) of the presence document of of the
   watched user and letting the receiving peering network to be
   responsible to send the right values to the right watchers according
   to the privacy definitions of the watched user that were delegated to
   it from the peering network where the watched user resides.

Houri, et al.            Expires August 29, 2007                [Page 5]

Internet-Draft           Presence & IM Use Cases           February 2007

3.4.  Page mode IM

   In this use case a user from one peer network sends a page mode [4]
   IM to a user on another peer network.  As with subscription, the
   message will pass between the users through the SBEs [2] of the peer

3.5.  Session based IM

   In this use case a user from one peer network creates an MSRP [5]
   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.

3.6.  Other services

   In addition to media (voice/video) which are out of scope for this
   document only presence and IM are more or less fully standardized in
   real time collaboration.  However 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 many 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

   There are many more collaboration services that can be thought about.
   Enabling peering between networks for some of the services will
   create a basis for defining many more services

3.7.  Federation

   Federation as defined in [2] is a use case also in real time

   Real time collaboration services may benefit even more the voice/
   video services from federation.  Collaboration by its definition is
   something that is stronger where there many more parties
   collaborating and federation is certainly a good way to achieve
   greater collaboration.

   Additional "side" services as security, lawful interception, logging
   and more may be provided to the peer networks that are members of the

Houri, et al.            Expires August 29, 2007                [Page 6]

Internet-Draft           Presence & IM Use Cases           February 2007


   Note that federation is also known as clearing house in the real time
   collaboration industry.

Houri, et al.            Expires August 29, 2007                [Page 7]

Internet-Draft           Presence & IM Use Cases           February 2007

4.  Discussion

   The use cases described above may seem to be simple.  However, in
   reality it is not so.  The following describes issues that need to be
   solved in order to enable the creation of the use cases without the
   need to negotiate each peer network relationship separately and

   o  Connectivity - A peer network needs a mechanism to learn the
      connectivity setting of the other peer network.  Examples of
      connectivity parameters may be list of domains that the peer
      network is representing, firewall and NAT settings and more.

   o  Security - The peer network or the federation that is being
      connected to may require certain level of security in order to
      accept connections from another peer network.  For example, peer
      network B may require that only TL'S will be used and it can also
      specifies the type and level of certificates that should be used.
      Community A will need a way to discover and use these parameters.

   o  Privacy - In many peer networks that provide real time
      collaboration services there are inter mechanisms that enable a
      user to configure the level of privacy that they wish to achieve.
      for example, a user may say that only certain users will be able
      to see him/her etc.  Similar mechanisms are required to be in
      place in peering and in the federation model.

   o  Services - When two or more peer networks are peering for real
      time collaboration services, each peer network has to have an
      understanding regarding the services that are provided by the
      other peer network.  This may/should include: A) The list of
      services that are provided by the peer network or the federation.
      B) Parameters for each services that may be different between peer
      networks.  For example if the peer network provides for page mode
      IMs or session based IMs or both?  Is presence filtering or
      partial notification is supported?  Are subscription to resource
      lists [3] are supported?

   o  Mappings - Many times one peer network may have different set of
      values for different statuses of a user.  For example "Do not
      Disturb" is translated to "Busy" in the other peer network.  Each
      peer network that peers with another peer network or with a
      federation, should have means for translating the values that may
      differ appropriately.

   o  Good Citizenship - presence and IM have many network and
      processing demands both form the point of view of number of
      messages and the point of view of processing time.  In order to

Houri, et al.            Expires August 29, 2007                [Page 8]

Internet-Draft           Presence & IM Use Cases           February 2007

      enable peer networks connecting to each other without overloading
      each other, each peer network should be able to learn what is the
      expected behavior by the connected to peer network or federation
      and act accordingly.

Houri, et al.            Expires August 29, 2007                [Page 9]

Internet-Draft           Presence & IM Use Cases           February 2007

5.  Security Considerations

   This document discusses use cases for peering between communities.
   It is very clear that the protocols that will enable and make such
   peering easier will have significant security considerations, there
   are out of scope for a use case document.

Houri, et al.            Expires August 29, 2007               [Page 10]

Internet-Draft           Presence & IM Use Cases           February 2007

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]  Meyer, D., "SPEERMINT Terminology",
        draft-ietf-speermint-terminology-06 (work in progress),
        September 2006.

   [3]  Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation
        Protocol (SIP) Event Notification Extension for Resource Lists",
        RFC 4662, August 2006.

   [4]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
        D. Gurle, "Session Initiation Protocol (SIP) Extension for
        Instant Messaging", RFC 3428, December 2002.

   [5]  Campbell, B., "The Message Session Relay Protocol",
        draft-ietf-simple-message-sessions-18 (work in progress),
        December 2006.

Houri, et al.            Expires August 29, 2007               [Page 11]

Internet-Draft           Presence & IM Use Cases           February 2007

Authors' Addresses

   Avshalom Houri
   Science Park Building 18/D

   Email: avshalom@il.ibm.com

   Edwin Aoki
   360 W.  Caribbean Drive
   Sunnyvale, CA  94089

   Email: aoki@aol.net

   Sriram Parameswar
   Microsoft  Corporation
   One Microsoft  Way
   Redmond, WA  98052

   Email: Sriram.Parameswar@microsoft.com

Houri, et al.            Expires August 29, 2007               [Page 12]

Internet-Draft           Presence & IM Use Cases           February 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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Houri, et al.            Expires August 29, 2007               [Page 13]