One document matched: draft-ietf-simple-chat-10.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes" ?>
<rfc ipr="pre5378Trust200902" category="std" docName="draft-ietf-simple-chat-10">
<front>
<title abbrev="Multi-party Chat MSRP">Multi-party Chat
Using the Message Session Relay Protocol (MSRP)</title>
<author initials="A" surname="Niemi" fullname="Aki Niemi">
<organization>Nokia</organization>
<address>
<postal>
<street>P.O. Box 407</street>
<city>NOKIA GROUP</city> <region>FIN</region> <code>00045</code>
<country>Finland</country>
</postal>
<phone>+358 50 389 1644</phone>
<email>aki.niemi@nokia.com</email>
</address>
</author>
<author initials="M" surname="Garcia-Martin" fullname="Miguel A. Garcia-Martin">
<organization>Ericsson</organization>
<address>
<postal>
<street>Calle Via de los Poblados 13</street>
<city>Madrid</city>
<region>ES</region>
<code>28033</code>
<country>Spain</country>
</postal>
<email>miguel.a.garcia@ericsson.com</email>
</address>
</author>
<author fullname="Geir A. Sandbakken" initials="G.A."
surname="Sandbakken"
role="editor">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Philip Pedersens vei 20</street>
<city>N-1366 Lysaker</city>
<country>Norway</country>
</postal>
<phone>+47 67 125 125</phone>
<email>geirsand@cisco.com</email>
<uri>http://www.cisco.com</uri>
</address>
</author>
<date day="20" month="September" year="2011" />
<area>General</area>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>messaging</keyword>
<keyword>message sessions</keyword>
<keyword>multi-party</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
The <xref target="RFC4975">Message Session Relay Protocol (MSRP)
</xref> defines a mechanism for sending a series of instant
messages within a session. The <xref target="RFC3261">
Session Initiation Protocol (SIP)</xref> in
combination with the <xref target="RFC3264">Session Description
Protocol (SDP)</xref> allows for two peers to establish and manage
such sessions.
</t>
<t>
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
<xref target="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.
</t>
<t>
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.
</t>
<t>Similar conferences supporting chat rooms are already
available today. For example, <xref target="RFC2810">Internet
Relay Chat (IRC)</xref>, <xref target="RFC6120">Extensible
Messaging and Presence Protocol (XMPP): Core</xref> 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.
</t>
<t>
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
<xref target="RFC4353"> SIP Conferencing Framework</xref> as a design
basis. It also aims to be compatible with the
<xref target="RFC5239">A Framework for Centralized Conferencing</xref>.
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. </t>
</section>
<section anchor="terminology" title="Terminology">
<t>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
<xref target="RFC2119">RFC 2119, BCP 14</xref>, and indicate
requirement levels for compliant implementations.</t>
<t>This memo deals with tightly coupled SIP
conferences defined in <xref target="RFC4353">
SIP Conferencing Framework </xref> and adopts the terminology
from that document. In addition to that terminology,
we introduce some new terms:
<list style="hanging">
<t hangText="Nickname: "> a pseudonym or descriptive name associated to a
participant. See <xref target="nicknames"/> for details </t>
<t hangText="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.</t>
<t hangText="Chat Room: "> a synonym for a multi-party chat.</t>
<t hangText="Chat Room URI: "> a URI that identifies a particular
chat room, and is a synonym of a Conference URI defined in
<xref target="RFC4353">RFC 4353 </xref>.</t>
<t hangText="Sender: "> the conference participant that
originally created an instant message and sent it to the chat room for
delivery.</t>
<t hangText="Recipient: "> the destination conference
participant(s). This defaults to the full conference participant
list, minus the IM Sender.</t>
<t hangText="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.</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="Conference Event Package:"> a notification mechanism that
allow conference participants to learn conference information
including roster and state changes in a conference.
This would typically be <xref target="RFC4575">A Session Initiation Protocol (SIP)
Event Package for Conference State</xref> or
<xref target="I-D.ietf-xcon-event-package">
Conference Event Package Data Format Extension for Centralized Conferencing</xref>.
</t>
</list></t>
</section>
<section anchor="motivation" title="Motivations and Requirements">
<t>
Although conference frameworks describing many types of
conferencing applications already exist, such as the
<xref target="RFC5239">Framework for Centralized Conferencing</xref>
and the
<xref target="RFC4353">SIP Conferencing
Framework</xref>, the exact details of session-based instant
messaging conferences are not well-defined at the moment.
</t>
<t>
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.
</t>
<t>We define the following requirements:</t>
<t>
<list style='format REQ-%d:'>
<t>
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.
</t>
<t>
A conference participant must be able to determine the
identities of the sender and recipient of the received IMs.
</t>
<t>
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).
</t>
<t>
It must be possible to send a message to a single
participant within the conference (i.e., a private instant message).
</t>
<t>
A conference participant may have a nickname or pseudonym
associated with their real identity.
</t>
<t>
It must be possible for a participant to change their nickname
during the progress of the conference.
</t>
<t>
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.
</t>
<t>
It must be possible for the conference participants to
learn the chat room capabilities described in this document.
</t>
</list>
</t>
</section>
<section anchor="overview" title="Overview of Operation">
<t>
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.
</t>
<t>
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 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 <xref
target="RFC4976">RFC 4976</xref>.
This is illustrated in <xref target="scenario" />
</t>
<figure title="Multi-party chat overview shown with MSRP Relays and a conference Focus UA"
anchor="scenario">
<artwork>
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
</artwork>
</figure>
<t>
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
<xref target="arch" />.
</t>
<figure title="Multi-party chat in a Centralized Conference"
anchor="arch">
<artwork>
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
</artwork>
</figure>
<t>
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' identities, including their nicknames.
</t>
<t>
All messages in the chat room use the
<xref target="RFC3862">'Message/CPIM' wrapper content type</xref>,
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.
</t>
<t>
A participant can also send a private instant message
addressed to a participant whose
identity has been learned, e.g. via a 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 that recipient. This
specification supports the sending of private messages to one
and only one recipient. However, if the recipient is logged
from different endpoints, the MSRP switch will distribute the
private message to each endpoint the recipient is logged.
</t>
<t>
We extend the current MSRP negotiation that takes place in
<xref target="RFC4566">SDP </xref> 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="chatroom-management" title="Creating, Joining, and Deleting
a Chat Room">
<section anchor="creating" title="Creating a Chat Room">
<t>
Since we consider a chat room a particular type of conference
having MSRP media, the methods
defined by the <xref target="RFC4353" >SIP Conference
Framework </xref> for creating conferences are directly
applicable to a chat room.
</t>
<t>
Once a chat room is created, it is identified by a SIP URI,
like any other conference.
</t>
</section>
<section title="Joining a Chat Room" anchor="joining">
<t>
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.
</t>
<t>
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 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.
</t>
<t>
Conference aware participants will detect that the peer is a
focus due to the presence of <xref target="RFC3840"> the
"isfocus" feature tag </xref> 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 <xref target="RFC4566">SDP</xref>.
</t>
<t>
The conference focus of a chat room MUST include support for
a <xref target="RFC3862">Message/CPIM</xref> 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'.
</t>
<t>
<list style="empty">
<t>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).</t>
</list>
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Deleting a Chat Room">
<t>
As with creating a conference, the methods defined by the
<xref target="RFC4353" >SIP Conference Framework</xref>
for deleting a conference are directly applicable to a chat
room. The MSRP switch will terminate the MSRP sessions with
all the participants.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Sending and Receiving Instant Messages" anchor="im">
<section title="Regular Messages" anchor="regular">
<t>
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 <xref target="RFC3862">Message/CPIM wrapper </xref>
that in turn contains the desired payload (e.g. text, image,
video-clip, etc.).
</t>
<t>
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 <xref target="RFC4975">RFC
4975</xref>. The sender MAY choose the desired MSRP report
model (e.g., populate the Success-Report and Failure-Report
MSRP header fields).
</t>
<t>
The SEND request MUST contain a top-level wrapper of type
'Message/CPIM' according to <xref target="RFC3862">RFC
3862</xref>. 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.
</t>
<t>
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 identity by which the
user is recognized in the conference. Identities that can be
used (among others) are:
</t>
<t>
<list style="symbols">
<t>A <xref target="RFC3261">SIP URI</xref> representing the
participant's address-of-record</t>
<t>A <xref target="RFC3966">tel URI</xref> representing the
participant's telephone number</t>
<t>An <xref target="RFC3860">IM URI</xref> representing the
participant's instant messaging address</t>
<t>An Anonymous URI representing the participant's
anonymous address</t>
</list>
</t>
<t>
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 imposes a requirement for the focus
of the conference to inform the MSRP switch the URIs which
the participant is known, in order for the MSRP switch to
validate messages. <xref target="reports"/> provides further
information with the actions to be taken in case this
validation fails.
</t>
<t>
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 <xref target="RFC4975">RFC 4975</xref>.
</t>
<t>
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 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.
</t>
<t>
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.
</t>
<t>
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 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 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 a conference event package.
</t>
</section>
<section title="Private Messages" anchor="private-messages">
<t>
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 <xref
target="chatroom-attribute"/> for details).
</t>
<t>
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 <xref
target="regular"> regular messages </xref>. The only
difference is that the MSRP endpoint MUST populate a single 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 a conference event package.
</t>
<t>
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). <xref target="reports"/> provides further
information with the actions to be taken in case this
validation fails.
</t>
<t>
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 <xref target="RFC4975">RFC 4975</xref>.
</t>
<t>
Then the MSRP switch MUST verify that the To header of the
Message/CPIM wrapper is 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.
</t>
<t>
<list style="empty">
<t>
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.
</t>
</list>
</t>
<t>
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 indicate 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.
</t>
<t>
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.
</t>
<t>
An MSRP endpoint that receives a SEND request from the MSRP
switch does the same validations as for <xref
target="regular"> regular messages </xref>. 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.
</t>
<!--- Multiple calls using same participant URI -->
<t>
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 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.
</t>
</section>
<section title="MSRP reports and responses" anchor="reports">
<t>
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 <xref target="regular"/> or <xref
target="private-messages"/>, respectively.
</t>
<t>
MSRP switches MUST follow the success report and failure
report handling described in section 7 of <xref
target="RFC4975">RFC 4975</xref>, 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 <xref target="RFC4975">RFC 4975</xref>.
</t>
<t>
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 <xref
target="RFC4975">RFC 4975</xref>).
</t>
<t>
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 <xref
target="RFC4975">RFC 4975</xref>.
</t>
<t>
When the MSRP swtich 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.
</t>
</section>
</section>
<section anchor="nicknames" title="Nicknames">
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <xref
target="RFC6120">Extensible Messaging and Presence
Protocol</xref>. 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 <xref target="RFC2810">Internet Relay Chat
(IRC)</xref>.
</t>
<section title="Using Nicknames within a Conference"
anchor="using-nicknames" >
<t>
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.
</t>
<t>
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. MSRP NICKNAME requests MUST NOT include
Success-Report or Failure-Report header fields.
</t>
<t>
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 not allowed, the MSRP switch
must reject the request with a 501 response, as per <xref
target="RFC4975">RFC 4975</xref>.
</t>
<t>
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 (applied to SIP),
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 MSRP switch MUST answer the NICKNAME
request with a 200 response as per regular MSRP procedures.
</t>
<t>
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 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".
</t>
<t>
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.
</t>
<t>
The syntax of the NICKNAME method and the "Use-Nickname"
header field is built upon the
<xref target="RFC4975">MSRP formal syntax </xref>
</t>
<figure>
<artwork>
ext-method =/ NICKNAMEm
NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps
ext-header =/ Use-Nickname
; ext-header is specified in RFC 4975
Use-Nickname = "Use-Nickname" ":" nickname
nickname = quoted-string
</artwork>
</figure>
</section>
<section title="Modifying a Nickname"
anchor="mod-nicknames">
<t>
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
<xref target="using-nicknames" />.</t>
<t>
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.
</t>
</section>
<section title="Removing a Nickname">
<t>
If the participant no longer wants to be known by a nickname
in the conference, the participant can follow the method
described in <xref target="mod-nicknames" />.
The nickname element of the Use&nbhy;Nickname header MUST be
set to an empty quoted string.
</t>
</section>
<section title="Nicknames in Conference Event Packages">
<t>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 <xref target="I-D.ietf-xcon-event-package">
Conference Event Package Data Format Extension for Centralized Conferencing </xref>.
The <xref target="I-D.ietf-xcon-common-data-model">
Conference Information Data Model for Centralized Conferencing </xref>
extends the user element from
<xref target="RFC4575">RFC 4575</xref> with a nickname attribute.
</t>
</section>
</section>
<section title="The SDP 'chatroom' attribute"
anchor="chatroom-attribute" >
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
The 'chatroom' SDP attribute has the following syntax:
</t>
<figure>
<artwork>
chatroom = chatroom-label ":" chat-token *(SP chat-token)
chatroom-label = "chatroom"
chat-token = (nicknames-token | private-msg-token | token)
nicknames-token = "nicknames"
private-msg-token = "private-messages"
</artwork>
</figure>
<t>
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
<xref target="nicknames"/>. 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 <xref target="private-messages" />.
</t>
<t>
Example of the 'chatroom' attribute for an MSRP media stream
that indicates the acceptance of nicknames and private
messages:
</t>
<figure><artwork>
a=chatroom:nickname private-messages
</artwork></figure>
</section>
<section title="Examples" anchor="examples" >
<section title="Joining a chat room" anchor="example-join">
<t><xref target="fig-joining"/> 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.</t>
<figure anchor="fig-joining"
title="Flow diagram of a user joining a chat room"
align="center"><artwork><![CDATA[
Alice Conference focus
| |
|F1: (SIP) INVITE |
|----------------------->|
|F2: (SIP) 200 OK |
|<-----------------------|
|F3: (SIP) ACK |
|----------------------->|
| |
]]></artwork></figure>
<t>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.</t>
<figure><artwork><![CDATA[
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: [length]
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
]]></artwork></figure>
<t>
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
envelopes. It also includes the the chatroom attribute with the
allowed extensions.
</t>
<figure><artwork><![CDATA[
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: [length]
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
a=chatroom:nickname private-messages
]]></artwork></figure>
<t>
F3: The session established is acknowledged (details not
shown).
</t>
</section>
<section title="Setting up a nickname" anchor="example-nickname">
<t><xref target="fig-nickname"/> 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.</t>
<figure anchor="fig-nickname"
title="Flow diagram of a user setting up her nickname"
align="center"><artwork><![CDATA[
Alice MSRP switch
| |
|F1: (MSRP) NICKNAME |
|----------------------->|
|F2: (MSRP) 423 |
|<-----------------------|
|F3: (MSRP) NICKNAME |
|----------------------->|
|F4: (MSRP) 200 |
|<-----------------------|
| |
]]></artwork></figure>
<t>F1: Alice sends an MSRP NICKNAME request that contains her
proposed nicknames in the Use-Nickname header field.</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
<t>F2: The MSRP switch analyzes the existing allocation of
nicknames and detects that the nickname "Alice the great"
is already provided to another participant by the conference.
The MSRP switch answers with a 423 response.</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
<t>F3: Alice receives the response. She proposes a new
nickname in a second NICKNAME request.</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
<t>F4: The MSRP switch accepts the nickname proposal and
answers with a 200 response.</t>
<figure><artwork><![CDATA[
MSRP 09swk2d 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------09swk2d$
]]></artwork></figure>
</section>
<section title="Sending a regular message to the chat room" anchor="example-normal-message">
<t><xref target="fig-sending-regular-message"/> 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.</t>
<figure anchor="fig-sending-regular-message"
title="Sending a regular message to the chat room"
align="center"><artwork><![CDATA[
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 | |
| |<------------------------------ |
| | | |
| | | |
]]></artwork></figure>
<t>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.</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
<t>F2: The MSRP switch acknowledges the reception of the SEND
request with a 200 (OK) response.</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
<t>F3: The MSRP switch creates a new MSRP SEND request that
contains the received Message/CPIM body and sends it to Bob.</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
<t>The rest of the message flows are analogous to the
previous. They are not shown here.</t>
</section>
<section title="Sending a private message to a participant" anchor="example-private-message">
<t><xref target="fig-sending-private-message"/> 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.</t>
<figure anchor="fig-sending-private-message"
title="Sending a private message to Bob"
align="center"><artwork><![CDATA[
Alice MSRP switch Bob
| | |
| F1: (MSRP) SEND | |
|--------------------->| F3: (MSRP) SEND |
| F2: (MSRP) 200 |----------------------->|
|<---------------------| F4: (MSRP) 200 |
| |<-----------------------|
| | |
]]></artwork></figure>
<t>F1: Alice builds a text message and wraps it in a CPIM
message. She addresses the CPIM message to the Bob's URI,
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.</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
<t>F2: The MSRP switch acknowledges the reception of the SEND
request with a 200 (OK) response.</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
<t>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.</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
<t>F4: Bob acknowledges the reception of the SEND
request with a 200 (OK) response.
</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
</section>
<section title="Chuncked private message" anchor="example-chuncked">
<t>
The MSRP message below depicts an example of the private
message in <xref target="example-private-message" /> split
in two chuncks. The MSRP switch must wait for the complete
set of CPIM headers before distributing the messages.
</t>
<figure><artwork><![CDATA[
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$
]]></artwork></figure>
</section>
<section title="Nickname in a conference information document" anchor="example-nickname-conference">
<t><xref target="fig-nickname-conference" /> depicts two user elements in a conference information
document both having the nickname element with a nickname string.
</t>
<figure anchor="fig-nickname-conference"
title="Nickname in a conference information document"><artwork><![CDATA[
<?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>
]]></artwork></figure>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<section anchor="new-msrp-method" title="New MSRP Method">
<t>
This specification defines a new MSRP method to be added to
the Methods sub-registry of the Message Session Relay
Protocol (MSRP) Parameters registry:
</t>
<t>
<list style="empty">
<t>
NICKNAME
</t>
</list>
</t>
<t>
See section <xref target="nicknames"/> for details.
</t>
</section>
<section anchor="new-msrp-header" title="New MSRP Header">
<t>
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:
</t>
<t>
<list style="empty">
<t>
Use&nbhy;Nickname
</t>
</list>
</t>
<t>See <xref target="nicknames"/> for details.
</t>
</section>
<section anchor="new-msrp-status-codes" title="New MSRP Status Codes">
<t>
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.
</t>
<t>
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 <xref target="private-messages"/> for
details.
</t>
<t>
The 423 response indicates a failure in allocated the
requested NICKNAME. This can be caused by a malformed
NICKNAME request (e.g., no Use&nbhy;Nickname header field),
an already allocated nickname, or a policy that prevents the
sender to use nicknames. See <xref
target="nicknames"/> for details.
</t>
<t>
The 428 status code indicates that the recipient of a SEND
request does not support private messages. See section <xref
target="private-messages"/> for details.
</t>
<t>
<xref target="iana-status-codes"/> summarizes the IANA
registration data with respect to new MSRP status codes:
</t>
<texttable anchor="iana-status-codes" title="New status codes">
<ttcol align="center">Value</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="center">Reference</ttcol>
<c>404</c><c>Failure to resolve recipient's URI</c><c>RFC
XXXX</c>
<c>423</c><c>Unable to allocate requested nickname</c><c>RFC
XXXX</c>
<c>428</c><c>Private messages not supported</c><c>RFC XXXX</c>
</texttable>
</section>
<section anchor="new-sdp-attribute" title="New SDP Attribute">
<t> This specification defines a new media-level attribute in the
Session Description Protocol (SDP) Parameters registry. The
registration data is as follows:
</t>
<t>
<list>
<t>Contact: Miguel Garcia <miguel.a.garcia@ericsson.com></t>
<t>Phone: +34 91 339 1000</t>
<t>Attribute name: chatroom</t>
<t>Long-form attribute name: Chat Room</t>
<t>Type of attribute: media level only </t>
<t>This attribute is not subject to the charset attribute</t>
<t>Description: This attribute identifiers support and
local policy allowance for a number of chatroomt related
functions</t>
<t>Specification: RFC XXXX</t>
</list>
</t>
<t>
See section <xref target="chatroom-attribute"/> for details.
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>This document proposes extensions to the
<xref target="RFC4975">Message Session Relay
Protocol </xref>. Therefore, the security considerations of
such document apply to this document as well.
</t>
<t> If the participant's SIP user agent doesn't understand the
<xref target="RFC3840"> the "isfocus" feature tag </xref>,
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 unlikley that
it will try to send a message using
<xref target="RFC3862">'Message/CPIM' wrapper content type</xref>,
and the MSRP switch will reject the request with a
<xref target="RFC4975">415 response</xref>. Still if particpants's
MSRP client does create a message with a valid
<xref target="RFC3862">'Message/CPIM' wrapper content type</xref>
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 paricipant 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.
</t>
<t> If a participant wants to avoid eavesdropping, the participant's
MSRP client can send the messages over a
<xref target="RFC5246">TLS </xref> 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 the chat room using <xref target="RFC5246">TLS </xref> transport.
</t>
<t>
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.
</t>
</section>
<section anchor="contributors" title="Contributors">
<t>
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.
</t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The authors want to thank Eva Leppanen, Adamu Haruna,
Adam Roach, Matt Lepinski, Mary Barnes, Ben Campbell, Paul
Kyzivat, Adrian Georgescu, and Nancy Greene
for providing comments.
</t>
</section>
</middle>
<!-- ************************************************************** -->
<!-- The BACK section includes the rest of the stuff, references, -->
<!-- acknowledgements, authors addresses, etc. -->
<!-- ************************************************************** -->
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3264" ?>
<?rfc include="reference.RFC.3840" ?>
<?rfc include="reference.RFC.3860" ?>
<?rfc include="reference.RFC.3862" ?>
<?rfc include="reference.RFC.4353" ?>
<?rfc include="reference.RFC.4566" ?>
<?rfc include="reference.RFC.4575" ?>
<?rfc include="reference.RFC.4975" ?>
<?rfc include="reference.RFC.4976" ?>
<?rfc include="reference.RFC.5239" ?>
<?rfc include="reference.RFC.5246" ?>
<?rfc include="reference.I-D.ietf-xcon-common-data-model" ?>
<?rfc include="reference.I-D.ietf-xcon-event-package" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2810" ?>
<?rfc include="reference.RFC.6120" ?>
<?rfc include="reference.RFC.3966" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:46:32 |