summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5344.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5344.txt')
-rw-r--r--doc/rfc/rfc5344.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc5344.txt b/doc/rfc/rfc5344.txt
new file mode 100644
index 0000000..7dece45
--- /dev/null
+++ b/doc/rfc/rfc5344.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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]
+