[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-niemi-simple-chat) 00 01 02
03 04 05 06 07 08 09 10 11 12 13 14
15 16 17 18 RFC 7701
Network Working Group A. Niemi
Internet-Draft Nokia
Intended status: Standards Track M. Garcia-Martin
Expires: July 26, 2012 Ericsson
G. Sandbakken, Ed.
Cisco Systems
January 23, 2012
Multi-party Chat Using the Message Session Relay Protocol (MSRP)
draft-ietf-simple-chat-13
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 chat sessions, or chat rooms,
using MSRP.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 26, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Niemi, et al. Expires July 26, 2012 [Page 1]
Internet-Draft Multi-party Chat MSRP January 2012
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Niemi, et al. Expires July 26, 2012 [Page 2]
Internet-Draft Multi-party Chat MSRP January 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations and Requirements . . . . . . . . . . . . . . . . . 6
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
5. Creating, Joining, and Deleting a Chat Room . . . . . . . . . 10
5.1. Creating a Chat Room . . . . . . . . . . . . . . . . . . . 10
5.2. Joining a Chat Room . . . . . . . . . . . . . . . . . . . 10
5.3. Deleting a Chat Room . . . . . . . . . . . . . . . . . . . 11
6. Sending and Receiving Instant Messages . . . . . . . . . . . . 12
6.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 12
6.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 13
6.3. MSRP reports and responses . . . . . . . . . . . . . . . . 15
7. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Using Nicknames within a Conference . . . . . . . . . . . 16
7.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 18
7.3. Removing a Nickname . . . . . . . . . . . . . . . . . . . 18
7.4. Nicknames in Conference Event Packages . . . . . . . . . . 18
8. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . . . 18
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 21
9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 23
9.3. Sending a regular message to the chat room . . . . . . . . 24
9.4. Sending a private message to a participant . . . . . . . . 26
9.5. Chunked private message . . . . . . . . . . . . . . . . . 27
9.6. Nickname in a conference information document . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10.1. New MSRP Method . . . . . . . . . . . . . . . . . . . . . 29
10.2. New MSRP Header . . . . . . . . . . . . . . . . . . . . . 30
10.3. New MSRP Status Codes . . . . . . . . . . . . . . . . . . 30
10.4. New SDP Attribute . . . . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. Normative References . . . . . . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Niemi, et al. Expires July 26, 2012 [Page 3]
Internet-Draft Multi-party Chat MSRP January 2012
1. Introduction
The Message Session Relay Protocol (MSRP) [RFC4975] 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) [RFC4566] allows for two peers
to establish and manage such sessions.
In another application of SIP, a user agent can join in a multi-party
conversation called a conference that is hosted by a specialized user
agent called a focus [RFC4353]. Such a conference can naturally
involve MSRP sessions. 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.
Several such systems already exist in the Internet. Participants in
a chat room can be identified with a pseudonym or nickname, and
decide whether their real identifier is disclosed to other
participants. Participants can also use a rich set of features such
as the ability to send private instant messages to other
participants.
Similar conferences supporting chat rooms are already available
today. For example, Internet Relay Chat (IRC) [RFC2810], Extensible
Messaging and Presence Protocol (XMPP): Core [RFC6120] based chat
rooms, and many other proprietary systems provide chat room
functionality. Specifying equivalent functionality for MSRP-based
systems provides competitive features and enables interworking
between the systems.
This document defines requirements, conventions, and extensions for
providing private messages and nickname management in centralized
conferences with MSRP. Participants in a chat room can be identified
by a pseudonym, and decide if their real identifier is disclosed to
other participants. This memo uses the SIP Conferencing Framework
[RFC4353] as a design basis. It also aims to be compatible with the
A Framework for Centralized Conferencing [RFC5239]. Should
requirements arise, future mechanisms for providing similar
functionality in generic conferences might be developed, for example,
where the media is not only restricted to MSRP. The mechanisms
described in this document provide a future compatible short-term
solution for MSRP centralized conferences.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Niemi, et al. Expires July 26, 2012 [Page 4]
Internet-Draft Multi-party Chat MSRP January 2012
document are to be interpreted as described in RFC 2119, BCP 14
[RFC2119], and indicate requirement levels for compliant
implementations.
This memo deals with tightly coupled SIP conferences defined in SIP
Conferencing Framework [RFC4353] and adopts the terminology from that
document. In addition to that terminology, we introduce some new
terms:
Nickname: a pseudonym or descriptive name associated to a
participant. See Section 7 for details
Multi-party chat: an instance of a tightly coupled conference, in
which the media exchanged between the participants consist of MSRP
based instant messages. Also known as a chat room.
Chat Room: a synonym for a multi-party chat.
Chat Room URI: a URI that identifies a particular chat room, and is
a synonym of a Conference URI defined in RFC 4353 [RFC4353].
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 is a MSRP endpoint. It is a
special MSRP endpoint that receives MSRP messages, and delivers
them to the other conference participants. The MSRP switch has a
similar role to a conference mixer with the exception that the
MSRP switch does not actually "mix" together different input media
streams; it merely relays the messages between participants.
Private Instant Message: an instant message sent in a chat room
intended for a single participant. A private IM is usually
rendered distinctly from the rest of the IMs, indicating that the
message was a private communication.
Anonymous URI: a URI concealing the participant's SIP AOR from the
other participants in the conference. The allocation of such a
URI is out of scope of this specification. An anonymous URI must
be valid for the length of the conference, and will be utilized by
the MSRP switch to forward messages to and from anonymous
participants.
Niemi, et al. Expires July 26, 2012 [Page 5]
Internet-Draft Multi-party Chat MSRP January 2012
Conference Event Package: a notification mechanism that allows
conference participants to learn conference information including
roster and state changes in a conference. This would typically be
A Session Initiation Protocol (SIP) Event Package for Conference
State [RFC4575] or Conference Event Package Data Format Extension
for Centralized Conferencing [I-D.ietf-xcon-event-package].
3. Motivations and Requirements
Although conference frameworks describing many types of conferencing
applications already exist, such as the Framework for Centralized
Conferencing [RFC5239] 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 multi-party 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.
We define the following requirements:
REQ-1: A basic requirement is the existence of a multi-party
conference, where participants can join and leave the
conference and get instant messages exchanged to the rest of
the participants.
REQ-2: A conference participant must be able to determine the
identifiers of the sender and recipient of the received IMs.
Note that the actual identifiers depend no those which were
selected by the sender or recipient when he or she joined the
conference.
REQ-3: A conference participant must be able to determine the
recipient of the received message. For instance, the
recipient of the message might be the entire conference or a
single participant of the conference (i.e., a private
message).
REQ-4: It must be possible to send a message to a single participant
within the conference (i.e., a private instant message).
Niemi, et al. Expires July 26, 2012 [Page 6]
Internet-Draft Multi-party Chat MSRP January 2012
REQ-5: A conference participant may have a nickname or pseudonym
associated with their real identifier.
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 an
anonymous identifier and not their real identifier to the
rest of the conference.
REQ-8: It must be possible for the conference participants to learn
the chat room capabilities described in this document.
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 Agent (UA) simply morphs from an ordinary UA into a
special purpose one called a Focus UA. Another, commonly used setup
is one where a dedicated node in the network functions as a Focus UA.
Each chat room has an identifier 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 a multi-party
chat, or chat room, MSRP is one of the established media streams.
Each conference participant establishes an MSRP session with the MSRP
switch, which is a special purpose MSRP application. The MSRP
sessions can be relayed by one or more MSRP relays, which are
specified in RFC 4976 [RFC4976]. This is illustrated in Figure 1
Niemi, et al. Expires July 26, 2012 [Page 7]
Internet-Draft Multi-party Chat MSRP January 2012
MSRP Sessions
+---------------------------+
| +-----------+ |
+---+--+ +---+--+ | |
| SIP | | SIP | | |
| MSRP | | MSRP | +--+---+----+
|Client| |Client| | MSRP |
+---+--+ ++-----+ | Relay |
| | +-----+-----+
SIP Dialogs | / |
| | | MSRP Sessions
+----+------+--+ |
| Conference | +-------+-----+
| Focus UA | | MSRP |
| |........| Switch |
| | | |
+---+--------+-+ +-------+-----+
| \ |
SIP Dialogs | | | MSRP Sessions
| \ |
+--+---+ +-+----+ +-----+------+
| SIP | | SIP | | MSRP |
| MSRP | | MSRP | | Relay |
|Client| |Client| +-+-------+--+
+---+--+ +--+---+ | |
| +-----------+ |
+------------------------------+
MSRP sessions
Figure 1: Multi-party chat overview shown with MSRP Relays and a
conference Focus UA
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 forwards messages between participants but doesn't
actually mix the streams in any way. The system is illustrated in
Figure 2.
Niemi, et al. Expires July 26, 2012 [Page 8]
Internet-Draft Multi-party Chat MSRP January 2012
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
Figure 2: Multi-party chat in a Centralized Conference
Typically conference participants also subscribe to a conference
event package to gather information about the conference roster in
the form of conference state notifications. For example,
participants can learn about other participants' identifiers,
including their nicknames.
All messages in the chat room use the 'Message/CPIM' wrapper content
type [RFC3862], so that it is possible to distinguish between private
and regular messages. 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 a
participant whose identifier has been learned, e.g. via a conference
event package. In this case the sender creates an MSRP SEND request
with a Message/CPIM wrapper whose To header contains not the chat
room URI but the recipient's URI. The MSRP switch then forwards the
SEND request to that recipient. This specification supports the
sending of private messages to one and only one recipient. However,
Niemi, et al. Expires July 26, 2012 [Page 9]
Internet-Draft Multi-party Chat MSRP January 2012
if the recipient is logged from different endpoints, the MSRP switch
will distribute the private message to each endpoint the recipient is
logged.
We extend the current MSRP negotiation that takes place in SDP
[RFC4566] to allow participants to learn whether the chat room
supports and is willing to accept (e.g. due to local policy
restrictions) certain MSRP functions defined in this memo, such as
nicknames or private messaging.
Naturally, when a participant wishes to leave a chat room, it sends a
SIP BYE request to the Focus UA and terminates the SIP dialog with
the focus and MSRP sessions with the MSRP switch.
This document assumes that each chat room is allocated its own SIP
URI. A user joining a chat room sends an INVITE request to that SIP
URI, and as a result, a new MSRP session is established between the
user and the MSRP switch. It is assumed that an MSRP session is
mapped to a chat room. If a user wants to join a second chat room,
he creates a different INVITE request, through a different SIP
dialog, which leads to the creation of a second MSRP session between
the user and the MSRP switch. Notice that these two MSRP sessions
can still be multiplexed over the same TCP connection as per regular
MSRP procedures. However, each chat room is associated to a unique
MSRP session and a unique SIP dialog.
5. Creating, Joining, and Deleting a Chat Room
5.1. Creating a Chat Room
Since we consider a chat room a particular type of conference having
MSRP media, 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.
The MSRP switch needs to be aware of the URIs of the participant
(SIP, Tel, or IM URIs) in order to validate messages sent from this
Niemi, et al. Expires July 26, 2012 [Page 10]
Internet-Draft Multi-party Chat MSRP January 2012
participant prior to their forwarding. This information is known to
the focus of the conference. Therefore an interface between the
focus and the MSRP switch is assumed. However, the interface between
the focus and the MSRP switch is outside the scope of this document.
Conference aware participants will detect 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.
Conference unaware participants will not notice it is a focus, and
can not apply the additional mechanisms defined in this document.
Participants are also aware that the mixer is an MSRP switch due to
the presence of a 'message' media type and either TCP/MSRP or TCP/
TLS/MSRP as the protocol field in the media line of SDP [RFC4566].
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).
If a participant wants to remain anonymous to the rest of the
participants in the conference, the participant's UA must provide an
anonymous URI to the conference focus. The URI will be used in the
From and To headers in the 'Message/CPIM' wrapper, and can be learned
by the other participants of the conference. Notice that in order
for the anonymity mechanism to work, the anonymous URI must not
reveal the participant's SIP AOR. The mechanism for acquiring an
anonymous URI is outside the scope of this specification.
The conference focus of a chat room MUST learn the chat room
capabilities of each participant that joins the chat room. The
conference focus MUST inform the MSRP switch of such support in order
to prevent the MSRP switch from distributing private messages to
participants who do not support private messaging. The recipient
would not be able to render the message as private, and any potential
reply would be sent to the whole chat room.
5.3. Deleting a Chat Room
As with creating a conference, the methods defined by the SIP
Conference Framework [RFC4353] for deleting a conference are directly
applicable to a chat room. The MSRP switch will terminate the MSRP
sessions with all the participants.
Niemi, et al. Expires July 26, 2012 [Page 11]
Internet-Draft Multi-party Chat MSRP January 2012
Deleting 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
deleted when the creator leaves the conference, or with any out of
band mechanism.
6. Sending and Receiving Instant Messages
6.1. Regular 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] that in turn contains 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, it constructs an MSRP SEND
request according to the procedures specified in RFC 4975 [RFC4975].
The sender MAY choose the desired MSRP report model (e.g., populate
the Success-Report and Failure-Report MSRP header fields).
The SEND request MUST contain a top-level wrapper of type 'Message/
CPIM' according to RFC 3862 [RFC3862]. The actual instant message
payload MUST be included as payload of the 'Message/CPIM' wrapper and
MAY be of any type negotiated in the SDP 'accept-types' attribute
according to the MSRP rules.
On sending a regular message the sender MUST populate the To header
of the Message/CPIM wrapper with the URI of the chat room. The
sender SHOULD populate the From header of the Message/CPIM wrapper
with a proper identifier by which the user is recognized in the
conference. Identifiers that can be used (among others) are:
o A SIP URI [RFC3261] representing the participant's address-of-
record
o A tel URI [RFC3966] representing the participant's telephone
number
o An IM URI [RFC3860] representing the participant's instant
messaging address
o An Anonymous URI representing the participant's anonymous address
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 of a participant. This
Niemi, et al. Expires July 26, 2012 [Page 12]
Internet-Draft Multi-party Chat MSRP January 2012
imposes a requirement for the focus of the conference to inform the
MSRP switch of the URIs by which the participant is known, in order
for the MSRP switch to validate messages. Section 6.3 provides
further information with the actions to be taken in case this
validation fails.
Then the MSRP switch should inspect the To header field of the
Message/CPIM wrapper. If the MSRP switch receives a message
containing several To header fields in the Message/CPIM wrapper the
MSRP switch MUST reject the MSRP SEND request with a 403 response, as
per procedures in RFC 4975 [RFC4975]. Then, if the To header field
of the Message/CPIM wrapper contains the chat room URI and there are
no other To header fields, the MSRP switch can generate a copy of the
SEND request to each of the participants in the conference except the
sender. The MSRP switch MUST NOT modify the content received in the
SEND request. However, the MSRP switch MAY re-chunk any of the
outbound MSRP SEND requests.
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 wrapper it SHOULD
start the distribution process. Having the header of the Message/
CPIM wrapper only in the first chunk, the MSRP switch MUST track the
Message-Id until the last chunk of the message has been distributed.
An MSRP endpoint that receives a SEND request from the MSRP switch
containing a Message/CPIM wrapper SHOULD first inspect the To header
field of the Message/CPIM wrapper. If the To header field is set to
the chat room URI, it should render it as 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 wrapper to identify the sender. The From header field will
include a URI that identifies the sender. The endpoint might have
also received further identifier information through a subscription
to a conference event package.
6.2. Private Messages
This section describes the conventions used to send and receive
private instant messages, i.e., instant messages that are addressed
to one participant of the chat room rather to all of them. A chat
room can signal support for private messages using the 'chatroom'
attribute in SDP (see Section 8 for details).
When a chat room participant wishes to send a private instant message
to a participant in the chat room, it follows the same procedures for
creating a SEND request as for regular messages (Section 6.1). The
Niemi, et al. Expires July 26, 2012 [Page 13]
Internet-Draft Multi-party Chat MSRP January 2012
only difference is that the MSRP endpoint MUST populate a single To
header of the Message/CPIM wrapper with the identifier of the
intended recipient. The identifier can be SIP, TEL, and IM URIs
typically learned from the information received in notifications of a
conference event package.
As for regular messages, 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
(i.e., the URI is a participant of this chat room). Section 6.3
provides further information with the actions to be taken in case
this validation fails.
Then the MSRP switch MUST inspect the To header field of the Message/
CPIM wrapper. If the MSRP switch receives a message containing
several To header fields in the Message/CPIM wrapper the MSRP switch
MUST reject the MSRP SEND request with a 403 response, as per
procedures in RFC 4975 [RFC4975]. Then the MSRP switch MUST verify
that the To header of the Message/CPIM wrapper matches the URI of a
participant of the chat room. If this To header field does not
contain the URI of a participant of the chat room or if the To header
field cannot be resolved (e.g., caused by a mistyped URI), the MSRP
switch MUST reject the request with a 404 response. This new 404
status code indicates a failure to resolve the recipient URI in the
To header field of the Message/CPIM wrapper.
Notice the importance of the From and To headers in the Message/
CPIM wrapper. If an intermediary modifies these values, the MSRP
switch might not be able to identify the source or intended
destination of the message, resulting in a rejection of the
message.
Finally, the MSRP switch MUST verify that the recipient supports
private messages. If the recipient does not support private
messages, the MSRP switch MUST reject the request with a 428
response. This new response 428 indicates that the recipient does
not support private messages. Any potential REPORT request that the
MSRP switch sends to the sender MUST include a Message/CPIM wrapper
containing the original From header field included in the SEND
request and the To header field of the original Message/CPIM wrapper.
The MSRP switch MUST NOT forward private messages to a recipient that
does not support private messaging.
If successful, the MSRP switch should search its mapping table to
find the MSRP sessions established towards the recipient. If a match
is found the MSRP switch MUST create a SEND request and MUST copy the
contents of the sender's message to it.
Niemi, et al. Expires July 26, 2012 [Page 14]
Internet-Draft Multi-party Chat MSRP January 2012
An MSRP endpoint that receives a SEND request from the MSRP switch
does the same validations as for regular messages (Section 6.1). If
the To header field is different from the chat room URI, the MSRP
endpoints knows that this is a private message. The endpoint should
render who it is from based on the value of the From header of the
Message/CPIM wrapper. The endpoint can also use the sender's
nickname, possibly learned via a conference event package, to render
such nickname rather than the sender's actual URI.
It is possible that a participant, identified by a SIP Address of
Record or other valid URI, joins a conference of instant messages
from two or more different SIP UAs. It is RECOMMENDED that the MSRP
switch can map a URI to two or more MSRP sessions. If the policy of
the server allows for this, the MSRP switch MUST copy all messages
intended to the recipient through each MSRP session mapped to the
recipient's URI.
6.3. MSRP reports and responses
This section discusses the common procedures for regular and private
messages with respect to MSRP reports and responses. Any particular
procedure affecting only regular messages or only private messages is
discussed in the previous Section 6.1 or Section 6.2, respectively.
MSRP switches MUST follow the success report and failure report
handling described in section 7 of RFC 4975 [RFC4975], complemented
with the procedures described in this section. The MSRP switch MUST
act as an MSRP endpoint receiver of the request according to section
5.3 of RFC 4975 [RFC4975].
If the MSRP switch receives an MSRP SEND request that does not
contain a Message/CPIM wrapper, the MSRP switch MUST reject the
request with a 415 response (specified in RFC 4975 [RFC4975]).
If the MSRP switch receives an MSRP SEND request where 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 sender of the
message or is not a valid participant of the chat room), the MSRP
switch MUST reject the request with a 403 response. In non-error
cases, the MSRP switch MUST construct responses according to section
7.2 of RFC 4975 [RFC4975].
When the MSRP switch forwards a SEND request, it MAY use any report
model in the copies intended for the recipients. The receiver
reports from the recipients MUST NOT be forwarded to the originator
of the original SEND request. This could lead to having the sender
receiving multiple reports for a single MSRP request.
Niemi, et al. Expires July 26, 2012 [Page 15]
Internet-Draft Multi-party Chat MSRP January 2012
7. Nicknames
A common characteristic of existing chat room services is that
participants have the ability to present themselves with a nickname
to the rest of the participants of the conference. It is used for
easy reference of participants in the chat room, and can also provide
anonymous participants with a meaningful descriptive name.
A nickname is a useful construct in many use cases, of which MSRP
chat is but one example. It is associated with a URI of which the
participant is known to the focus. Therefore, if a user joins the
chat room under the same URI from multiple devices, he or she may
request the same nickname across all these devices.
A nickname is a user selectable appearance of which the participant
wants to be known to the other participants. It is not a 'display-
name', but it is used somewhat like a display name. A main
difference is that a nickname is unique inside a chat room to allow
an unambiguous reference to a participant in the chat. Nicknames may
be long lived, or may be temporary. Users also need to reserve a
nickname prior to its utilization.
This memo specifies the nickname as a string. The nickname string
MUST be unambiguous within the scope of the chat room (conference
instance). This scope is similar to having a nickname unique inside
a chat room from Extensible Messaging and Presence Protocol
[RFC6120]. The chat room may have policies associated with
nicknames. It may not accept nickname strings at all, or a it may
provide a wider unambiguous scope like a domain or server, similar to
Internet Relay Chat (IRC) [RFC2810].
7.1. Using Nicknames within a Conference
This memo provides a mechanism to reserve a nickname for a
participant for as long as the participant is logged into the chat
room. The mechanism is based on a NICKNAME MSRP method (see below)
and a new "Use-Nickname" header. Note that other mechanisms may
exist (for example, a web page reservation system), although they are
outside the scope of this document.
A conference participant who has established an MSRP session with the
MSRP switch, where the MSRP switch has indicated the support and
availability of nicknames with the 'nicknames' token in the
'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP
switch. The NICKNAME request MUST include a new Use-Nickname header
that contains the nickname string that the participant wants to
reserve. MSRP NICKNAME requests MUST NOT include Success-Report or
Failure-Report header fields.
Niemi, et al. Expires July 26, 2012 [Page 16]
Internet-Draft Multi-party Chat MSRP January 2012
An MSRP switch that receives a NICKNAME request containing a nickname
in the Use-Nickname header field SHOULD first verify whether the
policy of the chat room allows the nickname functionality. If not
allowed, the MSRP switch MUST reject the request with a 501 response,
as per RFC 4975 [RFC4975].
If the policy of the chat room allows the usage of nicknames, the
MSRP switch SHOULD validate that the SIP AOR is entitled to reserve
the nickname. This may include, e.g., allowing that the
participant's URI may use the same nickname when the participant has
joined the chat room from different devices under the same URI. The
participant's authenticated identifier can be derived after a
successful SIP Digest Authentication [RFC3261], be included in a
trusted SIP P-Asserted-Identity header field [RFC3325], be included
in a valid SIP Identity header field [RFC4474], or be derived from
any other present or future SIP authentication mechanism. Once the
MSRP switch has validated that the participant is entitled to reserve
the requested nickname, the MSRP switch MUST answer the NICKNAME
request with a 200 response as per regular MSRP procedures.
The reservation of a nickname can fail, e.g. if the NICKNAME request
contains a malformed or non-existent Use-Nickname header field, or if
the same nickname has already been reserved by another participant
(i.e., by another URI) in the chat room. The validation can also
fail where the sender of the message is not entitled to reserve the
nickname. In any of these cases the MSRP switch MUST answer the
NICKNAME request with a 423 response. The semantics of the 423
response are: "Nickname usage failed; the nickname is not allocated
to this user".
As indicated earlier, this specification defines a new MSRP header
field: "Use-Nickname". The Use-Nickname header field carries a
nickname string, and SHOULD be included in the NICKNAME requests.
The syntax of the NICKNAME method and the "Use-Nickname" header field
is built upon the MSRP formal syntax [RFC4975]
ext-method =/ NICKNAMEm
NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps
ext-header =/ Use-Nickname
; ext-header defined in RFC 4975
Use-Nickname = "Use-Nickname:" SP nickname
nickname = quoted-string
; quoted-string defined in RFC 4975
Once the MSRP switch has reserved a nickname and has bound it to a
URI (e.g., a SIP Address-of-Record), the MSRP server MAY allow the
usage of the same nickname by the same user (identified by the same
Niemi, et al. Expires July 26, 2012 [Page 17]
Internet-Draft Multi-party Chat MSRP January 2012
URI, such as a SIP AoR) over a second MSRP session. This might be
the case if the user joins the same chat room from a different SIP
User Agent. In this case, the user MAY request the same or a
different nickname than that used in conjunction with the first MSRP
session; the MSRP server MAY accept the usage of the same nickname by
the same user. The MSRP switch MUST NOT automatically assign the
same nickname to more than one MSRP session established from the same
URI, because this can create confusion to the user as whether the
same nickname is bound to the second MSRP session.
7.2. Modifying a Nickname
Typically a participant will reserve a nickname as soon as the
participant joins the chat room. But it is also possible for a
participant to modify his/her own nickname and replace it with a new
one at any time during the duration of the MSRP session.
Modification of the nickname is not different from the initial
reservation and usage of a nickname, thus the NICKNAME method is used
as described in Section 7.1.
If a NICKNAME request that attempts to modify the current nickname of
the user for some reason fails, the current nickname stays in effect.
A new nickname comes into effect and the old one is released only
after a NICKNAME request is accepted with a 200 response.
7.3. Removing a Nickname
If the participant no longer wants to be known by a nickname in the
conference, the participant can follow the method described in
Section 7.2. The nickname element of the Use-Nickname header MUST be
set to an empty quoted string.
7.4. Nicknames in Conference Event Packages
Typically the conference focus acts as a notifier of the conference
event package. To notify subscribers of the nickname reserved for a
given participant, it is RECOMMENDED that conference focus and
endpoints support Conference Event Package Data Format Extension for
Centralized Conferencing [I-D.ietf-xcon-event-package]. The
Conference Information Data Model for Centralized Conferencing
[I-D.ietf-xcon-common-data-model] extends the user element from RFC
4575 [RFC4575] with a 'nickname' attribute.
8. The SDP 'chatroom' attribute
There are a handful of use cases where a participant would like to
learn the chat room capabilities supported by the MSRP switch and the
Niemi, et al. Expires July 26, 2012 [Page 18]
Internet-Draft Multi-party Chat MSRP January 2012
chat room. For example, a participant would like to learn if the
MSRP switch supports private messaging, otherwise, the participant
may send what he believes is a private instant message addressed to a
participant, but since the MSRP switch does not support the functions
specified in this memo, the message gets eventually distributed to
all the participants of the chat room.
The reverse case also exists. A participant, say Alice, whose user
agent does not support the extensions defined by this document joins
the chat room. The MSRP switch learns that Alice's application does
not support private messaging nor nicknames. If another participant,
say Bob, sends a private message to Alice, the MSRP switch does not
distribute it to Alice, because Alice is not able to differentiate it
from a regular message sent to the whole roster. Furthermore, if
Alice replied to this message, she would do it to the whole roster.
Because of this, the MSRP switch also keeps track of users who do not
support the extensions defined in this document.
In another scenario, the policy of a chat room may indicate that
certain functions are not allowed. For example, the policy may
indicate that nicknames or private messages are not allowed.
In order to provide the user with a good chat room experience, we
define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a
media-level value attribute [RFC4566] that MAY be included in
conjunction with an MSRP media stream (i.e., when an m= line in SDP
indicates "TCP/MSRP" or "TCP/TLS/MSRP"). The 'chatroom' attribute
without further modifiers (e.g., chat-tokens) indicates that the
endpoint supports the procedures described in this document for
transferring MSRP messages to/from a multi-party conference. The
'chatroom' attribute can be complemented with additional modifiers
that further indicate the intersection of support and chat room local
policy allowance for a number of functions specified in this
document. Specifically, we provide the means for indicating support
to use nicknames and private messaging.
The 'chatroom' SDP attribute has the following Augmented BNF (ABNF)
[RFC5234] syntax:
Niemi, et al. Expires July 26, 2012 [Page 19]
Internet-Draft Multi-party Chat MSRP January 2012
attribute =/ chatroom-attr
; attribute defined in RFC 4566
chatroom-attr = chatroom-label [":" chat-token
*(SP chat-token)]
chatroom-label = "chatroom"
chat-token = (nicknames-token / private-msg-token /
ext-token)
nicknames-token = "nickname"
private-msg-token = "private-messages"
ext-token = private-token / standard-token
private-token = toplabel "." *(domainlabel ".") token
; toplabel defined in RFC 3261
; domainlabel defined in RFC 3261
; token defined in RFC 3261
standard-token = token
A given 'chat-token' value MUST NOT appear more than once in a
'chatroom' attribute.
A conference focus that includes the 'nicknames' token in the session
description is signaling that the MSRP switch supports and the chat
room allows to use the procedures specified in Section 7. A
conference focus that includes the 'private-messages' in the SDP
description is signaling that the MSRP switch supports and the chat
room allows to use the procedures specified in Section 6.2.
Example of the 'chatroom' attribute for an MSRP media stream that
indicates the acceptance of nicknames and private messages:
a=chatroom:nickname private-messages
An example of a 'chatroom' attribute for an MSRP media stream where
the endpoint, e.g., an MSRP switch, does not allow either nicknames
nor private messages.
a=chatroom
The 'chatroom' attribute allows extensibility with the addition of
new tokens. No IANA registry is provided at this time, since no
extensions are expected at the time of this writing. Extensions to
the 'chatroom' attribute can be defined in IETF documents or as
private vendor extensions.
Extensions defined in IETF document MUST follow the 'standard-token'
ABNF previously defined. In this type of extensions, are must be
taken in the selection of the token to avoid a clash with any of the
tokens previously defined.
Niemi, et al. Expires July 26, 2012 [Page 20]
Internet-Draft Multi-party Chat MSRP January 2012
Private extensions MUST follow the 'private-token' ABNF previously
defined. The 'private-token' MUST include the DNS name of the vendor
in reverse order in the token, in order to avoid clashes of tokens.
The following is an example of a "chat.foo" extension by vendor
"example.com"
a=chatroom:nickname private-messages com.example.chat.foo
9. Examples
9.1. Joining a chat room
Figure 3 presents a flow diagram where Alice joins a chat room by
sending an INVITE request. This INVITE request contains a session
description that includes the chatroom extensions defined in this
document.
Alice Conference focus
| |
|F1: (SIP) INVITE |
|----------------------->|
|F2: (SIP) 200 OK |
|<-----------------------|
|F3: (SIP) ACK |
|----------------------->|
| |
Figure 3: Flow diagram of a user joining a chat room
F1: Alice constructs an SDP description that includes an MSRP media
stream. She also indicates her support for the chatroom extensions
defined in this document. She sends the INVITE request to the chat
room server.
Niemi, et al. Expires July 26, 2012 [Page 21]
Internet-Draft Multi-party Chat MSRP January 2012
INVITE sip:chatroom22@chat.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 290
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 client.atlanta.example.com
m=message 7654 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
a=chatroom:nickname private-messages
F2: The chat room server accepts the session establishment. It
includes the 'isfocus' and other relevant feature tags in the Contact
header field of the response. The chat room server also builds an
SDP answer that forces the reception of messages wrapped in Message/
CPIM wrappers. It also includes the 'chatroom' attribute with the
allowed extensions.
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:chatroom22@chat.example.com;transport=tcp> \
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
;automata;isfocus;message;event="conference"
Content-Type: application/sdp
Content-Length: 290
v=0
o=chat 2890844527 2890844527 IN IP4 chat.example.com
s=-
c=IN IP4 chat.example.com
m=message 12763 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html *
a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Niemi, et al. Expires July 26, 2012 [Page 22]
Internet-Draft Multi-party Chat MSRP January 2012
a=chatroom:nickname private-messages
F3: The session established is acknowledged (details not shown).
9.2. Setting up a nickname
Figure 4 shows an example of Alice setting up a nickname using the
conference as provider. Her first proposal is not accepted because
that proposed nickname is already in use. Then, she makes a second
proposal with a new nickname. This second proposal is accepted.
Alice MSRP switch
| |
|F1: (MSRP) NICKNAME |
|----------------------->|
|F2: (MSRP) 423 |
|<-----------------------|
|F3: (MSRP) NICKNAME |
|----------------------->|
|F4: (MSRP) 200 |
|<-----------------------|
| |
Figure 4: Flow diagram of a user setting up her nickname
F1: Alice sends an MSRP NICKNAME request that contains her proposed
nicknames in the Use-Nickname header field.
MSRP d93kswow NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice the great"
-------d93kswow$
F2: The MSRP switch analyzes the existing allocation of nicknames and
detects that the nickname "Alice the great" is already provided to
another participant in the chat room. The MSRP switch answers with a
423 response.
MSRP d93kswow 423 Nickname usage failed
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------d93kswow$
F3: Alice receives the response. She proposes a new nickname in a
second NICKNAME request.
Niemi, et al. Expires July 26, 2012 [Page 23]
Internet-Draft Multi-party Chat MSRP January 2012
MSRP 09swk2d NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice in Wonderland"
-------09swk2d$
F4: The MSRP switch accepts the nickname proposal and answers with a
200 response.
MSRP 09swk2d 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------09swk2d$
9.3. Sending a regular message to the chat room
Figure 5 depicts a flow diagram where Alice is sending a regular
message addressed to the chat room. The MSRP switch distributes the
message to the rest of the participants.
Alice MSRP switch Bob Charlie
| | | |
| F1: (MSRP) SEND | | |
|--------------------->| F3: (MSRP) SEND | |
| F2: (MSRP) 200 |----------------------->| |
|<---------------------| F4: (MSRP) SEND | |
| |------------------------------->|
| | F5: (MSRP) 200 OK | |
| |<-----------------------| |
| | F6: (MSRP) 200 OK | |
| |<------------------------------ |
| | | |
| | | |
Figure 5: Sending a regular message to the chat room
F1: Alice builds a text message and wraps it in a Message/CPIM
wrapper. She addresses the message to the chat room. She encloses
the resulting Message/CPIM wrapper in an MSRP SEND request and sends
it to the MSRP switch via the existing TCP connection.
Niemi, et al. Expires July 26, 2012 [Page 24]
Internet-Draft Multi-party Chat MSRP January 2012
MSRP 3490visdm SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 99s9s2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------3490visdm$
F2: The MSRP switch acknowledges the reception of the SEND request
with a 200 (OK) response.
MSRP 3490visdm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: 99s9s2
-------3490visdm$
F3: The MSRP switch creates a new MSRP SEND request that contains the
received Message/CPIM wrapper and sends it to Bob.
MSRP 490ej23 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: 304sse2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------490ej23$
Since the received message is addressed to the chat room URI in the
From header of the Message/CPIM header, Bob knows that this is a
regular message distributed all participants in the chat room, rather
that a private message addressed to him.
The rest of the message flows are analogous to the previous. They
Niemi, et al. Expires July 26, 2012 [Page 25]
Internet-Draft Multi-party Chat MSRP January 2012
are not shown here.
9.4. Sending a private message to a participant
Figure 6 depicts a flow diagram where Alice is sending a private
message addressed to Bob's SIP AOR. The MSRP switch distributes the
message only to Bob.
Alice MSRP switch Bob
| | |
| F1: (MSRP) SEND | |
|--------------------->| F3: (MSRP) SEND |
| F2: (MSRP) 200 |----------------------->|
|<---------------------| F4: (MSRP) 200 |
| |<-----------------------|
| | |
Figure 6: Sending a private message to Bob
F1: Alice builds a text message and wraps it in a Message/CPIM
wrapper. She addresses the message to Bob's URI, which she learned
from a notification in the conference event package. She encloses
the resulting Message/CPIM wrapper in an MSRP SEND request and sends
it to the MSRP switch via the existing TCP connection.
MSRP 6959ssdf SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: okj3kw
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------6959ssdf$
F2: The MSRP switch acknowledges the reception of the SEND request
with a 200 (OK) response.
MSRP 6959ssdfm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: okj3kw
-------6959ssdfm$
Niemi, et al. Expires July 26, 2012 [Page 26]
Internet-Draft Multi-party Chat MSRP January 2012
F3: The MSRP switch creates a new MSRP SEND request that contains the
received Message/CPIM wrapper and sends it only to Bob. Bob can
distinguish the sender in the From header of the Message/CPIM
wrapper. He also identifies this as a private message due to the
presence of his own SIP AOR in the To header field of the Message/
CPIM wrapper.
MSRP 9v9s2 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: d9fghe982
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------9v9s2$
F4: Bob acknowledges the reception of the SEND request with a 200
(OK) response.
MSRP 9v9s2 200 OK
To-Path: msrp://chat.example.com:5678/jofofo3;tcp
From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
Message-ID: d9fghe982
-------9v9s2$
9.5. Chunked private message
The MSRP message below depicts the example of the same private
message described in Section 9.4, but now the message is split in two
chunks. The MSRP switch must wait for the complete set of Message/
CPIM headers before distributing the messages.
Niemi, et al. Expires July 26, 2012 [Page 27]
Internet-Draft Multi-party Chat MSRP January 2012
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 1-*/174
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@example.com>
-------7443ruls$
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 68-174/174
Content-Type: message/cpim
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob
-------7443ruls$
9.6. Nickname in a conference information document
Figure 7 depicts two user elements in a conference information
document both having the nickname element with a nickname string.
Niemi, et al. Expires July 26, 2012 [Page 28]
Internet-Draft Multi-party Chat MSRP January 2012
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sip:chatroom22@chat.example.com"
state="full" version="1">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>MSRP nickname example</subject>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>2</user-count>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:bob@example.com" state="full">
<nickname>Dopey Donkey</nickname>
</user>
<!--
USER
-->
<user entity="sip:alice@atlanta.example.com" state="full">
<nickname>Alice the great</nickname>
</user>
</users>
</conference-info>
Figure 7: Nickname in a conference information document
10. IANA Considerations
10.1. New MSRP Method
This specification defines a new MSRP method to be added to the
Methods sub-registry of the Message Session Relay Protocol (MSRP)
Parameters registry:
NICKNAME
See section Section 7 for details.
Niemi, et al. Expires July 26, 2012 [Page 29]
Internet-Draft Multi-party Chat MSRP January 2012
10.2. New MSRP Header
This specification defines a new MSRP header to be added to the
Header Field sub-registry of the Message Session Relay Protocol
(MSRP) Parameters registry:
Use-Nickname
See Section 7 for details.
10.3. New MSRP Status Codes
This specification defines three new MSRP status codes to be added to
the Status-Code sub-registry of the Message Session Relay Protocol
(MSRP) parameters registry.
The 404 status code indicates the failure to resolve the recipient
URI in the To header field of the Message/CPIM wrapper in the SEND
request, e.g, due to an unknown recipient. See Section 6.2 for
details.
The 423 response indicates a failure in allocating the requested
NICKNAME. This can be caused by a malformed NICKNAME request (e.g.,
no Use-Nickname header field), an already allocated nickname, or a
policy that prevents the sender to use nicknames. See Section 7 for
details.
The 428 status code indicates that the recipient of a SEND request
does not support private messages. See Section 6.2 for details.
Table 1 summarizes the IANA registration data with respect to new
MSRP status codes:
+-------+---------------------------------------+-----------+
| Value | Description | Reference |
+-------+---------------------------------------+-----------+
| 404 | Failure to resolve recipient's URI | RFC XXXX |
| 423 | Unable to allocate requested nickname | RFC XXXX |
| 428 | Private messages not supported | RFC XXXX |
+-------+---------------------------------------+-----------+
Table 1: New status codes
10.4. New SDP Attribute
This specification defines a new media-level attribute in the Session
Description Protocol (SDP) Parameters registry. The registration
data is as follows:
Niemi, et al. Expires July 26, 2012 [Page 30]
Internet-Draft Multi-party Chat MSRP January 2012
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
Attribute name: chatroom
Long-form attribute name: Chat Room
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: This attribute identifies support and local policy
allowance for a number of chat room related functions
Specification: RFC XXXX
See section Section 8 for details.
11. Security Considerations
This document proposes extensions to the Message Session Relay
Protocol [RFC4975]. Therefore, the security considerations of that
document apply to this document as well.
If the participant's SIP user agent doesn't understand the "isfocus"
feature tag [RFC3840], it will not know that it is connected to a
conference instance. The participant might not be notified that the
participant's MSRP client will try to send messages to the MSRP
switch having potentially multiple recipients. If the participant's
MSRP client doesn't support the extensions of this specification, it
is unlikely that it will try to send a message using 'Message/CPIM'
wrapper content type [RFC3862], and the MSRP switch will reject the
request with a 415 response [RFC4975]. Still if a participant's MSRP
client does create a message with a valid 'Message/CPIM' wrapper
content type [RFC3862] having the To header set to the URI of the
chat room and the From header set to the URI of which the participant
is known to the conference, the participant might be unaware that the
message can be forwarded to multiple recipients. Equally if the To
header is set to a valid URI of a recipient known to the conference,
the message can be forwarded as a private message without the
participant knowing.
If a participant wants to avoid eavesdropping, the participant's MSRP
client can send the messages over a TLS [RFC5246] transport
connection, as allowed by MSRP. It's up to the policy of the MSRP
switch if the messages are forwarded to the other participant's in
Niemi, et al. Expires July 26, 2012 [Page 31]
Internet-Draft Multi-party Chat MSRP January 2012
the chat room using TLS [RFC5246] transport.
Nicknames will be used to show the appearances of the participants of
the conference. A successful take over of a nickname from a
participant might lead to private messages to be sent to the wrong
destination. The recipient's URI will be different from the URI
associated to the original owner of the nickname, but the sender
might not notice this. To avoid takeovers the MSRP switch MUST make
sure that a nickname is unique inside a chat room. Also the security
consideration for any authenticated identity mechanisms used to
validate the SIP AOR will apply to this document as well. If a
nickname can be reserved if it previously has been used by another
participant in the chat room, is up to the policy of the chat room.
12. Contributors
This work would have never been possible without the fruitful
discussions in the SIMPLE WG mailing list, specially with Brian Rosen
(Neustar) and Paul Kyzivat (Cisco), who provided extensive review and
improvements throughout the document.
13. Acknowledgments
The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach,
Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrian
Georgescu, Nancy Greene, and Flemming Andreasen for providing
comments.
14. References
14.1. 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.
[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
Niemi, et al. Expires July 26, 2012 [Page 32]
Internet-Draft Multi-party Chat MSRP January 2012
(CPIM)", RFC 3860, August 2004.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August 2004.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-32
(work in progress), September 2011.
[I-D.ietf-xcon-event-package]
Camarillo, G., Srinivasan, S., Even, R., and J.
Urpalainen, "Conference Event Package Data Format
Extension for Centralized Conferencing (XCON)",
draft-ietf-xcon-event-package-01 (work in progress),
September 2008.
Niemi, et al. Expires July 26, 2012 [Page 33]
Internet-Draft Multi-party Chat MSRP January 2012
14.2. Informative References
[RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
April 2000.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
Authors' Addresses
Aki Niemi
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
Email: aki.niemi@nokia.com
Miguel A. Garcia-Martin
Ericsson
Calle Via de los Poblados 13
Madrid, ES 28033
Spain
Email: miguel.a.garcia@ericsson.com
Niemi, et al. Expires July 26, 2012 [Page 34]
Internet-Draft Multi-party Chat MSRP January 2012
Geir A. Sandbakken (editor)
Cisco Systems
Philip Pedersens vei 20
N-1366 Lysaker
Norway
Phone: +47 67 125 125
Email: geirsand@cisco.com
URI: http://www.cisco.com
Niemi, et al. Expires July 26, 2012 [Page 35]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/