GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5344

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

Houri, et al. Informational [Page 1] RFC 5344 Presence and IM Peering Use Cases October 2008

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.

Houri, et al. Informational [Page 2] RFC 5344 Presence and IM Peering Use Cases October 2008

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

Houri, et al. Informational [Page 3] RFC 5344 Presence and IM Peering Use Cases October 2008

    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.

Houri, et al. Informational [Page 4] RFC 5344 Presence and IM Peering Use Cases October 2008

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.

Houri, et al. Informational [Page 5] RFC 5344 Presence and IM Peering Use Cases October 2008

 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.

Houri, et al. Informational [Page 6] RFC 5344 Presence and IM Peering Use Cases October 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.

Houri, et al. Informational [Page 7] RFC 5344 Presence and IM Peering Use Cases October 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

Houri, et al. Informational [Page 8] RFC 5344 Presence and IM Peering Use Cases October 2008

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.

Houri, et al. Informational [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5344.txt · Last modified: 2008/10/17 21:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki