Internet DRAFT - draft-houri-speermint-presence-im-requirements
draft-houri-speermint-presence-im-requirements
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]
