Internet DRAFT - draft-garcia-xcon-private-messaging-reqs
draft-garcia-xcon-private-messaging-reqs
Network Working Group M. Garcia-Martin
Internet-Draft A. Niemi
Expires: January 1, 2006 Nokia
June 30, 2005
Requirements for Private Messaging in Centralized Conference
Environments
draft-garcia-xcon-private-messaging-reqs-01
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 January 1, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Message Session Relay Protocol (MSRP) defines a mechanism for
sending session-based instant messages. The session is negotiated
using the Session Initiation Protocol (SIP) and the Session
Description Protocol (SDP). MSRP can be used in a centralized
conference just as any other media type. This document provides
requirements in support for MSRP in centralized conferences,
including requirements to provide private instant messages within a
Garcia-Martin & Niemi Expires January 1, 2006 [Page 1]
Internet-Draft Multiparty MSRP June 2005
conference.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 General Requirements . . . . . . . . . . . . . . . . . . . 5
4.2 Private Messaging Requirements . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 9
Garcia-Martin & Niemi Expires January 1, 2006 [Page 2]
Internet-Draft Multiparty MSRP June 2005
1. Introduction
The Message Session Relay Protocol (MSRP) [I-D.ietf-simple-message-
sessions] defines a mechanism for sending a series of instant
messages within a session. The Session Initiation Protocol (SIP)
[RFC3261] allows for two peers to set up such a session.
In another application of SIP, a user agent can join in a multi-party
session or centralized conference that is hosted by a specialized
user agent called a conference focus [I-D.ietf-sipping-conferencing-
framework]. Such a conference can naturally involve MSRP as well as
other media types. The conference focus is responsible for relaying
session-based instant messages received from one participant to all
the other participants.
A session-based instant messages conference is sometimes also
referred to as a chat room, and the conference focus is sometimes
referred to as the chat room server. Several of these types of
systems already exist in the Internet. Participants in a chat room
can use a rich set of features, such as the ability of sending
private instant messages to one or more participants, or to establish
sub-conferences within the existing conference.
The aim of this document is provide requirements in support for
conferences of session-based instant messages, private messaging, and
sidebars. The aim of this document is to trigger the discussion and
create solutions according to these requirements.
2. Terminology
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 RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations.
This memo deals with a particular case of tightly coupled SIP
conferences where the media exchanged consist of session-based
instant messages. Unless otherwise noted, we use the terminology
defined in the Framework for Conferencing with SIP [I-D.ietf-sipping-
conferencing-framework] applied to the scope of this document. In
addition to that terminology, we introduce some new terms:
Nickname: a descriptive name associated to a participant. A
nickname is non-routable pseudonym that the participant chooses
for the purpose of additional identification towards the rest of
the participants.
Garcia-Martin & Niemi Expires January 1, 2006 [Page 3]
Internet-Draft Multiparty MSRP June 2005
Session-based instant messages conference: a particular case of a
tightly coupled conference (as defined by the Framework for
Conferencing with SIP [I-D.ietf-sipping-conferencing-framework])
where the media exchanged between the participants consist of
session based instant messages transported with MSRP [I-D.ietf-
simple-message-sessions]. Typically a session based message
conference is referred to as a chat room.
Chat room: a synonym of a session-based instant messages conference.
Creator or message creator: the user that originally created a
message and sent it to the chat room for further distribution.
The creator can be identified by a SIP URI or a nickname.
MSRP switch: an MSRP endpoint that receives MSRP messages and
redistributes them to each conference participant as appropriate.
An MSRP switch has a similar role as a mixer (as defined by
RFC 3550 [RFC3550], however an MSRP switch does not combine
different input media streams; it merely distributes incoming
MSRP messages to the conference participants. The media mixer
function defined by the Framework and Data Model for Centralized
Conferencing [I-D.ietf-xcon-framework] is slightly different from
the one define in RFC 3550 [RFC3550], in the sense that it does
not necessarily allow combination of media, therefore, allowing an
MSRP switch to be considered a logical subfunction of such media
mixer. For clarity this document defines the term MSRP switch to
refer to that logical subfunction within the media mixer.
Private instant message: a session based instant message whose
intended list of destinations is explicitly signaled and is a
subset of the conference participants, rather than all the
participants of the conference.
3. Motivation
Although conference frameworks describing many types of conferencing
applications already exist, such as the Framework and Data Model for
Centralized Conferencing [I-D.ietf-xcon-framework] and the Framework
for Conferencing with SIP [I-D.ietf-sipping-conferencing-framework],
conferences of session-based messages do not seem to be covered in
detail. It seems beneficial to provide a set of requirements that
can lead to the creation of features that enhance conferences for
session-based messages in order to compete in functionality with
existing session-based instant messages conference systems.
Garcia-Martin & Niemi Expires January 1, 2006 [Page 4]
Internet-Draft Multiparty MSRP June 2005
4. Requirements
These requirements assume a centralized conference architecture, such
as the one defined by the Framework and Data Model for Centralized
Conferencing [I-D.ietf-xcon-framework] or the Framework for
Conferencing with SIP [I-D.ietf-sipping-conferencing-framework]. We
assumed the existence of a focus and an MSRP switch. Assuming so, we
define the following requirements:
4.1 General Requirements
REQ-GEN-1: There must be a general mechanism where by a participant
of a conference sends session based instant messages to
the rest of the participants of the conference.
REQ-GEN-2: The session based instant message media in a conference
must not interfere with other potential media in the same
conference: the conference can host other medias than
session based instant messages.
REQ-GEN-3: The mechanisms developed to support these requirements
should make use of the mechanisms developed within the
context of the Framework and Data Model for Centralized
Conferencing [I-D.ietf-xcon-framework].
REQ-GEN-4: New mechanisms that may be required to support these
requirements should be developed in consideration of
applicability to other media types, as appropriate.
REQ-GEN-5: It must be possible that participants join or leave a
particular session-based instant messages conference.
REQ-GEN-6: It must be possible to inform the creator of a session
based instant messages conference about the acceptance of
the message for distribution. Note that there is no
requirement to inform the creator that the message has
been delivered to each participant.
REQ-GEN-7: It must be possible to get the time-stamp at which the
MSRP switch dispatched a message.
REQ-GEN-8: It must be possible that a participant uses the
conference service in conjunction with an anonymizing
function, in particular, it must be possible that the
sender hides their permanent identity (e.g., SIP AOR) or
routing towards their identity to the rest of the
conference participants but still be able to receive
private messages from other participants.
REQ-GEN-9: On sending a session based message to the conference it
must be possible that a message creator discloses one of
their non-routable identities (such as a nickname) to the
MSRP switch.
Garcia-Martin & Niemi Expires January 1, 2006 [Page 5]
Internet-Draft Multiparty MSRP June 2005
REQ-GEN-10: On sending a session based message to the conference it
must be possible that a message creator indicates the
MSRP switch whether to disclose or not their non-routable
identity (such as a nickname) to the rest of the
participants.
REQ-GEN-11: Providing that the creator of a message is willing to
disclose their permanent routable identity, the MSRP
mixer must deliver the creator's permanent routable
identity to each recipient.
REQ-GEN-12: Providing that the creator of a message is willing to
disclose their nickname, the MSRP mixer must deliver the
creator's nickname to each recipient.
REQ-GEN-13: It must be possible to set up a sidebar conference with
one or more participants of the conference.
REQ-GEN-14: Mechanisms should optimize the efficiency of the MSRP
switch when it manipulates a session based instant
message.
4.2 Private Messaging Requirements
REQ-PRIV-1: It must be possible that the creator of a message sends a
message to one or more conference participants (a subset
of the conference roster), as opposed to the whole
conference roster (a.k.a. a private instant message).
REQ-PRIV-2: In order to preserve the "instant" experience of the
user, the mechanism developed to send private instant
messages should not impose an more than the following
delay in the delivery of the messages, in comparison with
messages addressed to the whole conference roster:
* the first private message to a particular recipient
should, on average, take no more than 500 milliseconds
longer than a message to the conference as a whole.
* subsequent private messages to a particular recipient
should, on the average, take no more than 50
milliseconds longer than a message to the conference
as a whole.
REQ-PRIV-3: A conference participant must be able to determine the
target of the received message. For instance, a
conference participant that receives a session based
message must be able to determine whether the message was
addressed to the whole conference roster, a sidebar
conference or just a subset of the roaster (private
messages).
REQ-PRIV-4: On sending private messages, it must be possible that the
creator sends private messages to participants who have
only revealed their nickname, but not their permanent
routable identity.
Garcia-Martin & Niemi Expires January 1, 2006 [Page 6]
Internet-Draft Multiparty MSRP June 2005
REQ-PRIV-5: It must be possible that the MSRP switch is a contributor
that sends messages to the participants (e.g., message of
the day, welcome message, server is shutting down, etc.)
REQ-PRIV-6: A session based instant messages conference or sidebar
conference can be characterized with a topic whose
purpose is to identify the subject of conversation.
REQ-PRIV-7: A user with the appropriate privileges must be able to
set and modify the topic of the conference or sidebar
conference.
5. Acknowledgements
The authors would like to thank Paul Kyzivat, Dave Oran, Eric Burger,
and Mary Barnes for their comments.
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[I-D.ietf-sipping-conferencing-framework]
Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol",
draft-ietf-sipping-conferencing-framework-05 (work in
progress), May 2005.
[I-D.ietf-xcon-framework]
Barnes, M., "A Framework and Data Model for Centralized
Conferencing", draft-ietf-xcon-framework-00 (work in
progress), May 2005.
[I-D.ietf-simple-message-sessions]
Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-10 (work in progress),
February 2005.
Garcia-Martin & Niemi Expires January 1, 2006 [Page 7]
Internet-Draft Multiparty MSRP June 2005
Authors' Addresses
Miguel A. Garcia-Martin
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 480 4586
Email: miguel.an.garcia@nokia.com
Aki Niemi
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
Email: aki.niemi@nokia.com
Garcia-Martin & Niemi Expires January 1, 2006 [Page 8]
Internet-Draft Multiparty MSRP June 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Garcia-Martin & Niemi Expires January 1, 2006 [Page 9]
