Internet DRAFT - draft-houri-speermint-usecase-presence
draft-houri-speermint-usecase-presence
SPEERMINT WG A. Houri
Internet-Draft IBM
Intended status: Standards Track E. Aoki
Expires: April 18, 2007 AOL LLC
S. Parameswar
Microsoft Corporation
October 15, 2006
RTC Provisioning Requirements
draft-houri-speermint-usecase-presence-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 April 18, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Houri, et al. Expires April 18, 2007 [Page 1]
Internet-Draft RTC Provisioning Requirements October 2006
Abstract
The document describes several use cases for peering between two or
more communities that provide real time communications services and
presence and IM in particular. The communities create a peering
relationship between themselves thus enabling their users to
collaborate with users on other communities. The target of the
document is to help understanding the requirements for peering
between domains with regard to real time services
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Simple Interdomain Subscription . . . . . . . . . . . . . 5
3.2. List Interdomain Subscription . . . . . . . . . . . . . . 5
3.3. Page mode IM . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Session based IM . . . . . . . . . . . . . . . . . . . . . 5
3.5. Other services . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Federation . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 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 April 18, 2007 [Page 2]
Internet-Draft RTC Provisioning Requirements October 2006
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 April 18, 2007 [Page 3]
Internet-Draft RTC Provisioning Requirements October 2006
2. Introduction
Real Time Communications (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 user cases that
describe how peering between communities may be used. The use cases
are intended to help in creating a set of requirements that will
enable more secure and easier peering between communities that
provide RTC services.
This document will use the terminology as defined in [2] unless
otherwise is stated.
The following sections provide several use cases followed by a
discussion on what these use cases may imply regarding the
functionalities that need to be provided for in order to implement
those use cases
Houri, et al. Expires April 18, 2007 [Page 4]
Internet-Draft RTC Provisioning Requirements October 2006
3. Use Cases
3.1. Simple Interdomain Subscription
Assume that we have two peer networks [2], peer network A and peer
network B. User Alice@A.com wants to subscribe to user Bob@B.com and
get his presence information. In order to do so, Alice@A.com may
connect directly to B.com and subscribe to Bob's presence
information. However, peer network B is not willing to support
subscriptions from any user in the network and is willing only to
support its users and users that are coming 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 on Bob to 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.
3.2. List Interdomain Subscription
This is the same as the simple interdomain subscription use case but
in this case Alice subscribes to a URI that represents a list of
users in peer network B [3]
3.3. Page mode IM
In this use case a user from one peer network sends a page mode [4]
IM to a user on another peer network. As with subscription, the
message will pass between the users through the SBEs [2] of the peer
networks.
3.4. Session based IM
In this use case a user from one peer network creates an MSRP [5]
session with a user from another peer network. The session
establishment and the messages will pass between the users through
the SBEs [2] of the peer networks.
3.5. Other services
In addition to media (voice/video) which are out of scope for this
document only presence and IM are more or less fully standardized in
real time communication. However there are many other services that
are being standardized or may be implemented using minimal extensions
to existing standards. These include:
Houri, et al. Expires April 18, 2007 [Page 5]
Internet-Draft RTC Provisioning Requirements October 2006
o N-way chat - Enable a multi participant chat that will include
users from many peer networs.
o File transfer - Send files from a user in one peer network to a
user in another peer network. Obviously this kind of operation
will require appropriate security mechanisms.
o More to come...
3.6. Federation
Federation as defined in [2] is a use case also in real time
communication.
Multiple peer networks may federate in order to create a whole that
is greater then its parts. In a federation there is no need for one
peer network to explicitly know about the other peer network that is
a member in the federation. It is enough for each peer network that
is a member in the federation to connect to the federation and thus
be able to communicate with other members of the federation.
Additional services as security, lawful intercept and more may be
provided to the peer networks that are members of the federation.
Federation is also known as clearing house in the industry.
Houri, et al. Expires April 18, 2007 [Page 6]
Internet-Draft RTC Provisioning Requirements October 2006
4. Discussion
The use cases described above may seem to be simple. However, in
reality it is not so. The following 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 Connectivity - A peer network needs a mechanism to learn the
connectivity setting of the other peer network or of the
federation. Examples of connectivity parameters may be list of
domains that the peer network is representing, firewall and NAT
settings and more.
o 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 TL'S 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 Privacy - In many peer networks that provide real time
collaboration services there are inter mechanisms that enable a
user to configure the level of privacy that they wish to achieve.
for example, a user may say that only certain users will be able
to see him/her etc. Similar mechanisms are required to be in
place in peering and especially in the federation model.
o Services - When two or more peer networks are peering for real
time communication 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 is
supported?
o Mappings - Many times one peer network may have different set of
values for different statuses of a user. For example "Do not
Disturb" is translated to "Busy" in the other peer network. Each
peer network that peers with another peer network or with a
federation, should have means for translating the values that may
differ appropriately.
o Good Citizenship - presence and IM have many network and
processing demands both form the point of view of number of
messages and the point of view of processing time. In order to
Houri, et al. Expires April 18, 2007 [Page 7]
Internet-Draft RTC Provisioning Requirements October 2006
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 April 18, 2007 [Page 8]
Internet-Draft RTC Provisioning Requirements October 2006
5. Security Considerations
This document discusses use cases for peering between communities.
It is very clear that the protocols that will enable and make such
peering easier will have significant security considerations, there
are our of scope for a use case document.
Houri, et al. Expires April 18, 2007 [Page 9]
Internet-Draft RTC Provisioning Requirements October 2006
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] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation
Protocol (SIP) Event Notification Extension for Resource Lists",
RFC 4662, August 2006.
[4] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[5] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-15 (work in progress),
July 2006.
Houri, et al. Expires April 18, 2007 [Page 10]
Internet-Draft RTC Provisioning Requirements October 2006
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 April 18, 2007 [Page 11]
Internet-Draft RTC Provisioning Requirements October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 April 18, 2007 [Page 12]
