SPEERMINT WG A. Houri Internet-Draft IBM Intended status: Standards Track E. Aoki Expires: November 16, 2007 AOL LLC S. Parameswar Microsoft Corporation May 15, 2007 Presence & IM Requirements draft-houri-speermint-presence-im-requirements-00.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 November 16, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Houri, et al. Expires November 16, 2007 [Page 1] Internet-Draft Presence & IM Requirements May 2007 Abstract The document lists requirements for peering between two or more service providers that provide none VOIP based 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.. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Houri, et al. Expires November 16, 2007 [Page 2] Internet-Draft Presence & IM Requirements May 2007 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Houri, et al. Expires November 16, 2007 [Page 3] Internet-Draft Presence & IM Requirements May 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 requirements for none VOIP RTC services. The requirements are based on the use cases draft [3]. This document will use the terminology as defined in [2] unless otherwise is stated. Houri, et al. Expires November 16, 2007 [Page 4] Internet-Draft Presence & IM Requirements May 2007 3. Requirements The use cases described in [3] may seem simple. However, in reality it is not so. The following is an initial list of 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 manually. o PRES-IM-REQ-001: 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 PRES-IM-REQ-002: 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 TLS 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 PRES-IM-REQ-003: Simple Subscription - It should be possible for users of one community to subscribe to a presentity served by another community via their local community. o PRES-IM-REQ-004: Public List Subscription - It should be possible for users of one community to subscribe to a public list of presentities served by another community via their local community. o PRES-IM-REQ-005: Private List Subscription - It should be possible for users of one community to subscribe to a private (personal) list presentities served by another community via their local community. o PRES-IM-REQ-006: Sending One Time Message - It should be possible for a users of one community to send a one time message to users in the other community via their local community. o PRES-IM-REQ-007: Creating Message Sessions - It should be possible for a users of one community to create a session based messaging with users in the other community via their local community server. o PRES-IM-REQ-008: Participate in N-Way Chat - It should be possible for users from multiple communities to participate in a chat room where there will be use res from other communities. Houri, et al. Expires November 16, 2007 [Page 5] Internet-Draft Presence & IM Requirements May 2007 o PRES-IM-REQ-009: Transfer Files - It should be possible for users from one community to send files to users in another community via their local community server. o PRES-IM-REQ-010: Federation - It should be possible for several communities to federate together so users of each community will be able to collaborate with users of other community or communities. It should be possible for each federating community to find the list of other communities in the federation. o PRES-IM-REQ-011: Federation Privacy - It should be possible for a community in a federation to specify which other communities should be able to connect with it via the federation. o PRES-IM-REQ-012: Privacy Sharing - In order to enable sending less notifications between communities, there should be a mechanism that will enable sharing privacy information of users between the communities. This will enable sending a single notification per presentity that will be sent to the appropriate watchers on the other community according to the presentity's privacy information. o PRES-IM-REQ-013: Privacy Sharing Security - The privacy sharing mechanism must be done in a way that will enable getting the consent of the user whose privacy will be sent to the other community prior to sending the privacy information. if user consent is not give, it should not be possible to this optimization. In addition to getting the consent of users regarding privacy sharing, the privacy data must be sent only via secure channels between communities. o PRES-IM-REQ-014: Multiple Recipients - It should be possible to send a presence document with a list of watchers on the other community that should receive the presence document notification. This will enable sending less presence document notifications between the communities while avoiding the need to share privacy information of presentities from one community to the other. o PRES-IM-REQ-015: Services Discovery - 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 [4] are supported. Etc. Houri, et al. Expires November 16, 2007 [Page 6] Internet-Draft Presence & IM Requirements May 2007 o PRES-IM-REQ-016: Mappings - A lot of the early deployments of SIP based presence and IM gateways are deployed in front of legacy proprietary systems that use different names for different properties that exist in PIDF. For example "Do Not Disturb" may be translated to "Busy" in another system. In order to make sure that the meaning of the status is preserved, there is a need that either each system will translate its internal statuses to standard PIDF based statuses of a translation table of proprietary statuses to standard based PIDF statuses will be provided from one system to the other. o PRES-IM_REQ-017: Good Citizenship - presence and IM have many network and processing demands both from the point of view of number of messages and the point of view of processing time. In order to 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 November 16, 2007 [Page 7] Internet-Draft Presence & IM Requirements May 2007 4. Security Considerations This document discusses requirements for none VOIP real time collaboration peering between communities. Some of the requirements touch on privacy of users and other security sensitive data. The realization of these requirements in protocols will certainly have implications on security and will have take security into consideration. The requirements also require explicitly that any sharing of privacy settings of users between communities must be done with the given consent of the users whose privacy is shared and in a secure channel. Houri, et al. Expires November 16, 2007 [Page 8] Internet-Draft Presence & IM Requirements May 2007 5. Acknowledgments We would like to thank Jonathan Rosenberg and Roahn Mahy for their input. Houri, et al. Expires November 16, 2007 [Page 9] Internet-Draft Presence & IM Requirements May 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] Houri, A., "Presence & IM Use Cases", draft-ietf-speermint-consolidated-presence-im-usecases-00 (work in progress), February 2007. [4] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006. Houri, et al. Expires November 16, 2007 [Page 10] Internet-Draft Presence & IM Requirements May 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 November 16, 2007 [Page 11] Internet-Draft Presence & IM Requirements May 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 November 16, 2007 [Page 12]