One document matched: draft-garcia-xcon-private-messaging-reqs-00.txt
Network Working Group M. Garcia-Martin
Internet-Draft A. Niemi
Expires: September 28, 2005 Nokia
March 27, 2005
Requirements for private messaging in centralized conference
environements
draft-garcia-xcon-private-messaging-reqs-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 September 28, 2005.
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
Garcia-Martin & Niemi Expires September 28, 2005 [Page 1]
Internet-Draft Multiparty MSRP March 2005
requirements in support for MSRP in centralized conferences,
including requirements to provide private instant messages within a
conference.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 General Requirements . . . . . . . . . . . . . . . . . . . 5
4.2 Private Messaging Requirements . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Garcia-Martin & Niemi Expires September 28, 2005 [Page 2]
Internet-Draft Multiparty MSRP March 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 messaging 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 messaging. Unless otherwise noted, we use the terminology
defined in the SIP Conferencing Framework [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 September 28, 2005 [Page 3]
Internet-Draft Multiparty MSRP March 2005
Session-based instant messaging conference: a particular case of a
tightly coupled conference (as defined by the SIP Conferencing
Framework [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 messaging
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 the
SIP Conferencing Framework [I-D.ietf-sipping-conferencing-
framework]), however an MSRP switch does not combine different
input media streams; it merely distributes incoming MSRP messages
to the conference participants.
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.barnes-xcon-framework] and the SIP
Conferencing Framework [I-D.ietf-sipping-conferencing-framework],
conferences of session-based messaging 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 messaging conference systems.
4. Requirements
We are assuming an centralized conference architecture composed of a
focus and an MSRP switch. Assuming so, we define the following
requirements:
Garcia-Martin & Niemi Expires September 28, 2005 [Page 4]
Internet-Draft Multiparty MSRP March 2005
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 messaging.
REQ-GEN-3: Mechanisms developed to support these requirements should
also be feasible, if applicable, to other media types.
REQ-GEN-4: It must be possible that participants join or leave a
particular session-based instant messaging conference.
REQ-GEN-5: It must be possible to inform the creator of a session
based messaging about the acceptance of the message for
distribution.
REQ-GEN-6: It must be possible to get the time-stamp at which the
MSRP switch dispatched a message.
REQ-GEN-7: The message sequence witnessed by different endpoints
must be identical across all the participants.
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 a
participant of the conference only reveals a non-routable
identity (e.g., nickname) to the rest of the conference
participants, but it does not reveal a routable identity
(e.g., SIP-AOR).
REQ-GEN-9: On sending a session based message to the conference it
must be possible that a message creator discloses their
non-routable identity (such as a nickname) to the rest of
the participants.
REQ-GEN-10: Providing that the creator of a message is willing to
disclose their routable identity, a conference
participant that receives a session based instant message
must be able to determine the identity of the creator of
the message.
REQ-GEN-11: Providing that the creator of a message is willing to
disclose their nickname, a conference participant that
receives a session based instant message must be able to
determine the nickname of the creator of the message.
REQ-GEN-12: It must be possible to set up a sidebar conference with
one or more participants of the conference.
REQ-GEN-13: Mechanisms should optimize the efficiency of the MSRP
switch when it manipulates a session based instant
message.
Garcia-Martin & Niemi Expires September 28, 2005 [Page 5]
Internet-Draft Multiparty MSRP March 2005
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 (aka 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 extra delay in the delivery
of the message in comparison with messages addressed to
the whole conference roster.
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 might be possible that
the creator sends private messages to participants who
have only revealed their nickname, but not their routable
identity.
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 messaging 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. 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.
[I-D.ietf-sipping-conferencing-framework]
Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol",
draft-ietf-sipping-conferencing-framework-03 (work in
progress), October 2004.
Garcia-Martin & Niemi Expires September 28, 2005 [Page 6]
Internet-Draft Multiparty MSRP March 2005
[I-D.barnes-xcon-framework]
Barnes, M. and C. Boulton, "A Framework and Data Model for
Centralized Conferencingg", draft-barnes-xcon-framework-01
(work in progress), December 2004.
[I-D.ietf-simple-message-sessions]
Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-09 (work in progress),
October 2004.
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 September 28, 2005 [Page 7]
Internet-Draft Multiparty MSRP March 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 September 28, 2005 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 04:19:52 |