Multi-party Chat
Using the Message Session Relay Protocol (MSRP)NokiaP.O. Box 407NOKIA GROUPFIN00045Finland+358 50 389 1644aki.niemi@nokia.comEricssonCalle Via de los Poblados 13MadridES28033Spainmiguel.a.garcia@ericsson.comTANDBERGPhilip Pedersens vei 20N-1366 LysakerNorway+47 67 125 125geir.sandbakken@tandberg.comhttp://www.tandberg.com
General
I-DInternet-Draftmessagingmessage sessionsmulti-partyThe 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.
The Message Session Relay Protocol (MSRP)
defines a mechanism for sending a series of instant
messages within a session. The
Session Initiation Protocol (SIP) in
combination with the Session Description
Protocol (SDP) 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
. 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 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 other participants.
Similar conferences supporting chat rooms are already available today.
For example, Internet Relay Chat (IRC),
Extensible Messaging and Presence Protocol
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 identity
is disclosed to other participants. This memo uses the
SIP Conferencing Framework as a design
basis. It also aims to be compatible with the
A Framework for Centralized Conferencing.
It is expected that future mechanisms will be
developed for providing similar functionality in generic
conferences, i.e., 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. 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, and indicate
requirement levels for compliant implementations.This memo deals with tightly coupled SIP
conferences defined in
SIP Conferencing Framework adopting
the terminology. In addition to that terminology,
we introduce some new terms:
a pseudonym or descriptive name associated to a
participant. See for details
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. a synonym for a multi-party chat a URI that identifies a particular
chat room, and is a synonym of a Conference URI defined in
the conference participant that
originally created an instant message and sent it to the chat room for
delivery. the destination conference
participant(s). This defaults to the full conference participant
list, minus the IM Sender. 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.
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.
a temporary
Globally Routable User Agent URI (GRUU)
that can be registered
with the conference focus to conceal a participant's SIP AOR
from the other participants in the conference.
Although conference frameworks describing many types of
conferencing applications already exist, such as the
Framework for Centralized Conferencing
and the
SIP Conferencing
Framework, 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:
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.
A conference participant must be able to determine the
identities of the sender and recipient of the received IMs.
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).
It must be possible to send a message to a single
participant within the conference (i.e., a private instant message).
A conference participant may have a nickname or pseudonym
associated with their real identity.
It must be possible for a participant to change their nickname
during the progress of the conference.
It must be possible that a participant is only known by
an anonymous identity and not their real identity to the rest of the
conference.
It must be possible for the MSRP switch originate IMs
to the conference by owner or administrator
(e.g. message of the day, welcome messages, server is shutting down, etc.)
It must be possible for the conference participants to
learn the chat room capabilities described in this document.
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 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
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 found in .
This is illustrated in
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
.
Typically conference participants also subscribe to the
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' identities.
All messages in the chat room use the
'Message/CPIM' wrapper content type,
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 participants whose
identity has been learned, e.g. via a notification from the
conference event package. In this
case the sender creates an MSRP SEND request with a Message/CPIM
body whose To header contains not the chat room URI but
the recipient's URI. The MSRP switch
then forwards the SEND request to the recipient.
We extend the current MSRP negotiation that takes place in
SDP 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.
Since we consider a chat room a particular type of conference
having MSRP media, the methods
defined by the SIP Conference
Framework 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.
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. Conference aware participants
will detect that the peer is a focus due to the presence
of the "isfocus" feature tag
in the Contact header field of
the 200-class response to the INVITE request. Conference unaware
participants will not notice it is a foucs, 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 an 'message' media type and either TCP/MSRP or
TCP/TLS/MSRP as the protocol field in the
SDP media-line.
The conference focus of a chat room MUST include support for
a Message/CPIM 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 can
register or acquire by other means a temporary GRUU
with the conference focus. The procedure SHOULD follow
the recommendation of
draft-ietf-sip-gruu.
The temporary GRUU can be used in the From and To header in
the 'Message/CPIM' wrapper concealing the participant's SIP AOR
from the other participants in the conference.
The conference focus of a chat room MUST learn the chat room
capabilities of each participant that joins the chat room, and
MUST inform the MSRP switch of such support. This is to prevent
that the MSRP switch distributes private messages to participants
who do not support private messaging. The recipient could be able to
render the private message, but not supporting private messages
the participant can not respond.
As with creating a conference, the methods defined by the
SIP Conference Framework
for deleting a conference are directly applicable to a chat
room. The MSRP switch will terminate the MSRP sessions with
all the participants.
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.
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
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, he constructs an MSRP
SEND request that MUST contain a top-level wrapper of type
'Message/CPIM'. The actual instant message
payload inside 'Message/CPIM' MAY be of any type negotiated in the
SDP 'accepted-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:A SIP URI representing the
participant's address-of-recordA tel URI representing the
participant's telephone numberAn IM URI representing the
participant's instant messaging address An temporary GRUU
representing the anonymous URI associated with the sender.
The 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.
Then the MSRP switch should inspect the To header field of the
Message/CPIM wrapper. If the To header field of the Message/CPIM
wrapper contains the chat room URI, 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 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 SHOULD start the distribution process. Having the
Message/CPIM header 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 body. If the To header field
is set to the chat room URI, it should render 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 .
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 (see
for details).
When a chat room participant wishes to send a private instant
message to a participant the chat room, it follows the same procedures
for creating a SEND request as for
regular messages .
The only difference is that the MSRP endpoint
MUST populate the To header of the Message/CPIM
with the identity of the intended recipient.
The identity can be SIP, TEL, and IM URIs typically
learned from the information received in notifications of the
conference event package .
As for regular messages, the 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, and that the recipient is supporting private messages.
See section for report and response handling.
If successful, the MSRP switch should search it's mapping
table to find the MSRP session 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.
An MSRP endpoint that receives a SEND request from the MSRP
switch does the same validations as for
regular messages . If the To header field is different
from the chat room URI, the MSRP endpoints know that it is a
private message. It should render who it is from based on the From
header of the Message/CPIM wrapper
It is possible that a participant, identified by
a SIP Address of Record, joins a conference of instant messages
from two or more different SIP UAs. It is RECOMMENDED that
the the MSRP switch can map a participant or anonymous URI
for two or more MSRP sessions. If the policy of the server
allows for this, the MSRP switch MUST copy all messages intended
for the recipient through each MSRP session.
The MSRP SHALL follow the success report and failure report
handling described in section 7 of . For
regular messages the MSRP switch MUST act as a MSRP endpoint receiver
of the request according to section 5.3 of .
For regular messages the MSRP switch MAY use any report model in the copies
of the regular SEND request intended for the recipients, but
any received reports 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.
The MSRP switch for regular messages SHALL construct responses
according to section 7.2 of .
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),
the response code is 403. Otherwise the response code is
200.
Private messages (section )
handle MSRP reports differently from regular chat room messages.
The MSRP switch acts transparently having an end-to-end relationship
between the sender and the recipient. The
MSRP switch MUST for private messages keep any Sucess-Report
and Failure-Report headers in the relayed request.
Any reports or responses from the recipient MUST
be forwarded to the sender.
For private messages the MSRP switch MUST follow section 7.2
of in the following error scenarios.
The MSRP switch MUST inspect the To header
field of the Message/CPIM wrapper. If the To header field of the
Message/CPIM wrapper in the request does not contain the chat room URI,
it must
check if it contains a participants URI associated with
a participant. If the URI in the To header can not be resolved
(e.g. cased by a mistyped URI or that the recipient has abandoned
he chat room), the response error code is 427.
The new 427 status code indicates a failure to resolve the
recipient URI in the To header field. If the recipient doesn't
support private messages, the response code is 428.
The new response 428 indicate that the recipient does not support
private messages. A REPORT request MUST include
a Message/CPIM wrapper, with the original From header field
included in the SEND request, and the To header field of the
original message. The message MUST NOT be forwarded to the recipient
if above conditions applies.
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. It 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. 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).
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&nbhy;Nickname header that contains the nickname string that the
participant wants to reserve.
The MSRP switch that receives a NICKNAME request containing a
nickname in the Use&nbhy;Nickname header field SHOULD first
verify whether the policy of the chat room allows the nickname
functionality. If is not allowed, the MSRP the response code
is 501 section 7.2 of
for constructing a response.
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. The participant's authenticated identity can be
derived after a successful HTTP Digest Authentication, included in a trusted
SIP P-Asserted-Identity header field, included in a valid SIP Identity
header field, or derived from any other present or future SIP
authentication mechanism. Once the MSRP switch has validated
that the participant is entitled to reserve the nickname, the
response code is 200.
The reservation of a nickname can fail, e.g. if the NICKNAME
request contains a malformed or non-existent Use&nbhy;Nickname header
field, or if the same nickname has already been reserved by another
participant in the conference. The validation can also fail where
the SIP AOR is not entitled to reserve the nickname. In any of these cases
the MSRP response code is 423.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&nbhy;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
Typically participants will reserve a nickname as soon as they
join the chat room. But it is also
possible for participants to modify their own nicknames and
replace them it 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
.
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.
If the participant no longer wants to be known by a nickname
in the conference, the participant can follow the method
described in .
The nickname element of the Use&nbhy;Nickname header MUST be
set to an empty quoted string.
Typically the conference focus acts as a notifier of the
SIP conference event package . The
conference focus MAY notify subscribers of the nickname reserved
by a given participant. We define an extension to the conference
event package to include nicknames. The extension adds a
<nickname> child element to the <user> element
containing the nickname string. The following element is to be added to the sequence of
the USER-TYPE in the XML schema in conference
event package
]]> The participants of the conference are identified by the
SIP, TEL and IM URI's typically learned from the
information received in notifications of the
conference event package .
If nicknames are not supported nor allowed, the participant list
of the conference will be less presentable.
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 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
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. Further more, if Alice replied to this message, she
would do it to the whole roster. Because of this, the MSRP switch
keeps also 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 attribute that MAY be included in conjunction
with and MSRP media stream (i.e., when an m= line in SDP indicates
"TCP/MSRP" or "TCP/TLS/MSRP"). The 'chatroom' attribute indicates
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 syntax:
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 of the procedures specified in
. 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 of the procedures
specified in .
Example of the 'chatroom' attribute for an MSRP media stream
that indicates the acceptance of nicknames and private
messages:
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.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.
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 also that
forces the reception of messages wrapped in message/cpim
envelops. It also includes the the chatroom attribute with the
allowed extensions.
F3: The session established is acknowledged (details not
shown).
shows an example of Alice
setting up a nickname using the conference as provider.
Her first proposal is not accepted
because the proposed nickname is already in use. Her second
proposal is accepted.F1: Alice sends an MSRP NICKNAME request that contains her
proposed nicknames in the Set-Nickname header field.F2: The MSRP switch analyzes the existing allocation of
nicknames and detects that the nickname "Alice is great"
is already provided to another participant by the conference.
The MSRP switch answers with a 423 response.F3: Alice receives the response. She proposes a new
nickname in a second NICKNAME request.F4: The MSRP switch accepts the nickname proposal and
answers with a 200 response. 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.F1: Alice builds a text message and wraps it in a CPIM
message. She addresses the CPIM message to the chat room. She
encloses the result in an MSRP SEND request and sends it to the
MSRP switch via the existing TCP connection.F2: The MSRP switch acknowledges the reception of the SEND
request with a 200 (OK) response.F3: The MSRP switch creates a new MSRP SEND request that
contains the received message/cpim body and sends it to Bob.The rest of the message flows are analogous to the
previous. They are not shown here. 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.F1: Alice builds a text message and wraps it in a CPIM
message. She addresses the CPIM message to the Bob's nickname,
which she learned from a notification in the conference event
package. She encloses the result in an MSRP SEND request and
sends it to the MSRP switch via the existing TCP connection.F2: The MSRP switch acknowledges the reception of the SEND
request with a 200 (OK) response.F3: The MSRP switch creates a new MSRP SEND request that
contains the received message/cpim body and sends it only to
Bob. Bob can distinguish the sender in the From header of the
CPIM message. He also identifies this as a private message due
to the To CPIM header. depicts an example of the private message
in split in two
chuncks. The MSRP switch must wait for the complete set of CPIM headers before distributing the
messages.
depicts a flow
diagram where Alice is utilizing the temporary GRUU when sending a
private message to BobF1: Alice builds a text message adding her registered temp-gruu
to the From header of the CPIM messageF2: The MSRP switch inspects the From header field and verifies
that the temp-gruuu in registered to Alice. If the temporary gruu
is valid, the MSRP acknowledges the reception of SEND request with
a 200 (OK) responseFlow F3 is not shown depicts two user elements in a conference information
document both having the nickname element with a nickname string.
This specification defines a new MSRP method to be added to the
Methods sub-registry under the MSRP Parameter registry: NICKNAME.
See section for details.
This specification defines a new MSRP header to be added to
the header-field sub registry under the MSRP Parameter registry:
Use&nbhy;Nickname. See section for details.
This specification defines three new MSRP status codes to be added
to the Status-Code sub-registry under MSRP parameters.
The 427 status code indicates the failure to resolve the
recipient URI in the To header field of the Message/CPIM wrapper in the
SEND request. See section for details.
The 428 status code indicates that the recipient of a SEND request does
not support private messages. See section for details.
The 423 response indicates that the requested nickname is not allocated
to the user requesting it. See section for details.
This specification defines a new media level attribute in the
Session Description Protocol (SDP) Parameters registry: chatroom.
See section for details.
This document proposes extensions to the
Message Session Relay
Protocol . 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 transport
connection, as allowed by MSRP. 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 take overs
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.
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.
The authors want to thank Eva Leppanen, Adamu Haruna,
Adam Roach, Matt Lepinski, Mary Barnes and Ben Campbell
for providing comments.