One document matched: draft-ietf-simple-chat-17.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-17">
<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">
<address>
<email>aki.niemi@iki.fi</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">
<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="17" month="November" year="2012" />
<area>General</area>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>messaging</keyword>
<keyword>message sessions</keyword>
<keyword>multi-party</keyword>
<keyword>chat</keyword>
<keyword>MSRP</keyword>
<keyword>SIMPLE</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="RFC4566">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 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.
</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 eases interworking between these
systems.
</t>
<t>
This document defines requirements, conventions, and
extensions for providing private messages and nickname
management in centralized chat rooms 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 <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>. 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 chat rooms. </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 chat room participant who
originally created an instant message and sent it to the
chat room server for further delivery.</t>
<t hangText="Recipient: "> the destination chat room
participant(s). This defaults to the full conference
participant list minus the Instant Message (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 chat room
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 chat room participants.</t>
<t hangText="Private Instant Message: ">
an instant message sent in a chat room intended for a
single participant. Generally speaking, a private IM is
seen by the MSRP switch, in addition to the sender and
recipient. 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
chat room. The allocation of such a URI is out of scope of
this specification. An anonymous URI must be valid for the
length of the chat room session and will be utilized by the
MSRP switch to forward messages to and from anonymous
participants. Privacy and anonymity are discussed in greater
detail in <xref target="RFC3323">RFC 3323 </xref> and <xref
target="RFC3325">RFC 3325</xref>.
</t>
<t hangText="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 <xref
target="RFC4575">A Session Initiation Protocol (SIP) Event
Package for Conference State</xref> or <xref
target="RFC6502"> Conference Event Package Data Format
Extension for Centralized Conferencing</xref>.
</t>
<t hangText="Identifier:"> a string used to recognize or
establish as being a particular user.
</t>
<t hangText="To log in:"> to enter identifying data, as a
name or password, into a chat room, so as to be able
to do work with the chat room.
</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 (chat rooms) 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 chat rooms 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 chat room, where
participants can join and leave the chat room and get
instant messages exchanged to the rest of the
participants.
</t>
<t>
A recipient of an instant message in a chat room must be
able to determine the identifier of the sender of the
message. Note that the actual identifier depends on the
one which was used by the sender when they joined the
chat room.
</t>
<t>
A recipient of an instant message in a chat room must be
able to determine the identifier of the recipient of
received messages. For instance, the recipient of the
message might be the entire chat room or a single
participant (i.e., a private message). Note that the
actual identifier may depend on the one which was used by
the recipient when he or she joined the chat room.
</t>
<t>
It must be possible to send a message to a single
participant within the chat room (i.e., a private instant message).
</t>
<t>
A chat room participant may have a nickname or pseudonym
associated with their real identifier.
</t>
<t>
It must be possible for a participant to change their nickname
during the progress of the chat room session.
</t>
<t>
It must be possible that a participant is only known by an
anonymous identifier and not their real identifier to the rest
of the chat room.
</t>
<t>
It must be possible for chat room participants to
learn the chat room capabilities described in this document.
</t>
</list>
</t>
</section>
<section anchor="overview" title="Overview of Operation">
<t>
Before a chat room can be entered, it must be created. Users
wishing to host a chat room 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 identifier of its own: a SIP URI that
participants use to join the chat room, e.g. by sending an
INVITE request to it. 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 chat room 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" align="center">
<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 Chat Room"
anchor="arch" align="center">
<artwork>
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
</artwork>
</figure>
<t>
Typically chat room 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.
</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 chat room, 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 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 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, if the
recipient is logged in from different endpoints, the MSRP switch
will distribute the private message to each endpoint the
recipient is logged in.
</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. This is achieved by a new 'chatroom' attribute in
SDP (please refer to <xref target="chatroom-attribute"/> for a
detailed description).
</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 anchor="policy" title="Policy Attributes of the Chat Room">
<t>
The <xref target="RFC4353">Conference Framework with SIP
</xref> introduces the notion of a Conference Policy as a
complete set of rules governing a particular conference. In
the case of chat rooms, since they are a specialized type of
conferences, the notion of a Conference Policy exists and it
is sometimes extended with new chat-specific rules. This
section lists all the Conference Policy attributes used by
the present document and refers to sections in the document
where the usage of these attributes are described in greater
detail.
</t>
<t>
<list style="hanging">
<t hangText="Nicknames: ">Whether the chat room accepts
users to be recognized with a nickname. See <xref
target="nicknames"/>, <xref target="using-nicknames"/>,
and <xref target="chatroom-attribute"/> for details. Also,
the scope of uniqueness of the nickname: the chat room
(conference instance), a real or domain, a server, etc.
</t>
<t hangText="Nickname quarantine: ">The quarantine to be
imposed to a nickname once it is not currently in use
(e.g., because the participant holding this nickname
abandons the chat room), prior to the wide availability of
this nickname to other users. This allows the initial
holder of the nickname to join the chat room during the
quarantine period and claim the same nickname they were
previously using. See <xref target="security"/> for
details.
</t>
<t hangText="Private messaging: ">Whether the chat room
accepts users to send private messages to other
users of the chat room through the MSRP switch. See <xref
target="private-messages"/> and <xref
target="chatroom-attribute"/> for details.
</t>
<t hangText="Deletion of the chat room: ">Whether the chat
room can be deleted when the creator leaves the chat room
or through an out of band mechanism. See <xref
target="deleting-chatroom" /> for details.
</t>
<t hangText="Simultaneous access: ">Whether a user can log
from different endpoints using the same identity. See
<xref target="regular"/> and <xref
target="private-messages"/> for details.
</t>
<t hangText="Force TLS transport: ">Whether the MSRP
switch accepts only TLS as an MSRP transport, in an effort
to guarantee confidentiality and privacy. See <xref
target="security" /> for details.
</t>
<t hangText="Maximum message size in congested MSRP
sessions: ">The maximum size of messages that
can be distributed to a user over a congested MSRP
session. See <xref target="congestion"/> for details.
</t>
<t hangText="Chunk reception timer: ">The value of a time
that controls the maximum time that the MSRP switch is
waiting for the reception of different chunks belonging to
the same message. If the timer expires, the MSRP switch
will discard the associated message state. See <xref
target="regular"/> for details.
</t>
<t hangText="Supported wrapped media types: ">The list of
media types that the MSRP switch accepts in
Message/CPIM wrappers sent from participants. This list is
included in the 'accept-wrapped-types' attribute of the
MSRP message media line in SDP. If the MSRP switch accepts
additional media types than those explicitly listed, a "*"
is added to the list. A single "*" indicates that the chat
room accepts any wrapped media type.
</t>
</list>
</t>
</section>
</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 chat room by sending an INVITE
request to the chat room URI. The chat room them uses
regular SIP mechanisms to authenticate the participant. This
may include, e.g., client certificates, <xref
target="RFC3261">SIP Digest authentication </xref>, <xref
target="RFC3325">asserted network identity </xref>, <xref
target="RFC4474">SIP Identity header field </xref>, etc. As
long as the user is authenticated, the INVITE request is
accepted by the focus and the user is brought into the
actual chat room.
</t>
<t>
This specification requires all instant messages to be
wrapped in a <xref target="RFC3862">Message/CPIM wrapper
</xref>. Therefore, the 'accept-types' attribute for the
MSRP message media in both the SDP offer and answer need to
include at least the value 'Message/CPIM'. If not, the
conference focus will reject the request. The actual instant
message payload type is negotiated in the
'accept-wrapped-types' attribute in SDP (see <xref
target="RFC4975">RFC 4975 </xref> for details). There is no
default wrapped type. Typical wrapped type values can
include: text/plain, text/html, image/jpeg, image/png,
audio/mp3, etc. It is RECOMMENDED that participant endpoints
add an 'accept-wrapped-types' attribute to the MSRP
'message' media line in SDP, where the supported wrapped
types are declared, as per <xref target="RFC4975">RFC 4975
procedures </xref>.
</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 only use a <xref
target="RFC3862">Message/CPIM</xref> top-level wrapper as a
payload of MSRP messages, and the focus MUST declare it in
the SDP offer or answer as per regular <xref
target="RFC4975">RFC 4975 procedures </xref>. This implies
that if the conference focus receives from a participant's
endpoint an SDP offer that does not include the value
'Message/CPIM' in the 'accept-types' attribute for the MSRP
message media line, the conference focus SHOULD either
reject the MSRP message media stream or the complete SDP
offer by using regular SIP or SDP procedures (e.g., creating
an SDP answer that sets to zero the port of the MSRP message
media line, responding the INVITE with a 488 response,
etc.).
</t>
<t>
If the conference focus accepts the participant's SDP offer,
when the conference focus generates the SDP answer, it MUST
set the 'accept-types' attribute for the MSRP message media
line to a value of 'Message/CPIM'. This specification
requires all instant messages to be wrapped in a
Message/CPIM wrapper, therefore, the 'accept-types'
attribute in this SDP body contains a single value of
'Message/CPIM'. The actual instant message payload type is
negotiated in the 'accept-wrapped-types' attribute in SDP
(see <xref target="RFC4975">RFC 4975 </xref> for
details). The conference focus MAY also add an
'accept-wrapped-types' attribute to the MSRP message media
line in SDP containing the supported wrapped types,
according to the supported wrapped media types policy.
</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 the user agent supports anonymous participation and the
user chooses to use it, the participant's UA
SHOULD do at least one of these options:
</t>
<t>
<list style="format (%c)">
<t>
provide an anonymous URI in SIP headers that otherwise
reveal identifiers. Please refer to <xref
target="RFC3323">RFC 3323</xref> for a detailed
description of which headers are subject to reveal
identifiers and how to populate them; or
</t>
<t>
trust the conference focus and request privacy of their
URI, e.g, by means of the <xref target="RFC3323">SIP
Privacy header field </xref>, <xref
target="RFC3325">Network asserted identity </xref>, or
similar privacy mechanism.
</t>
</list>
</t>
<t>
If the participant has requested privacy, the conference
focus MUST expose a participant's anonymous URI through the
<xref target="RFC4575">conference event package </xref>.
</t>
<t>
The conference focus of a chat room MUST inform the MSRP
switch of the chat room capabilities of each participant
that joins the chat room in order to prevent the MSRP switch
from distributing private messages to participants who do
not support private messaging. This is achieved by the
exchange of new 'chatroom' attributes in SDP (please refer
to <xref target="chatroom-attribute"/> for a detailed
description). 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 anchor="deleting-chatroom" 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 chat room, 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 payload of the 'Message/CPIM' wrapper will
be the actual instant message payload, and, according to
<xref target="RFC4975">RFC 4975</xref>, it needs to be one
of those negotiated in the 'accept-wrapped-types' attribute
in SDP.
</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 MUST also populate the From header of the
Message/CPIM wrapper with a proper identifier by which the
user is recognized in the chat room. Identifiers 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>
If the participant wants to remain anonymous, the
participant's endpoint MUST populate an anonymous URI in the From
header of the 'Message/CPIM' wrapper. Other participants of
the chat room will use this anonymous URI in the To header
of the 'Message/CPIM' wrapper when sending private
messages. 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>
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 of the
URIs by 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>
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 <xref
target="RFC4975">RFC 4975</xref>. 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 chat room 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>
<!-- The following text needs to be confirmed by the mailing list -->
<t>
When generating a copy of the SEND request to each
participant in the chat room, the MSRP switch MUST evaluate
the wrapped media types that the recipient is able to
accept. This was learned through the 'accept-wrapped-types'
attribute of the MSRP message media line in SDP. If the MSRP
switch is aware that the media type of the wrapped content
is not acceptable to the recipient, the MSRP switch SHOULD
NOT forward this message to that endpoint. Note that this
version of the specification does not require the MSRP
switch to notify the sender about this failure. Extensions
to this specification may improve handling of unknown media
types.
</t>
<!--- Chunked messages -->
<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 wrapper it SHOULD start the
distribution process. But bear in mind that still the MSRP
switch SHOULD implement some sanity checking. Please refer
to the security considerations in <xref target="security" />
for further details.
</t>
<t>
When forwarding chunked messages as soon as they are
received, the Message/CPIM wrapper is only present at the
beginning of the message, typically within the first
chunk. Subsequent chunks will contain the rest of the
message, but not the Message/CPIM headers. Therefore, an
MSRP switch that receives a subsequent message may face
challenges in determining the correct list of recipients of
the message. An MSRP switch that uses this fast forwarding
procedure MUST temporarily store the Message-Id of the MSRP
message to correlate the different chunks, as well as it
MUST temporarily store the list of recipients to which the
initial chunks were delivered. The MSRP switch SHOULD
forward subsequent chunks only to those recipients who were
sent the initial chunks, except if the MSRP switch has
knowledge that one of the recipients of the initial chunks
has dropped from the chat room. This behavior also avoids
new participants who joined the chat room when the first
chunk has been distributed to receive subsequent chunks that
would otherwise need to be discarded.
</t>
<t>
Once the MSRP switch receives the last chunk of a message,
and that chunk is successfully sent to each of the
recipients, the MSRP switch MUST discard the temporary
storage of MSRP Message-ID and the associated list of
recipients.
</t>
<!--- This problem with chunk messaging might be also
applicable to the non-fast forwarding mechanism -->
<t>
In some occasions, a sender might suffer a transport error
condition (such as loss of connectivity or depletion of
battery) that makes the sending of a message incomplete,
e.g., some chunks were received by the MSRP switch, but not
all of them. This is a behavior already considered in the
core MSRP specification (see <xref target="RFC4975"> RFC
4975 </xref> Section 5.4). The problem in the context of a
chat room lies with the usage of temporary storage for fast
forwarding. In order to prevent attacks related to the
exhaustion of temporary storage of chunked messages, on
receiving a first chunk of a message, where the MSRP switch
is using the fast forward method, the MSRP switch MUST set a
chunk reception timer for controlling the reception of the
remaining chunks.
</t>
<t>
This chunk reception timer can be re-set every time a new
chunk of the same message is received. When this timer
fires, the MSRP switch MUST consider that the sending of the
message was aborted, and MAY discard all the message state
associated to it, including the Message-ID and the list of
recipients. Additionally, if this chunk reception timer
fires, the MSRP switch MAY choose to send an abort chunk
(i.e., one with the "#" flag set) to each to the
recipients. This is just an optimization, since MSRP
endpoints need to be able to handle incomplete messages as
per regular MSRP.
</t>
<t>
The specific value of this chunk reception timer is not
standardized; it is subject of local policy. However, it is
recommended not to be a short value. For example a time interval
on the order of a normal TCP timeout (i.e., around 540
seconds) would be reasonable. A value on the order of a few
seconds would not.
</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 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 chat room. 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.
</t>
<!--- Simultaneous access using same participant URI -->
<t>
It is possible that a participant, identified by a SIP
Address of Record or other valid URI, joins a chat room
simultaneously from two or more different SIP UAs. It is
recommended that the MSRP switch implements means to map a
URI to two or more MSRP sessions. If the policy of the chat
room allows simultaneous access, the MSRP switch MUST copy
all regular messages intended to the recipient through each
MSRP session mapped to the recipient's URI.
</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. The chat room has local policy that
determines whether private messages are supported or not. A
chat room can signal support for private messages using the
'chatroom' attribute in SDP (please refer to <xref
target="chatroom-attribute"/> for a detailed description).
</t>
<t>
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 <xref target="regular"> regular messages </xref>. The
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.
</t>
<t>
<list style="empty">
<t>
This version of the specification does not support
sending a private message to multiple recipients, i.e.,
the presence of multiple To headers in the Message/CPIM
wrapper of the MSRP SEND request. This is due to added
complexity, for example, with the need to determine
whether a message was not deliver to some of the
intended recipients. Implementations that still want to
recreate this function can send a series of single
private messages, one private message per intended
recipient. The endpoint can correlate this series of
messages and create the effect of a private message
addressed to multiple recipients.
</t>
</list>
</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>
Then the MSRP switch inspects 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 <xref
target="RFC4975">RFC 4975</xref>. Then the MSRP switch
verifies 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.
</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 verifies 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.
</t>
<t>
If successful, the MSRP switch should search its mapping
table to find the MSRP sessions established toward 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>
<!--- Simultaneous access using same participant URI -->
<t>
As with regular messages, if the policy of the chat room
allows simultaneous access, the MSRP switch
MUST copy all private messages intended to the recipient through
each MSRP session mapped to the recipient's URI.m
</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 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.
</t>
</section>
<section anchor="congestion" title="Congestion Avoidance">
<t>
Congestion can occur when multiple heterogeneous interfaces
are used by a diversity of users who are participating in a
chat room, and, in particular, when paths become overloaded
by any application. Some of these users might have fast path
capable of high throughputs while other users might be slow
paths with constrained throughputs. Some paths might become
congested only by the chat application; other paths gets
congested by other applications different than the chat
one. It is therefore possible that a subset of the
participants of the chat room are able to send and receive a
large number of messages in a short time or with large
contents (e.g., pictures), whereas others are not able to
keep the pace.
</t>
<t>
Additionally, since MSRP uses a connection-oriented
transport protocol such as TCP, it is expected that
the TCP congestion avoidance mechanisms will also be
activated should congestion occur.
</t>
<t>
While this document does not mandate a particular
MSRP-specific mechanism to avoid congestion in any of the
paths, something that is deemed outside the scope of this
document, this document provides some recommendations for
implementors to consider.
</t>
<t>
It is RECOMMENDED that MSRP switches implement one or more
MSRP-specific strategies to detect and avoid
congestion. Possible strategies (but definitely not a
comprehensive list) include:
</t>
<t>
<list style="symbols">
<t>If the MSRP switch is writing data to a send buffer and
detects that the send buffer associated to that TCP
connection is getting full (e.g., close to 80% of its
capacity), the MSRP switch marks the associated MSRP
sessions making use of that TCP connection as "congested".
</t>
<t>Prior to sending a new MSRP message to a user, the MSRP
switch verifies the congested flag associated to that MSRP
session. If the MSRP session is marked as congested, the
MSRP switch can apply a congestion avoidance mechanism,
such as:
<list style="symbols">
<t>
The MSRP switch can discard regular MSRP messages
sent to that user while the TCP send buffer is
congested. In order to inform the user of the
congestion, the MSRP switch can send a regular MSRP
message indicating the user that some messages are
discarded due to network congestion.
</t>
<t>
The MSRP can implement a temporary policy to
disallow the distribution of messages larger than a
certain size to MSRP sessions marked as
congested. Similarly, the user should be informed of
this fact by the MSRP switch sending a regular MSRP
message indicating this condition.
</t>
</list>
</t>
</list>
</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
chat room. 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. 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.
</t>
<t>
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.
</t>
<t>
This memo specifies the nickname as a string. The nickname
string MUST unambiguously be associated to a single user in
the scope of the chat room (conference instance). This scope
is similar to having a nickname unique per user 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 Chat Room"
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 chat room 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. This nickname string MUST NOT be zero octets in
length and MUST NOT be more than 1023 octets in
length. Last, MSRP NICKNAME requests MUST NOT include
Success-Report or Failure-Report header fields.
</t>
<t><list style="empty">
<t>
Bear in mind that nickname strings, like the rest of the
MSRP message, use the <xref target="RFC3629"> UTF-8
transformation format </xref>. Therefore, a character may
be result encoded in more than one octet.
</t>
</list></t>
<t>
An MSRP switch that receives a NICKNAME request containing
a 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 403 response, as per <xref
target="RFC4975">RFC 4975</xref>.
</t>
<!--- Nickname comparison text below -->
<t>
If the policy of the chat room allows the usage of
nicknames, any new nickname requested MUST be prepared and
compared with nicknames already in use or reserved
following the rules defined in
<xref target="I-D.ietf-precis-nickname">Preparation and
Comparison of Nicknames </xref>.
</t>
<t>
This mitigates the problem of nickname duplication, but it
does not solve a problem whereby users can choose similar
(but different) characters to represent two different
nicknames. For example, "BOY" and "B0Y" are different
nicknames which can mislead users. The former uses the
capital letter "O" while the latter uses the number zero
"0". In many fonts the letter "O" and the number zero "0"
might be quite similar, and difficult to be perceived as
different characters. Chat rooms MAY provide a mechanism to
mitigate confusable nicknames.
</t>
<t>
In addition to preparing and comparing following the rules
above, the MSRP switch SHOULD only allow the reservation of
an already used nickname, if the same user (e.g., identified
by the SIP AOR) that is currently using the nickname is
making this subsequent request. 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
<xref target="RFC3261">SIP Digest Authentication </xref>, be
included in a trusted <xref target="RFC3325">SIP
P-Asserted-Identity header field </xref>, be included in a
valid <xref target="RFC4474">SIP Identity header field
</xref>, 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 verifies if the
suggested nickname can be accepted (see below).
</t>
<t>
The reservation of a nickname can fail in several cases. If
the NICKNAME request contains a malformed value in the
Use&nbhy;Nickname header field, the MSRP switch MUST answer
the NICKNAME request with a 424 response code. This can be
the case when the value of the Use&nbhy;Nickname header
field does not conform to the syntax.
</t>
<t>
The reservation of a nickname can also fail if the value of
the Use&nbhy;Nickname header field of the NICKNAME request
is a reserved word (not to be used as a nickname by any
user) or that particular value is already in use by another
user. In this case the MSRP switch MUST answer the NICKNAME
request with a 425 response code.
</t>
<t>
In both error conditions (receiving a 424 or 425 response
code), the nickname usage is considered failed; the nickname
is not allocated to this user. The user can select a
different nickname and retry another NICKNAME request.
</t>
<t>
If the MSRP switch is able to accept the suggested nickname
to be used by this user, the MSRP switch MUST answer the
NICKNAME request with a 200 response as per regular MSRP
procedures.
</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. This specification defines
the usage of the Use&nbhy;Nickname header field in NICKNAME
requests. If need arises, usages of the Use&nbhy;Nickname
header field in other MSRP methods should be specified
separately.
</t>
<t>
According to <xref target="RFC4975">RFC 4975</xref>, MSRP
uses the <xref target="RFC3629"> UTF-8 transformation
format</xref>. The syntax of the MSRP NICKNAME method and the
"Use-Nickname" header field is built upon the <xref
target="RFC4975">MSRP formal syntax </xref> using the
<xref target="RFC5234">Augmented Backus-Naur Form (ABNF) </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 defined in RFC 4975
Use-Nickname = "Use-Nickname:" SP nickname
nickname = DQUOTE 1*1023(qdtext / qd-esc) DQUOTE
; qdtext and qd-esc defined in RFC 4975
</artwork>
</figure>
<t>
Note that, according to <xref target="RFC4975">RFC 4975</xref>,
"quoted-string" admits a subset of <xref target="RFC3629">
UTF-8 characters </xref>. Please
refer to Section 9 of <xref target="RFC4975">RFC 4975</xref>
for more details.
</t>
<t>
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 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.
</t>
</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 chat room, 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, <xref target="RFC4575">RFC 4575
</xref>. It is RECOMMENDED that conference foci and
endpoints support <xref target="RFC6502"> RFC 6502 </xref>
for providing information regarding the conference, and in
particular, supplying information of the roaster of the
conference. It is also RECOMMENDED that conference foci and
endpoints support <xref target="RFC6501">RFC 6501 </xref>,
which extends the <user> element originally specified
in <xref target="RFC4575">RFC 4575</xref> with a new
'nickname' attribute. This allows endpoints to learn the
nicknames of participants of the chat room.
</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
local policy of 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'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.
</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 <xref target="RFC4566">media-level value
attribute </xref> 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 chat
room. The 'chatroom' attribute can be complemented with
additional modifiers that further indicate the intersection of
support and 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' attribute merely indicates the capabilities
supported and allowed by the local policy. This attribute is
not a negotiation subject to the <xref target="RFC3264">SDP
offer/answer model</xref>, but instead a
declaration. Therefore, a 'chatroom' attribute included in an
SDP answer does not need to be a subset of the values included
in the 'chatroom' attribute of its corresponding SDP
offer. Consequently, an SDP answer MAY contain a 'chatroom'
attribute even if its corresponding SDP offer did not include
it.
</t>
<t>
On doing subsequent <xref target="RFC3264">SDP
offer/answer</xref> exchanges pertaining to the same session,
the 'chatroom' attribute MAY be modified with respect an
earlier SDP offer/answer exchange. The new value of this
attribute indicate the current support and local policy,
meaning that some restrictions can apply now or might have
been removed. If the 'chatroom' attribute is not included in a
subsequent SDP offer/answer, but is corresponding MSRP stream
is still in place, it indicates that support for the
procedures indicated in this document are disabled.
</t>
<t>
The 'chatroom' SDP attribute has the following <xref
target="RFC5234">Augmented BNF (ABNF) </xref> syntax:
</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>
A given 'chat-token' value MUST NOT appear more than once in a
'chatroom' attribute.
</t>
<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 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 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>
<t>
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.
</t>
<figure><artwork>
a=chatroom
</artwork></figure>
<t>
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.
</t>
<t>
Extensions defined in IETF document MUST follow the
'standard-token' ABNF previously defined. In this type of
extensions, care must be taken in the selection of the token to
avoid a clash with any of the tokens previously defined.
</t>
<t>
Private extensions MUST follow the 'private-token' ABNF
previously defined. The 'private-token' MUST include the DNS
name of the vendor. Then the token is reversed in order to
avoid clashes of tokens. The following is an example of a
extension named "foo.chat" by a vendor "example.com"
</t>
<figure><artwork>
a=chatroom:nickname private-messages com.example.chat.foo
</artwork></figure>
<t>
Note that feature names created by different organizations are
not intended to have the same semantics or even interoperate.
</t>
</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: 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
]]></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 forces the reception of messages wrapped in
Message/CPIM wrappers. It also includes 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: 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
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 chat room 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.</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) 425 |
|<-----------------------|
|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 in the chat room.
The MSRP switch answers with a 425 response.</t>
<figure><artwork><![CDATA[
MSRP d93kswow 425 Nickname reserved or already in use
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
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.</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 wrapper 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>
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.
</t>
<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
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.</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 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.</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="Chunked private message" anchor="example-chunked">
<t>
The MSRP message below depicts the example of the same
private message described in <xref
target="example-private-message"/>, 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.
</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 an XML
Conference Information Document received in a SIP NOTIFY
request as a notification to the XCON Conference Event
Package, <xref target="RFC6502">RFC 6502 </xref>. The
Conference Information Document follows the XCON Data Model
specified in <xref target="RFC6501">RFC 6501 </xref>.
</t>
<t>
The Conference Information Document of <xref
target="fig-nickname-conference" /> presents information of
two users who are participating in the conference (see each
of the <user> elements). Each participant is bound to
a nickname, shown in the 'nickname' attribute of the
<user> element.
</t>
<t>
<list style="hanging">
<t>NOTE: The purpose of <xref
target="fig-nickname-conference" /> is to show the
user-to-nickname relation. It is believed that the example
is correct, according to <xref target="RFC6501">RFC 6501
</xref>. In case of contradictions between this
specification and <xref target="RFC6501">RFC 6501</xref>,
the latter has precedence over this one.
</t>
</list>
</t>
<figure anchor="fig-nickname-conference"
title="Nickname in a conference information document" align="center"><artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
xmlns:xcon="urn:ietf:params:xml:ns:xcon-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"
xcon:nickname="Dopey Donkey">
<display-text>Bob Hoskins</display-text>
</user>
<!--
USER
-->
<user entity="sip:alice@atlanta.example.com"
state="full"
xcon:nickname="Alice the great">
<display-text>Alice Kay</display-text>
</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's 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 424 status code indicates a failure in allocating the
requested nickname due to a malformed syntax in the
Use&nbhy;Nickname header field. See <xref
target="nicknames"/> for details.
</t>
<t>
The 425 status code indicates a failure in allocating the
requested nickname because the requested nickname in the
Use&nbhy;Nickname header field is reserved or is already in
use by another user. 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 <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>424</c><c>Malformed nickname</c><c>RFC
XXXX</c>
<c>425</c><c>Nickname reserved or already in use</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 identifies support and
local policy allowance for a number of chat room 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 that
document apply to this document as well.
</t>
<t>
If the participant's SIP user agent does not understand the
<xref target="RFC3840"> "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 does not support the extensions of this specification,
it is unlikely 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 a
participant'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 chat room, 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 chat room, the message can be
forwarded as a private message without the participant
knowing.
</t>
<t>
To mitigate these problems, when the chat room detects that a
user agent does not support the procedures of this document
(i.e., when the SIP User Agent is not chat room aware), the
MSRP switch SHOULD send a regular MSRP message indicating that
the SIP User Agent is actually part of a chat room, and that
all the messages that the user sends correctly formated will
be distributed to a number of participants. Additionally, the
MSRP switch SHOULD also send a regular MSRP text message
including the list of participants in the chat room, so that
the user becomes aware of the roster.
</t>
<t>
If a participant wants to avoid security concerns on the path
between himself and the MSRP switch (e.g., being eavesdropped,
faked packet injection, or packet corruption), the
participant's user agent can force the usage of <xref
target="RFC5246">TLS </xref> in the SDP offer/answer
negotiation as per regular <xref target="RFC4975">RFC 4975
</xref> procedures. This will result in MSRP messages being
sent over a <xref target="RFC5246">TLS </xref> transport
connection. The MSRP switch may also have local policy that
forces the usage of TLS transport for all MSRP sessions,
something that is also negotiated in SDP as per regular <xref
target="RFC4975">RFC 4975 </xref> procedures.
</t>
<t>
Nicknames are used to show the appearance of the participants
of the chat room. 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. The chat room has a policy that
determines the time that a nickname is still reserved to its
holder, once it is no longer in used. This allows, e.g., a
user that accidentally looses its connectivity, to re-connect
to the chat room and keep on using the same nickname. It is up
to the policy of the chat room to determine if a nickname that
has been previously used by another participant of the chat
room can be reserved or not.
</t>
<t>
<xref target="using-nicknames"/> discusses the problem of
similar but different nicknames (e.g., thanks to the use of
similar characters), and chat rooms MAY provide a mechanism to
mitigate confusable nicknames.
</t>
<t>
Recipients of instant messages should be cautious with the
rendering of content, which can be malicious in nature. This
includes, but it is not only restricted to, the reception of
HTML and Javascript scripts, executable code, phishing
attempts, etc. Endpoints SHOULD always request permission from
the user before executing one of these actions.
</t>
<t>
It must be noted that endpoints using TLS client side
certificate with real names in the certificates will not be
anonymous to the MSRP switch they connect to. While the name
in the certificate might not be used by MSRP, the server will
have a certificate with the actual name in it.
</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 (Huawei), 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, Nancy Greene, Cullen Jennings, Flemming
Andreasen, Suresh Krishnan, Christer Holmberg, Saul Ibarra,
Enrico Marocco, Alexey Melnikov, and Peter Saint-Andre for
providing comments.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3264" ?>
<?rfc include="reference.RFC.3323" ?>
<?rfc include="reference.RFC.3629" ?>
<?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.5234" ?>
<?rfc include="reference.RFC.5239" ?>
<?rfc include="reference.RFC.5246" ?>
<?rfc include="reference.RFC.6501" ?>
<?rfc include="reference.RFC.6502" ?>
<?rfc include="reference.I-D.ietf-precis-nickname" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2810" ?>
<?rfc include="reference.RFC.3325" ?>
<?rfc include="reference.RFC.3966" ?>
<?rfc include="reference.RFC.4474" ?>
<?rfc include="reference.RFC.6120" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:46:30 |