[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 5344

SPEERMINT WG                                                    A. Houri
Internet-Draft                                                       IBM
Intended status: Informational                                   E. Aoki
Expires: May 19, 2008                                            AOL LLC
                                                           S. Parameswar
                                                  Microsoft  Corporation
                                                       November 16, 2007


             Presence & Instant Messaging Peering Use Cases
     draft-ietf-speermint-consolidated-presence-im-usecases-03.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 May 19, 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 May 19, 2008                  [Page 1]

Internet-Draft       Presence & IM Peering Use Cases       November 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  . . . . . . . . . . . . . . . . . . . . . . . 5
     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 . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9



























Houri, et al.             Expires May 19, 2008                  [Page 2]

Internet-Draft       Presence & IM Peering Use Cases       November 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 readability).  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, 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@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 that Peer Network A will connect to
   peer network B and will 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 that will pass them to Alice.

2.2.  List Based Interdomain Subscription

   This is similar to the simple interdomain subscription use case
   except that in this case Alice subscribes to a Uniform Resource
   Identifier (URI) [10] that represents a list of users in Peer Network
   B [11] [4]



Houri, et al.             Expires May 19, 2008                  [Page 3]

Internet-Draft       Presence & IM Peering Use Cases       November 2007


   There are several types of lists that Alice may subscribe to:

   o  Personal group - A list that was created and maintained by Alice
      and includes Alice's watch list.
   o  Public group - A list that is created and maintained by an
      administrator and is typically referred to as a public group.
      Public groups usually contains a list of specific people that have
      some common characteristic e.g. support group of a company.
   o  Ad-hock group - A list that is short lived and is usually created
      in a context of some activity that Alice is doing.  A public 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 [7] in another
   Peer Network, it may be possible that many watchers [7] 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 to be responsible for
   sending the right values to the right watchers according to the
   delegated privacy policies of the watched users.

   Instead of sharing watcher'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 that the presence
   document is intended for.  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 is 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.





Houri, et al.             Expires May 19, 2008                  [Page 4]

Internet-Draft       Presence & IM Peering Use Cases       November 2007


2.4.  Page Mode IM

   In this use case a user from one Peer Network sends a page mode [9]
   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) [12] 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 fully standardized (became RFCs).  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 textual chat that will
      include users from multiple Peer Networks.  See [5] for more
      details.
   o  File transfer - Send files from a user in one Peer Network to a
      user in another Peer Network.  See [6] 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 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 peering also for future services.

2.7.  Federation & Clearing House

   Federation as defined in [2] 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 each other via a peer-to-peer fashion.  One of
   the most important services that this type of federation should
   provide is authorized interconnection that enables each Peering
   Network to trust that the other Peering Network is who it claims to
   be.  Other services that might be provided include an N-way chat
   server, lawful interception, logging and more.  This type of



Houri, et al.             Expires May 19, 2008                  [Page 5]

Internet-Draft       Presence & IM Peering Use Cases       November 2007


   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.  IANA Considerations

   This document has no actions for IANA.


4.  Security Considerations

   When Peer Network A peers with Peer Network B, there are several
   security issues that the administrator of each Peer Network will need
   mechanisms to verify:

   o  The other Peer Network is really the Peering Network that it
      claims to be.
   o  The other Peer Network is secure and trustful such that
      information that is passed to will not reach a third party.
   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
      verified to be secure.

   The same issues of security are even more important from the point of
   view of the users of the Peer Networks.  Users will have the concern
   on how their privacy is being adhered to when their presence
   information is being sent to the other Peer Network.  We are seeing
   today users are concerned with providing their email address to a
   third party when they register to a domain.  Presence contains much
   more sensitive information and the concerns of the users here will be
   much deeper.

   The privacy issue is even harder if 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 if a user of one Peer Network will be able to see
   the privacy information and will learn he/she are listed in a block
   list of a close friend.

   This document discusses use cases for peering between Peer Networks
   and it is out of scope for the document to provide solutions for



Houri, et al.             Expires May 19, 2008                  [Page 6]

Internet-Draft       Presence & IM Peering Use Cases       November 2007


   security.  Nevertheless, it is obvious that the protocols that will
   enable the use cases that are described here will have to provide for
   the security considerations described here.


5.  Acknowledgments

   We would like to thank Jonathan Rosenberg, Jon Peterson, 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-13 (work in progress),
         November 2007.

   [3]   Uzelac, A., "VoIP SIP Peering Use Cases",
         draft-ietf-speermint-voip-consolidated-usecases-03 (work in
         progress), November 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-07 (work in progress),
         November 2007.

   [5]   Niemi, A. and M. Garcia-Martin, "Multi-party Instant Message
         (IM) Sessions Using the Message Session Relay  Protocol
         (MSRP)", draft-ietf-simple-chat-00 (work in progress),
         June 2007.

   [6]   Garcia-Martin, M., Isomaki, M., Camarillo, G., and S. Loreto,
         "A Session Description Protocol (SDP) Offer/Answer Mechanism to
         Enable File  Transfer", draft-ietf-mmusic-file-transfer-mech-04
         (work in progress), October 2007.

   [7]   Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
         and Instant Messaging", RFC 2778, February 2000.




Houri, et al.             Expires May 19, 2008                  [Page 7]

Internet-Draft       Presence & IM Peering Use Cases       November 2007


   [8]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

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

   [10]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
         January 2005.

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

   [12]  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


   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 May 19, 2008                  [Page 8]

Internet-Draft       Presence & IM Peering Use Cases       November 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 May 19, 2008                  [Page 9]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/