One document matched: draft-niemi-simple-chat-05.txt
Differences from draft-niemi-simple-chat-04.txt
Network Working Group A. Niemi
Internet-Draft M. Garcia-Martin
Expires: December 23, 2006 Nokia Research Center
June 21, 2006
Multi-party Instant Message (IM) Sessions Using the Message Session
Relay Protocol (MSRP)
draft-niemi-simple-chat-05
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 December 23, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Message Session Relay Protocol (MSRP) defines a mechanism for
sending instant messages within a peer-to-peer session, negotiated
using the Session Initiation Protocol (SIP) and the Session
Description Protocol (SDP). This document defines the necessary
tools for establishing multi-party instant messaging (IM) sessions,
or chat rooms, using the centralized conferencing model.
Niemi & Garcia-Martin Expires December 23, 2006 [Page 1]
Internet-Draft Multiparty MSRP June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations and Requirements . . . . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
5. Creating, Joining, and Destroying a Chat Room . . . . . . . . 8
5.1. Creating a Chat Room . . . . . . . . . . . . . . . . . . . 8
5.2. Joining a Chat Room . . . . . . . . . . . . . . . . . . . 8
5.3. Destroying a Chat Room . . . . . . . . . . . . . . . . . . 8
6. Sending and Receiving Instant Messages . . . . . . . . . . . . 9
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Niemi & Garcia-Martin Expires December 23, 2006 [Page 2]
Internet-Draft Multiparty MSRP June 2006
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] in combination with the Session Description Protocol (SDP)
[RFC3264] allows for two peers to establish and manage such sessions.
In another application of SIP, a user agent can join in a multi-party
session or conference that is hosted by a specialized user agent
called a conference focus [RFC4353]. Such a conference can naturally
involve an MSRP session as one of possibly many media components. It
is the responsibility of an entity handling the media to relay
instant messages received from one participant to the rest of the
participants in the conference.
Participants in a chat room can be identified with a pseudonym or
nickname, and decide whether their real identity is disclosed to
other participants. Participants can also use a rich set of
features, such as the ability to send private instant messages to one
or more participants, and the ability to establish sub-conferences
with one or more of the participants within the existing conference.
They also allow combining instant messaging with other media
components, such as voice, video, whiteboarding, screen sharing, and
file transfer.
Such conferences are already available today with other technologies
different than MSRP. For example, Internet Relay Chat (IRC)
[RFC2810], Extensible Messaging and Presence Protocol [RFC3920] based
chat rooms, and many other proprietary systems provide this kind of
functionality. It makes sense to specify equivalent functionality
for MSRP-based systems to both provide competitive features as well
as enable interworking between the systems.
The aim of this document is to define requirements, conventions and
extensions for enabling features similar to many of these existing
systems in the Internet, namely the Internet Relay Chat (IRC)
[RFC2810] and Extensible Messaging and Presence Protocol [RFC3920]
Multi-User Chat [JEP-0045].
This memo uses the SIP Conferencing Framework [RFC4353] as a design
basis. It also aims to be compatible with the Centralized
Conferencing Framework [I-D.ietf-xcon-framework]. Where appropriate,
some features are specified generically to all conference types.
This specification will discuss applying those generic mechanisms in
the context of multiparty chats.
Niemi & Garcia-Martin Expires December 23, 2006 [Page 3]
Internet-Draft Multiparty MSRP June 2006
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, BCP 14
[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 [RFC4353] applied to the
scope of this document. In addition to that terminology, we
introduce some new terms:
Session-based Instant Messaging Conference: an instance of a tightly
coupled conference, in which the media exchanged between the
participants consist of (among others) MSRP based instant
messages. This term refers to all types of conferences: long-
lasting as well as ad-hoc conferences. Also known as a chat room.
Chat Room: a synonym for session-based instant messaging conference.
Chat Room URI: a URI that identifies a particular chat room in a
conference server. Since a chat room is a specialized conference
of instant messages, in the context of this document, a chat room
URI is a synonym of a conference URI.
Conference Server: a (possibly decomposed) server that provides
multipart text conference services. It is also the combination of
a conference focus and an MSRP switch.
Sender: the conference participant that originally created an
instant message and sent it to the chat room for delivery.
Recipient: the destination conference participant(s). This defaults
to the full conference participant list, minus the IM Sender.
MSRP switch: a media level entity that receives MSRP messages and
delivers them to the other conference participants. An MSRP
switch has a similar role to a conference mixer with the exception
that an MSRP switch does not actually "mix" together different
input media streams; it merely relays the messages between
participants.
Niemi & Garcia-Martin Expires December 23, 2006 [Page 4]
Internet-Draft Multiparty MSRP June 2006
3. Motivations and Requirements
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 SIP
Conferencing Framework [RFC4353], the exact details of session-based
instant messaging conferences are not well-defined at the moment.
To allow interoperable chat implementations, for both conference-
aware, and conference-unaware user agents, certain conventions for
MSRP conferences need to be defined. It also seems beneficial to
provide a set of features that enhance the baseline multiparty MSRP
in order to be able to create systems that have functionality on par
with existing chat systems, as well as enable building interworking
gateways to these existing chat systems.
A number of requirements that enrich the session based messaging
conferences have already been described in Requirements for Instant
Messaging in 3GPP Wireless Systems [I-D.niemi-simple-im-wireless-
reqs] or the Advanced Instant Messaging Requirements for the Session
Initiation Protocol [I-D.rosenberg-simple-messaging-requirements].
In addition, we define the following requirements:
Note that some of the requirements listed herein are not addressed
by this document, but in other I-Ds possibly discussed in other
working groups.
REQ-1: The conference must have the ability to host other media in
addition to MSRP, as well as multiple streams of MSRP.
REQ-2: A conference participant must be able to determine the
identities of the sender and recipient of the received IMs.
For instance, the recipient of the message might be the
entire conference, a conference sidebar or a single
participant of the conference (i.e., a private message).
REQ-3: It must be possible to send a message to a single
participant, or a subset of the conference participants
(i.e., a private instant message).
REQ-4: It must be possible to set up a sidebar session with one or
more participants of the chat room.
REQ-5: A conference participant may have a nickname or pseudonym
associated with their real identity.
Niemi & Garcia-Martin Expires December 23, 2006 [Page 5]
Internet-Draft Multiparty MSRP June 2006
REQ-6: It must be possible for a participant to change their
nickname during the progress of the conference.
REQ-7: It must be possible that a participant is only known by their
nickname and not their real identity to the rest of the
conference.
REQ-8: It must be possible for the MSRP switch itself to send IMs to
the conference (e.g., message of the day, welcome messages,
server is shutting down, etc.)
REQ-9: A chat room, or a chat room sidebar must be able to be
characterized with a topic whose purpose is to identify the
subject of conversation.
REQ-10: A user with the appropriate privileges must be able to set
and/or modify the topic of the chat room, or chat room
sidebar.
4. Overview of Operation
In order to set up a conference, one must first be created. Users
wishing to host a conference themselves can of course do just that;
their user agents simply morph from an ordinary user agent into a
special purpose one called a conference focus. Another commonly used
setup is one where a dedicated node in the network functions as a
conference focus.
Each chat room has an identity of its own: a SIP URI that
participants use to join the conference, e.g., by sending an INVITE
request. The conference focus processes the invitations, and as
such, maintains SIP dialogs with each participant. In an instant
messaging conference, or chat room, MSRP is one of the established
media streams. Each conference participant establishes an MSRP
session with an MSRP switch, which is a special purpose MSRP
application. The MSRP switch is similar to a conference mixer in
that it handles media sessions with each of the participants and
bridges these streams together. However, unlike a conference mixer,
the MSRP switch merely relays messages between participants but
doesn't actually mix the streams in any way. The system is
illustrated in Figure 1.
Niemi & Garcia-Martin Expires December 23, 2006 [Page 6]
Internet-Draft Multiparty MSRP June 2006
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
Figure 1: Multiparty MSRP in a Centralized Conference
Typically conference participants also subscribe to the conference
event package [I-D.ietf-sipping-conference-package] to gather
information about the conference roster in the form of conference
state notifications. For example, participants can learn about other
participants' identities.
All messages in the chat room use the 'multipart/mixed' MIME type to
accommodate a 'Message/CPIM' wrapper content type [RFC3862] .When a
participant wants to send an instant message to the conference, it
constructs an MSRP SEND request and submits it to the MSRP switch
including a regular payload (e.g., a Message/CPIM message that
contains a text, html, an image, etc.). The Message/CPIM To header
is set to the chat room URI. The switch then fans out the SEND
request to all of the other participants using their existing MSRP
sessions.
A participant can also send a private instant message addressed to
one or more conference participants whose identities have been
learnt, e.g., via a notification from the conference event package
[I-D.ietf-sipping-conference-package]. Procedures for private
messaging are described in separate documents.
Naturally, when a participant wishes to leave a chat room, it sends a
Niemi & Garcia-Martin Expires December 23, 2006 [Page 7]
Internet-Draft Multiparty MSRP June 2006
SIP BYE request to the conference focus and disconnects.
5. Creating, Joining, and Destroying a Chat Room
5.1. Creating a Chat Room
Since we consider a chat room a particular type of conference where
one of the offered media happens to be MSRP, the methods defined by
the SIP Conference Framework [RFC4353] for creating conferences are
directly applicable to a chat room.
Once a chat room is created, it is identified by a SIP URI, like any
other conference.
5.2. Joining a Chat Room
Participants usually join the conference by sending an INVITE request
to the conference URI. As long as the conference policy allows, the
INVITE request is accepted by the focus and the user is brought into
the conference. Participants are aware that the peer is a focus due
to the presence of the "isfocus" feature tag [RFC3840] in the Contact
header field of the 200-class response to the INVITE request.
Participants are also aware that the mixer is an MSRP switch due to
the presence of an additional 'message' media type and either TCP/
MSRP or TCP/TLS/MSRP as the protocol field in the SDP [RFC2327]
media-line.
The conference focus of a chat room MUST include support for a
Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by
setting the 'accept-types' MSRP media line attribute in the SDP offer
or answer to include 'Message/CPIM'.
Note that the 'Message/CPIM' wrapper is used to carry the sender
information that, otherwise, it will not be available to the
recipient. Additionally, 'Message/CPIM' wrapper carries the
recipient information (e.g., To and Cc: headers).
5.3. Destroying a Chat Room
As with creating a conference, the methods defined by the SIP
Conference Framework [RFC4353] for destroying a conference are
directly applicable to a chat room.
Destroying a chat room is an action that heavily depends on the
policy of the chat room. The policy can determine that the chat room
is destroyed when the creator leaves the conference, or with any out
of band mechanism.
Niemi & Garcia-Martin Expires December 23, 2006 [Page 8]
Internet-Draft Multiparty MSRP June 2006
6. Sending and Receiving Instant Messages
This section describes the conventions used to send and receive
instant messages that are addressed to all the participants in the
chat room. These are sent over a regular MSRP SEND request that
contains a Message/CPIM wrapper [RFC3862] and the desired payload
(e.g., text, image, video-clip, etc.).
When a chat room participant wishes to send an instant message to all
the other participants in the chat room, he constructs an MSRP SEND
request that MUST contain a top-level wrapper of type 'Message/CPIM'
[RFC3862]. The actual instant message payload inside 'Message/CPIM'
MAY be of any type negotiated in the SDP 'accept-types' attribute
according to the MSRP rules.
The sender SHOULD populate the From header of the Message/CPIM
wrapper with a proper identity by which the user is recognized in the
conference. Identities that can be used (among others) are:
o A SIP URI [RFC3261] representing the sender's address-of-record
o A tel URI [RFC3966] representing the sender's telephone number
o An IM URI [RFC3860] representing the sender's instant messaging
address
If the sender of the message wants to remain anonymous to the rest of
the participants, and providing that the policy of the conference
allows anonymous participation, the creator SHOULD populate the From
header of the Message/CPIM body with an anonymous identity, e.g.,
using the "anonymous" SIP URI as described in RFC 3261 [RFC3261]
Section 8.1.1.3.
The sender MUST populate the To header field of the Message/CPIM body
with the chat room URI.
An MSRP switch that receives a SEND request from a participant SHOULD
first verify that the From header field of the Message/CPIM wrapper
is correctly populated with a valid URI as indicated earlier. If the
URI included in the From header field of the Message/CPIM wrapper is
not valid (e.g, because it does not "belong" to the user), then the
MSRP switch MUST generate a 403 response and MUST NOT forward the
SEND request to any of the participants. Otherwise, the MSRP switch
SHOULD generate a 200 response according to the MSRP rules for
response generation.
Then the MSRP switch should inspect the To header field of the
Message/CPIM wrapper. If the To header field of the Message/CPIM
Niemi & Garcia-Martin Expires December 23, 2006 [Page 9]
Internet-Draft Multiparty MSRP June 2006
wrapper contains the chat room URI, the MSRP switch generates a copy
of the SEND request to each of the participants in the conference
except the sender. The MSRP switch MUST NOT modify any of the bodies
included in the received SEND request. Note that the MSRP switch
does not need to wait for the reception of the complete MSRP chunk or
MSRP message before it starts the distribution to the rest of the
participants. Instead, once the MSRP switch has received the headers
of the Message/CPIM body it is able to start the distribution
process.
The MSRP switch is required to examine the To header field of the
Message/CPIM wrapper in order to determine whether the message is
addressed to the whole roster (i.e., it is the chat room URI) or
to a subset of it (e.g., a sidebar or a private message).
An MSRP endpoint that receives a SEND request from an MSRP switch
containing a Message/CPIM wrapper SHOULD first inspect the To header
field of the Message/CPIM body. If the To header field is set to the
chat room URI, then it is a regular message that has been distributed
to all the participants in the conference. Then the MSRP endpoint
SHOULD inspect the From header field of the Message/CPIM body to
identify the sender. The From header field will include a URI that
identifies the sender. The endpoint might have also received further
identity information through a subscription to the SIP conference
event package [I-D.ietf-sipping-conference-package].
7. Examples
TBD.
8. IANA Considerations
None.
9. Security Considerations
This document proposes extensions to the Message Session Relay
Protocol [I-D.ietf-simple-message-sessions]. Therefore, the security
considerations of such document apply to this document as well.
In general, messages sent to a multi-party session based messaging
focus are not deem to expose any security threat. Nevertheless, if a
participant wants to avoid eavesdropping from non authorized
entities, it should send those messages a TLS [RFC2246] transport
connection, as allowed by MSRP.
Niemi & Garcia-Martin Expires December 23, 2006 [Page 10]
Internet-Draft Multiparty MSRP June 2006
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[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.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3860] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[I-D.ietf-xcon-framework]
Barnes, M., "A Framework and Data Model for Centralized
Conferencing", draft-ietf-xcon-framework-04 (work in
progress), June 2006.
[I-D.ietf-simple-message-sessions]
Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-14 (work in progress),
February 2006.
Niemi & Garcia-Martin Expires December 23, 2006 [Page 11]
Internet-Draft Multiparty MSRP June 2006
10.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[JEP-0045]
Saint-Andre, P., "Multi-User Chat", JSF JEP 0045,
September 2005.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
April 2000.
[I-D.niemi-simple-im-wireless-reqs]
Niemi, A., "Requirements for Instant Messaging in 3GPP
Wireless Systems", draft-niemi-simple-im-wireless-reqs-02
(work in progress), October 2003.
[I-D.rosenberg-simple-messaging-requirements]
Rosenberg, J., "Advanced Instant Messaging Requirements
for the Session Initiation Protocol (SIP)",
draft-rosenberg-simple-messaging-requirements-01 (work in
progress), February 2004.
[I-D.ietf-sipping-conference-package]
Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State",
draft-ietf-sipping-conference-package-12 (work in
progress), July 2005.
Niemi & Garcia-Martin Expires December 23, 2006 [Page 12]
Internet-Draft Multiparty MSRP June 2006
Authors' Addresses
Aki Niemi
Nokia Research Center
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
Email: aki.niemi@nokia.com
Miguel A. Garcia-Martin
Nokia Research Center
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 480 4586
Email: miguel.an.garcia@nokia.com
Niemi & Garcia-Martin Expires December 23, 2006 [Page 13]
Internet-Draft Multiparty MSRP June 2006
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 (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Niemi & Garcia-Martin Expires December 23, 2006 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 21:45:34 |