GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7701

Internet Engineering Task Force (IETF) A. Niemi Request for Comments: 7701 Category: Standards Track M. Garcia-Martin ISSN: 2070-1721 Ericsson

                                                         G. Sandbakken
                                                         Cisco Systems
                                                         December 2015
  Multi-party Chat Using the Message Session Relay Protocol (MSRP)

Abstract

 The Message Session Relay Protocol (MSRP) defines a mechanism for
 sending instant messages (IMs) within a peer-to-peer session,
 negotiated using the Session Initiation Protocol (SIP) and the
 Session Description Protocol (SDP).  This document defines the
 necessary tools for establishing multi-party chat sessions, or chat
 rooms, using MSRP.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7701.

Niemi, et al. Standards Track [Page 1] RFC 7701 Multi-party Chat MSRP December 2015

Copyright Notice

 Copyright (c) 2015 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Niemi, et al. Standards Track [Page 2] RFC 7701 Multi-party Chat MSRP December 2015

Table of Contents

 1. Introduction ....................................................4
 2. Terminology .....................................................5
 3. Motivations and Requirements ....................................6
 4. Overview of Operation ...........................................7
    4.1. Policy Attributes of the Chat Room ........................10
 5. Creating, Joining, and Deleting a Chat Room ....................12
    5.1. Creating a Chat Room ......................................12
    5.2. Joining a Chat Room .......................................12
    5.3. Deleting a Chat Room ......................................14
 6. Sending and Receiving Instant Messages .........................14
    6.1. Regular Messages ..........................................14
    6.2. Private Messages ..........................................17
    6.3. MSRP Reports and Responses ................................19
    6.4. Congestion Avoidance ......................................20
 7. Nicknames ......................................................21
    7.1. Using Nicknames within a Chat Room ........................22
    7.2. Modifying a Nickname ......................................24
    7.3. Removing a Nickname .......................................25
    7.4. Nicknames in Conference Event Packages ....................25
 8. The SDP 'chatroom' Attribute ...................................25
 9. Examples .......................................................28
    9.1. Joining a Chat Room .......................................28
    9.2. Setting Up a Nickname .....................................30
    9.3. Sending a Regular Message to the Chat Room ................31
    9.4. Sending a Private Message to a Participant ................33
    9.5. Chunked Private Message ...................................35
    9.6. Nickname in a Conference Information Document .............35
 10. IANA Considerations ...........................................37
    10.1. New MSRP Method ..........................................37
    10.2. New MSRP Header ..........................................37
    10.3. New MSRP Status Codes ....................................37
    10.4. New SDP Attribute ........................................38
 11. Security Considerations .......................................38
 12. References ....................................................40
    12.1. Normative References .....................................40
    12.2. Informative References ...................................43
 Acknowledgments ...................................................43
 Contributors ......................................................43
 Authors' Addresses ................................................44

Niemi, et al. Standards Track [Page 3] RFC 7701 Multi-party Chat MSRP December 2015

1. Introduction

 The Message Session Relay Protocol (MSRP) [RFC4975] defines a
 mechanism for sending a series of instant messages within a session.
 The Session Initiation Protocol (SIP) [RFC3261] in combination with
 the Session Description Protocol (SDP) [RFC4566] allows for two peers
 to establish and manage such sessions.
 In another application of SIP, a User Agent (UA) can join in a multi-
 party conversation called a "conference" that is hosted by a
 specialized UA called a "focus" [RFC4353].  Such a conference can
 naturally involve MSRP sessions.  It is the responsibility of an
 entity handling the media to relay IMs received from one participant
 to the rest of the participants in the conference.
 Several such systems already exist in the Internet.  Participants in
 a chat room can be identified with a pseudonym or nickname and can
 decide whether their real identifier is disclosed to other
 participants.  Participants can also use a rich set of features such
 as the ability to send private instant messages to other
 participants.
 Similar conferences supporting chat room functionality are already
 available today.  For example, Internet Relay Chat (IRC) [RFC2810],
 Extensible Messaging and Presence Protocol (XMPP): Core [RFC6120], as
 well as many other proprietary systems.  Specifying equivalent
 functionality for MSRP-based systems eases interworking between these
 systems.
 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 should be
 disclosed to other participants.  This memo uses the SIP Conferencing
 Framework [RFC4353] as a design basis.  It also aims to be compatible
 with "A Framework for Centralized Conferencing" [RFC5239].  Should
 requirements arise, future mechanisms for providing similar
 functionality in generic conferences might be developed, for example,
 where the media is not only restricted to MSRP.  The mechanisms
 described in this document provide a future compatible short-term
 solution for MSRP centralized chat rooms.

Niemi, et al. Standards Track [Page 4] RFC 7701 Multi-party Chat MSRP December 2015

2. Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in BCP 14 [RFC2119] and
 indicate requirement levels for compliant implementations.
 This memo deals with "Tightly Coupled SIP Conferences" as defined in
 the SIP Conferencing Framework [RFC4353] and adopts the terminology
 from that document.  In addition, we introduce some new terms:
 Nickname:   a pseudonym or descriptive name associated with a
    participant.  See Section 7 for details.
 Multi-party Chat:   an instance of a tightly coupled conference, in
    which the media exchanged between the participants consist of
    MSRP-based IMs.  Also known as a chat room.
 Chat Room:   a synonym for a multi-party chat.
 Chat Room URI:   a URI that identifies a particular chat room and
    that is a synonym of a "Conference URI" as defined in RFC 4353
    [RFC4353].
 Sender:   the chat room participant who originally created an IM and
    sent it to the chat room server for further delivery.
 Recipient:   the destination chat room participant(s).  This defaults
    to the full conference participant list minus the IM Sender.
 MSRP Switch:   a media-level entity that is an 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.
 Private IM:   an IM 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.
 Anonymous URI:  a URI concealing the participant's SIP address of
    record (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

Niemi, et al. Standards Track [Page 5] RFC 7701 Multi-party Chat MSRP December 2015

    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 RFC 3323 [RFC3323]
    and RFC 3325 [RFC3325].
 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
    the mechanisms defined in "A Session Initiation Protocol (SIP)
    Event Package for Conference State" [RFC4575] or "Conference Event
    Package Data Format Extension for Centralized Conferencing (XCON)"
    [RFC6502].
 Identifier:  a string used to recognize or establish as being a
    particular user.
 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.

3. Motivations and Requirements

 Although conference frameworks describing many types of conferencing
 applications already exist, such as the one in "A Framework for
 Centralized Conferencing" [RFC5239] and the SIP Conferencing
 Framework [RFC4353], the exact details of session-based instant
 messaging conferences (chat rooms) are not well-defined at the
 moment.
 To allow interoperable chat implementations, for both conference-
 aware and conference-unaware UAs, 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 to enable the building of interworking
 gateways to these existing chat systems.
 We define the following requirements:
 REQ-1:  A basic requirement is the existence of a chat room, where
         participants can join and leave the chat room and exchange
         IMs with the rest of the participants.
 REQ-2:  A recipient of an IM 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 that was used by the
         sender when joining the chat room.

Niemi, et al. Standards Track [Page 6] RFC 7701 Multi-party Chat MSRP December 2015

 REQ-3:  A recipient of an IM 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 that
         was used by the recipient when he or she joined the chat
         room.
 REQ-4:  It must be possible to send a message to a single participant
         within the chat room (i.e., a private IM).
 REQ-5:  A chat room participant may have a nickname or pseudonym
         associated with their real identifier.
 REQ-6:  It must be possible for a participant to change their
         nickname during the progress of the chat room session.
 REQ-7:  It must be possible for a participant to be known only by an
         anonymous identifier and not their real identifier by the
         rest of the chat room.
 REQ-8:  It must be possible for chat room participants to learn the
         chat room capabilities described in this document.

4. Overview of Operation

 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 UA
 simply morphs from an ordinary UA into a special purpose one called a
 "Focus UA".  Another, commonly used setup is one where a dedicated
 node in the network functions as a Focus UA.
 Each chat room has an identifier of its own: a SIP URI that
 participants use to join the 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 RFC 4976 [RFC4976].  This is illustrated in Figure 1.

Niemi, et al. Standards Track [Page 7] RFC 7701 Multi-party Chat MSRP December 2015

                      MSRP Sessions
              +--------------------------+
              |                          |
          +---+--+    +---+--+           |
          | SIP  |    | SIP  |           |
          | MSRP |    | MSRP |     +-----+-----+
          |Client|    |Client|     |   MSRP    |
          +---+--+    ++--+--+     |   Relay   |
              |        |   \       +-----+-----+
  SIP Dialogs |       /     +----+       |
              |      |            \      | MSRP Sessions
         +----+------+--+          |     |
         |              |        +-+-----+-----+
         |  Conference  |        |    MSRP     |
         |  Focus UA    |........|    Switch   |
         |              |        |             |
         +----+-------+-+        +-+-----+-----+
              |        \           |     |
  SIP Dialogs |        |    +------+     | MSRP Sessions
              |         \  /             |
          +---+--+    +-+--+-+     +-----+-----+
          | SIP  |    | SIP  |     |   MSRP    |
          | MSRP |    | MSRP |     |   Relay   |
          |Client|    |Client|     +-----+-----+
          +---+--+    +------+           |
              |                          |
              +--------------------------+
                      MSRP Sessions
    Figure 1: Multi-party Chat Overview Shown with MSRP Relays
              and a Conference Focus UA
 The MSRP switch is similar to a conference mixer in that it both
 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: it doesn't
 actually mix the streams in any way.  The system is illustrated in
 Figure 2.

Niemi, et al. Standards Track [Page 8] RFC 7701 Multi-party Chat MSRP December 2015

                   +------+
                   | MSRP |
                   |Client|
 +------+          +--.---+          +------+
 | MSRP |             |              | MSRP |
 |Client|             |             _|Client|
 +------._            |           ,' +------+
          `._         |         ,'
             `.. +----------+ ,'
                `|          |'
                 |   MSRP   |
                 |  Switch  |
                ,|          |_
           _,-'' +----------+ ``-._
 +------.-'            |           `--+------+
 | MSRP |              |              | MSRP |
 |Client|              |              |Client|
 +------+              |              +------+
                   +---'--+
                   | MSRP |
                   |Client|
                   +------+
 Figure 2: Multi-party Chat in a Centralized Chat Room
 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.
 All messages in the chat room use the Message/CPIM wrapper content
 type [RFC3862], 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.
 A participant can also send a private IM 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

Niemi, et al. Standards Track [Page 9] RFC 7701 Multi-party Chat MSRP December 2015

 recipient is logged in from different endpoints, the MSRP switch will
 distribute the private message to each endpoint at which the
 recipient is logged in.
 We extend the current MSRP negotiation that takes place in SDP
 [RFC4566] to allow participants to learn whether the chat room
 supports and is willing to accept (e.g., due to local policy
 restrictions) certain MSRP functions defined in this memo, such as
 nicknames or private messaging.  This is achieved by a new 'chatroom'
 attribute in SDP (please refer to Section 8 for a detailed
 description).
 Naturally, when a participant wishes to leave a chat room, it sends a
 SIP BYE request to the Focus UA and terminates the SIP dialog with
 the focus and MSRP sessions with the MSRP switch.
 This document assumes that each chat room is allocated its own SIP
 URI.  A user joining a chat room sends an INVITE request to that SIP
 URI, and, as a result, a new MSRP session is established between the
 user and the MSRP switch.  It is assumed that an MSRP session is
 mapped to a chat room.  If a user wants to join a second chat room,
 he creates a different INVITE request, through a different SIP
 dialog, which leads to the creation of a second MSRP session between
 the user and the MSRP switch.  Notice that these two MSRP sessions
 can still be multiplexed over the same TCP connection as per regular
 MSRP procedures.  However, each chat room is associated with a unique
 MSRP session and a unique SIP dialog.

4.1. Policy Attributes of the Chat Room

 The Conference Framework with SIP [RFC4353] introduces the notion of
 a Conference Policy as "The complete set of rules governing a
 particular conference."  A chat room is a specialized type of
 conference, and the conference policy 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.
 Nicknames:  Whether the chat room accepts users to be recognized with
    a nickname.  See Sections 7, 7.1, and 8 for details.  Also, the
    scope of uniqueness of the nickname: the chat room (conference
    instance), a realm or domain, a server, etc.

Niemi, et al. Standards Track [Page 10] RFC 7701 Multi-party Chat MSRP December 2015

 Nickname quarantine:  The quarantine to be imposed on 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 Section 11 for details.
 Private messaging:  Whether the chat room allows users to send
    private messages to other users of the chat room through the MSRP
    switch.  See Sections 6.2 and 8 for details.
 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 Section 5.3 for details.
 Simultaneous access:  Whether a user can log in from different
    endpoints using the same identity.  See Sections 6.1 and 6.2 for
    details.
 Force TLS transport:  Whether the MSRP switch accepts only Transport
    Layer Security (TLS) as an MSRP transport, in an effort to
    guarantee confidentiality and privacy.  See Section 11 for
    details.
 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 Section 6.4 for details.
 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 Section 6.1 for details.
 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 to those explicitly listed, a "*" is added
    to the list.  A single "*" indicates that the chat room accepts
    any wrapped media type.

Niemi, et al. Standards Track [Page 11] RFC 7701 Multi-party Chat MSRP December 2015

5. Creating, Joining, and Deleting a Chat Room

5.1. Creating a Chat Room

 Since we consider a chat room a particular type of conference having
 MSRP media, the methods defined by the SIP Conference Framework
 [RFC4353] for creating conferences are directly applicable to a chat
 room.
 Once a chat room is created, it is identified by a SIP URI, like any
 other conference.

5.2. Joining a Chat Room

 Participants usually join the chat room by sending an INVITE request
 to the chat room URI.  The chat room then uses regular SIP mechanisms
 to authenticate the participant.  This may include, e.g., client
 certificates, SIP Digest authentication [RFC3261], asserted network
 identity [RFC3325], SIP Identity header field [RFC4474], 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.
 This specification requires all IMs to be wrapped in a Message/CPIM
 wrapper [RFC3862].  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' (notice that RFC 4975 [RFC4975]
 mandates this 'accept-types' attribute in SDP).  If the 'accept-
 types' attribute does not contain the value 'Message/CPIM', the
 conference focus will reject the request.  The actual instant message
 payload type is negotiated in the 'accept-wrapped-types' attribute in
 SDP (see RFC 4975 [RFC4975] 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 RFC 4975 procedures [RFC4975].
 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.
 Conference-aware participants will detect that the peer is a focus
 due to the presence of the "isfocus" feature tag [RFC3840] in the
 Contact header field of the 200-class response to the INVITE request.
 Conference-unaware participants will not notice it is a focus, and

Niemi, et al. Standards Track [Page 12] RFC 7701 Multi-party Chat MSRP December 2015

 cannot apply the additional mechanisms defined in this document.
 Participants are also aware that the mixer is an MSRP switch due to
 the presence of a 'message' media type and either TCP/MSRP or
 TCP/TLS/MSRP as the protocol field in the media line of SDP
 [RFC4566].
 The conference focus of a chat room MUST only use a Message/CPIM
 [RFC3862] top-level wrapper as a payload of MSRP messages, and the
 focus MUST declare it in the SDP offer or answer as per regular
 procedures in RFC 4975 [RFC4975].  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 reject
 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.).
 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 IMs 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
 IM payload type is negotiated in the 'accept-wrapped-types' attribute
 in SDP (see RFC 4975 [RFC4975] 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.
    Note that the Message/CPIM wrapper is used to carry the sender
    information that, otherwise, it will not be available to the
    recipient.  Additionally, the Message/CPIM wrapper carries the
    recipient information (e.g., To and Cc headers).
 If the UA supports anonymous participation and the user chooses to
 use it, the participant's UA SHOULD do at least one of these options:
 (a)  provide an anonymous URI in SIP headers that otherwise reveal
      identifiers.  Please refer to RFC 3323 [RFC3323] for a detailed
      description of which headers are subject to reveal identifiers
      and how to populate them; or
 (b)  trust the conference focus and request privacy of their URI,
      e.g., by means of the SIP Privacy header field [RFC3323],
      network asserted identity [RFC3325], or a similar privacy
      mechanism.

Niemi, et al. Standards Track [Page 13] RFC 7701 Multi-party Chat MSRP December 2015

 If the participant has requested privacy, the conference focus MUST
 expose a participant's anonymous URI through the conference event
 package [RFC4575].
 The conference focus of a chat room learns the supported chat room
 capabilities in the endpoint by means of the 'chatroom' attribute
 exchanged in the SDP offer/answer (please refer to Section 8 for a
 detailed description).  The conference focus MUST inform the MSRP
 switch of the chat room capabilities of each participant that joins
 the chat room (note that the interface defined between the conference
 focus and the MSRP switch is outside the scope of this
 specification).  This information allows the MSRP switch, e.g., to
 avoid the distribution of private messages to participants whose
 endpoints do not support private messaging.

5.3. Deleting a Chat Room

 As with creating a conference, the methods defined by the SIP
 Conference Framework [RFC4353] for deleting a conference are directly
 applicable to a chat room.  The MSRP switch will terminate the MSRP
 sessions with all the participants.
 Deleting a chat room is an action that heavily depends on the policy
 of the chat room.  For example, the policy can determine whether the
 chat room is deleted when the creator leaves the room or whether an
 out-of-band mechanism is responsible for the deletion.

6. Sending and Receiving Instant Messages

6.1. Regular Messages

 This section describes the conventions used to send and receive IMs
 that are addressed to all the participants in the chat room.  These
 are sent over a regular MSRP SEND request that contains a Message/
 CPIM wrapper [RFC3862] that, in turn, contains the desired payload
 (e.g., text, image, video clip, etc.).
 When a chat room participant wishes to send an instant message to all
 the other participants in the chat room, it constructs an MSRP SEND
 request according to the procedures specified in RFC 4975 [RFC4975].
 The sender MAY choose the desired MSRP report model (e.g., populate
 the Success-Report and Failure-Report MSRP header fields).
 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:

Niemi, et al. Standards Track [Page 14] RFC 7701 Multi-party Chat MSRP December 2015

 o  A SIP URI [RFC3261] representing the participant's address-of-
    record
 o  A tel URI [RFC3966] representing the participant's telephone
    number
 o  An IM URI [RFC3860] representing the participant's instant
    messaging address
 o  An anonymous URI representing the participant's anonymous address
 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.
 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.  Section 6.3 provides
 further information with the actions to be taken in case this
 validation fails.
 Then the MSRP switch should inspect the To header field of the
 Message/CPIM wrapper.  If the MSRP switch receives a message
 containing several To header fields in the Message/CPIM wrapper the
 MSRP switch MUST reject the MSRP SEND request with a 403 response, as
 per procedures in RFC 4975 [RFC4975].  Then, if the To header field
 of the Message/CPIM wrapper contains the chat room URI and there are
 no other To header fields, the MSRP switch can generate a copy of the
 SEND request to each of the participants in the 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.
 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

Niemi, et al. Standards Track [Page 15] RFC 7701 Multi-party Chat MSRP December 2015

 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.
 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 the
 MSRP switch SHOULD still implement some sanity checking.  Please
 refer to the security considerations in Section 11 for further
 details.
 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; it MUST also 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 had joined the chat
 room when the first chunk was distributed from receiving subsequent
 chunks that would otherwise need to be discarded.
 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
 discards the temporary storage of MSRP Message-ID and the associated
 list of recipients.
 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 RFC 4975 [RFC4975]
 Section 5.4).  The problem in the context of a chat room lies with
 the use 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.

Niemi, et al. Standards Track [Page 16] RFC 7701 Multi-party Chat MSRP December 2015

 This chunk reception timer can be reset every time a new chunk of the
 same message is received.  When this timer expires, the MSRP switch
 MUST consider that the sending of the message was aborted, and it MAY
 discard all the message state associated with it, including the
 Message-ID and the list of recipients.  Additionally, if this chunk
 reception timer expires, 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.
 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.
 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.
 It is possible that a participant, identified by a SIP AoR 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.

6.2. Private Messages

 This section describes the conventions used to send and receive
 private IMs, i.e., IMs that are addressed to one participant of the
 chat room rather than to all of them.  The chat room has a local
 policy that determines whether or not private messages are supported.
 A chat room can signal support for private messages using the
 'chatroom' attribute in SDP (please refer to Section 8 for a detailed
 description).
 When a chat room participant wishes to send a private IM to a
 participant in the chat room, it follows the same procedures to
 create a SEND request as for regular messages (Section 6.1).  The

Niemi, et al. Standards Track [Page 17] RFC 7701 Multi-party Chat MSRP December 2015

 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.
    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 delivered 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.
 As for regular messages, an MSRP switch that receives a SEND request
 from a participant SHOULD first verify that the From header field of
 the Message/CPIM wrapper is correctly populated with a valid URI
 (i.e., the URI is a participant of this chat room).  Section 6.3
 provides further information regarding the actions to be taken in
 case this validation fails.
 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 RFC 4975 [RFC4975].  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.
    Notice the importance of the From and To headers in the Message/
    CPIM wrapper.  If an intermediary modifies these values, the MSRP
    switch might not be able to identify the source or intended
    destination of the message, resulting in a rejection of the
    message.
 Finally, the MSRP switch 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
 428 response indicates that the recipient does not support private
 messages.  Any potential REPORT request that the MSRP switch sends to

Niemi, et al. Standards Track [Page 18] RFC 7701 Multi-party Chat MSRP December 2015

 the sender MUST include a Message/CPIM wrapper containing the
 original From header field included in the SEND request and the To
 header field of the original Message/CPIM wrapper.  The MSRP switch
 MUST NOT forward private messages to a recipient that does not
 support private messaging.
 If successful, the MSRP switch should search its mapping table to
 find the MSRP sessions established 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.
 An MSRP endpoint that receives a SEND request from the MSRP switch
 does the same validations as for regular messages (Section 6.1).  If
 the To header field is different from the chat room URI, the MSRP
 endpoints know 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
 the sender of the message, instead of using the sender's actual URI.
 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.

6.3. MSRP Reports and Responses

 This section discusses the common procedures for regular and private
 messages with respect to MSRP reports and responses.  Any particular
 procedure affecting only regular messages or only private messages is
 discussed in the previous sections (Sections 6.1 or 6.2,
 respectively).
 MSRP switches MUST follow the success report and failure report
 handling described in Section 7 of RFC 4975 [RFC4975], complemented
 with the procedures described in this section.  The MSRP switch MUST
 act as an MSRP endpoint receiver of the request, according to
 Section 5.3 of RFC 4975 [RFC4975].
 If the MSRP switch receives an MSRP SEND request that does not
 contain a Message/CPIM wrapper, the MSRP switch MUST reject the
 request with a 415 response (specified in RFC 4975 [RFC4975]).
 If the MSRP switch receives an MSRP SEND request where the URI
 included in the From header field of the Message/CPIM wrapper is not
 valid, (e.g., because it does not "belong" to the sender of the
 message or is not a valid participant of the chat room), the MSRP

Niemi, et al. Standards Track [Page 19] RFC 7701 Multi-party Chat MSRP December 2015

 switch MUST reject the request with a 403 response.  In cases without
 error, the MSRP switch MUST construct responses according to
 Section 7.2 of RFC 4975 [RFC4975].
 When the MSRP switch forwards a SEND request, it MAY use any report
 model in the copies intended for the recipients.  The receiver
 reports from the recipients MUST NOT be forwarded to the originator
 of the original SEND request.  This could lead to having the sender
 receiving multiple reports for a single MSRP request.

6.4. Congestion Avoidance

 Congestion can occur when multiple heterogeneous interfaces are used
 by a number 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 paths 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.  Therefore, it is
 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 up the pace.
 Additionally, since MSRP uses a connection-oriented transport
 protocol such as TCP, it is expected that TCP congestion control
 mechanisms be activated if congestion occurs.  Details on congestion
 control are specified in RFC 5681 [RFC5681].
 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.
 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:
 o  If the MSRP switch is writing data to a send buffer and detects
    that the send buffer associated with 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".
 o  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:

Niemi, et al. Standards Track [Page 20] RFC 7701 Multi-party Chat MSRP December 2015

  • The MSRP switch MAY discard regular MSRP messages sent to that

user while the congestion flag is raised for the user's TCP

       connection.  In order to inform the user of the congestion, the
       MSRP switch MAY send a regular MSRP message to the user whose
       congestion flag is raised.  This message indicates that some
       other messages are being discarded due to network congestion.
       However, it should be noted that this message can get stuck at
       MSRP switch, if the path is fully congested, i.e., it may not
       be delivered anyhow.
  • 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.
 o  If the MSRP switch determines that the congestion flag associated
    with a given TCP connection has been raised for quite some time
    (on the order of a few minutes), or if the interface is down, this
    may be considered an indication that the TCP connection has not
    been able to recover from a congestion state.  The MSRP switch MAY
    close this congested TCP connection as well as the MSRP session
    and SIP session.

7. Nicknames

 A common characteristic of existing chat room services is that
 participants have the ability to present themselves with a nickname
 to the rest of the participants of the 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.
 A nickname is a useful construct in many use cases, of which MSRP
 chat is but one example.  A nickname is associated with a URI; the
 focus knows the participant by its association to this URI.
 Therefore, if a user joins the chat room under the same URI from
 multiple devices, he or she may request the same nickname across all
 these devices.
 A nickname is a user-selectable moniker by 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 they may be temporary.  Users also need to reserve
 a nickname prior to its utilization.

Niemi, et al. Standards Track [Page 21] RFC 7701 Multi-party Chat MSRP December 2015

 This memo specifies the nickname as a string.  The nickname string
 MUST unambiguously be associated with 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 "Extensible
 Messaging and Presence Protocol (XMPP): Core" [RFC6120].  The chat
 room may have policies associated with nicknames.  It may not accept
 nickname strings at all, or it may provide a wider unambiguous scope
 like a domain or server, similar to IRC [RFC2810].

7.1. Using Nicknames within a Chat Room

 This memo provides a mechanism to reserve a nickname for a
 participant for as long as the participant is logged into the chat
 room.  The mechanism is based on a NICKNAME MSRP method (see below)
 and a new "Use-Nickname" header.  Note that other mechanisms may
 exist (for example, a web page reservation system), although they are
 outside the scope of this document.
 A 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-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.  Finally, MSRP NICKNAME
 requests MUST NOT include Success-Report or Failure-Report header
 fields.
    Bear in mind that nickname strings, like the rest of the MSRP
    message, use the UTF-8 transformation format [RFC3629].
    Therefore, a character may be encoded in more than one octet.
 An MSRP switch that receives a NICKNAME request containing a
 Use-Nickname header field SHOULD first verify whether the policy of
 the chat room allows the nickname functionality.  If not allowed, the
 MSRP switch MUST reject the request with a 403 response, as per RFC
 4975 [RFC4975].
 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
 "Preparation, Enforcement, and Comparison of Internationalized
 Strings Representing Nicknames" [RFC7700].
 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"

Niemi, et al. Standards Track [Page 22] RFC 7701 Multi-party Chat MSRP December 2015

 and "B0Y" are different nicknames that 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 perceive as different characters.
 Chat rooms MAY provide a mechanism to mitigate confusable nicknames.
 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 the participant's URI to use the same
 nickname when the participant has joined the chat room from different
 devices under the same URI.  The participant's authenticated
 identifier can be derived after a successful SIP Digest
 Authentication [RFC3261], included in a trusted SIP P-Asserted-
 Identity header field [RFC3325], included in a valid SIP Identity
 header field [RFC4474], 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 requested nickname,
 the MSRP switch verifies if the suggested nickname can be accepted
 (see below).
 The reservation of a nickname can fail in several cases.  If the
 NICKNAME request contains a malformed value in the Use-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-Nickname header field does not conform to the syntax.
 The reservation of a nickname can also fail if the value of the
 Use-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 these cases, the MSRP switch
 MUST answer the NICKNAME request with a 425 response code.
 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.
 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.

Niemi, et al. Standards Track [Page 23] RFC 7701 Multi-party Chat MSRP December 2015

 As indicated earlier, this specification defines a new MSRP header
 field: Use-Nickname.  The Use-Nickname header field carries a
 nickname string.  This specification defines the usage of the
 Use-Nickname header field in NICKNAME requests.  If need arises,
 usages of the Use-Nickname header field in other MSRP methods should
 be specified separately.
 According to RFC 4975 [RFC4975], MSRP uses the UTF-8 transformation
 format [RFC3629].  The syntax of the MSRP NICKNAME method and the
 Use-Nickname header field is built upon the MSRP formal syntax
 [RFC4975] using the Augmented Backus-Naur Form (ABNF) [RFC5234].
          other-method =/ NICKNAMEm
                   ; other-method defined in RFC 4975
          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
 Note that, according to RFC 4975 [RFC4975], "quoted-string" admits a
 subset of UTF-8 characters [RFC3629].  Please refer to Section 9 of
 RFC 4975 [RFC4975] for more details.
 Once the MSRP switch has reserved a nickname and has bound it to a
 URI (e.g., a SIP AoR), 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 UA.  In this case,
 the user MAY request a nickname that is the same or different than
 that used in conjunction with the first MSRP session; the MSRP server
 MAY accept the usage of the same nickname by the same user.  The MSRP
 switch MUST NOT automatically assign the same nickname to more than
 one MSRP session established from the same URI, because this can
 create confusion to the user as whether the same nickname is bound to
 the second MSRP session.

7.2. Modifying a Nickname

 Typically, a participant will reserve a nickname as soon as the
 participant joins the chat room.  But it is also possible for a
 participant to modify his/her own nickname and replace it with a new
 one at any time during the duration of the MSRP session.
 Modification of the nickname is not different from the initial
 reservation and usage of a nickname; thus, the NICKNAME method is
 used as described in Section 7.1.

Niemi, et al. Standards Track [Page 24] RFC 7701 Multi-party Chat MSRP December 2015

 If a NICKNAME request that attempts to modify the current nickname of
 the user fails for some reason, the current nickname stays in effect.
 A new nickname comes into effect and the old one is released only
 after a NICKNAME request is accepted with a 200 response.

7.3. Removing a Nickname

 If the participant no longer wants to be known by a nickname in the
 chat room, the participant can follow the method described in
 Section 7.2.  The nickname element of the Use-Nickname header MUST be
 set to an empty quoted string.

7.4. Nicknames in Conference Event Packages

 Typically the conference focus acts as a notifier of the conference
 event package, RFC 4575 [RFC4575].  It is RECOMMENDED that conference
 foci and endpoints support RFC 6502 [RFC6502] for providing
 information regarding the conference and, in particular, supplying
 information of the roster of the conference.  It is also RECOMMENDED
 that conference foci and endpoints support RFC 6501 [RFC6501], which
 extends the <user> element originally specified in RFC 4575 [RFC4575]
 with a new 'nickname' attribute.  This allows endpoints to learn the
 nicknames of participants of the chat room.

8. The SDP 'chatroom' Attribute

 There are a handful of use cases where a participant would like to
 learn the chat room capabilities supported by the 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 IM addressed
 to a participant, but since the MSRP switch does not support the
 functions specified in this memo, the message would eventually be
 distributed to all the participants of the chat room.
 The reverse case also exists.  A participant, say Alice, whose UA
 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.

Niemi, et al. Standards Track [Page 25] RFC 7701 Multi-party Chat MSRP December 2015

 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 forbidden.
 In order to provide the user with a good chat room experience, we
 define a new 'chatroom' SDP attribute.  The 'chatroom' attribute is a
 media-level value attribute [RFC4566] that MAY be included in
 conjunction with an MSRP media stream (i.e., when an "m=" line in SDP
 indicates "TCP/MSRP" or "TCP/TLS/MSRP").  The 'chatroom' attribute
 without further modifiers (e.g., chat-tokens) indicates that the
 endpoint supports the procedures described in this document for
 transferring MSRP messages to/from a 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 to indicate support for the use of nicknames and
 private messaging.
 The 'chatroom' attribute merely indicates the capabilities supported
 and allowed by the local policy.  This attribute is not a negotiation
 subject to the SDP offer/answer model [RFC3264], 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.
 In subsequent SDP offer/answer [RFC3264] exchanges pertaining to the
 same session, the 'chatroom' attribute MAY be modified with respect
 to an earlier SDP offer/answer exchange.  The new value of this
 attribute indicates 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 a corresponding MSRP stream is still in place, it
 indicates that support for the procedures indicated in this document
 are disabled.

Niemi, et al. Standards Track [Page 26] RFC 7701 Multi-party Chat MSRP December 2015

 The 'chatroom' SDP attribute has the following ABNF [RFC5234] syntax:
        attribute         =/ chatroom-attr
                                  ; attribute defined in RFC 4566
        chatroom-attr     = chatroom-label [":" chat-token
                            *(SP chat-token)]
        chatroom-label    = "chatroom"
        chat-token        = (nicknames-token / private-msg-token /
                             ext-token)
        nicknames-token   = "nickname"
        private-msg-token = "private-messages"
        ext-token         = private-token / standard-token
        private-token     = toplabel "." *(domainlabel ".") token
                                  ; toplabel defined in RFC 3261
                                  ; domainlabel defined in RFC 3261
                                  ; token defined in RFC 3261
        standard-token    = token
 A given 'chat-token' value MUST NOT appear more than once in a
 'chatroom' attribute.
 A conference focus that includes the 'nicknames' token in the session
 description is signaling that the MSRP switch supports and the chat
 room allows the use of the procedures specified in Section 7.  A
 conference focus that includes the 'private-messages' in the SDP
 description is signaling that the MSRP switch supports and the chat
 room allows the use of the procedures specified in Section 6.2.
 An example of the 'chatroom' attribute for an MSRP media stream that
 indicates the acceptance of nicknames and private messages:
           a=chatroom:nickname private-messages
 An example of a 'chatroom' attribute for an MSRP media stream where
 the endpoint, e.g., an MSRP switch, does not allow nicknames or
 private messages.
           a=chatroom
 The 'chatroom' attribute allows extensibility with the addition of
 new tokens.  No IANA registry is provided at this time, since no
 extensions are expected at the time of this writing.  Extensions to
 the 'chatroom' attribute can be defined in IETF documents or as
 private-vendor extensions.

Niemi, et al. Standards Track [Page 27] RFC 7701 Multi-party Chat MSRP December 2015

 Extensions defined in an IETF document MUST follow the 'standard-
 token' ABNF previously defined.  In this type of extension, care must
 be taken in the selection of the token to avoid a clash with any of
 the tokens previously defined.
 Private extensions MUST follow the 'private-token' ABNF previously
 defined.  The 'private-token' MUST be included in the DNS name of the
 vendor.  Then, the token is reversed in order to avoid clashes of
 tokens.  The following is an example of an extension named "foo.chat"
 by a vendor "example.com"
         a=chatroom:nickname private-messages com.example.chat.foo
 Note that feature names created by different organizations are not
 intended to have the same semantics or even interoperate.

9. Examples

9.1. Joining a Chat Room

 Figure 3 presents a flow diagram where Alice joins a chat room by
 sending an INVITE request.  This INVITE request contains a session
 description that includes the chat room extensions defined in this
 document.
 Alice               Conference Focus
   |                        |
   |F1: (SIP) INVITE        |
   |----------------------->|
   |F2: (SIP) 200 OK        |
   |<-----------------------|
   |F3: (SIP) ACK           |
   |----------------------->|
   |                        |
 Figure 3: Flow Diagram of a User Joining a Chat Room

Niemi, et al. Standards Track [Page 28] RFC 7701 Multi-party Chat MSRP December 2015

 F1: Alice constructs an SDP description that includes an MSRP media
 stream.  She also indicates her support for the chat room extensions
 defined in this document.  She sends the INVITE request to the chat
 room server.
 INVITE sip:chatroom22@chat.example.com SIP/2.0
 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 Max-Forwards: 70
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Chatroom 22 <sip:chatroom22@chat.example.com>
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
 Content-Type: application/sdp
 Content-Length: 290
 v=0
 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
 s=-
 c=IN IP4 client.atlanta.example.com
 m=message 7654 TCP/MSRP *
 a=accept-types:message/cpim text/plain text/html
 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
 a=chatroom:nickname private-messages
 F2: The chat room server accepts the session establishment.  It
 includes the 'isfocus' and other relevant feature tags in the Contact
 header field of the response.  The chat room server also builds an
 SDP answer that forces the reception of messages wrapped in Message/
 CPIM wrappers.  It also includes the 'chatroom' attribute with the
 allowed extensions.
 SIP/2.0 200 OK
 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
  ;received=192.0.2.101
 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
 To: Chatroom 22 <sip:chatroom22@chat.example.com>;tag=8321234356
 Call-ID: 3848276298220188511@atlanta.example.com
 CSeq: 1 INVITE
 Contact: <sip:chatroom22@chat.example.com;transport=tcp> \
           ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
           ;automata;isfocus;message;event="conference"
 Content-Type: application/sdp
 Content-Length: 290

Niemi, et al. Standards Track [Page 29] RFC 7701 Multi-party Chat MSRP December 2015

 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
 F3: The session established is acknowledged (details not shown).

9.2. Setting Up a Nickname

 Figure 4 shows an example of Alice setting up a nickname using the
 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.
 Alice                  MSRP Switch
   |                        |
   |F1: (MSRP) NICKNAME     |
   |----------------------->|
   |F2: (MSRP) 425          |
   |<-----------------------|
   |F3: (MSRP) NICKNAME     |
   |----------------------->|
   |F4: (MSRP) 200          |
   |<-----------------------|
   |                        |
       Figure 4: Flow Diagram of a User Setting up Her Nickname
 F1: Alice sends an MSRP NICKNAME request that contains her proposed
 nicknames in the Use-Nickname header field.
 MSRP d93kswow NICKNAME
 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
 Use-Nickname: "Alice the great"
 -------d93kswow$
 F2: The MSRP switch analyzes the existing allocation of nicknames and
 detects that the nickname "Alice the great" is already provided to
 another participant in the chat room.  The MSRP switch answers with a
 425 response.

Niemi, et al. Standards Track [Page 30] RFC 7701 Multi-party Chat MSRP December 2015

 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$
 F3: Alice receives the response.  She proposes a new nickname in a
 second NICKNAME request.
 MSRP 09swk2d NICKNAME
 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
 Use-Nickname: "Alice in Wonderland"
 -------09swk2d$
 F4: The MSRP switch accepts the nickname proposal and answers with a
 200 response.
 MSRP 09swk2d 200 OK
 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
 -------09swk2d$

9.3. Sending a Regular Message to the Chat Room

 Figure 5 is a flow diagram where Alice is sending a regular message
 addressed to the chat room.  The MSRP switch distributes the message
 to the rest of the participants.
 Alice               MSRP Switch                   Bob   Charlie
   |                      |                        |       |
   | F1: (MSRP) SEND      |                        |       |
   |--------------------->|  F3: (MSRP) SEND       |       |
   | F2: (MSRP) 200       |----------------------->|       |
   |<---------------------|  F4: (MSRP) SEND       |       |
   |                      |------------------------------->|
   |                      |  F5: (MSRP) 200 OK     |       |
   |                      |<-----------------------|       |
   |                      |  F6: (MSRP) 200 OK     |       |
   |                      |<------------------------------ |
   |                      |                        |       |
   |                      |                        |       |
         Figure 5: Sending a Regular Message to the Chat Room

Niemi, et al. Standards Track [Page 31] RFC 7701 Multi-party Chat MSRP December 2015

 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.
 MSRP 3490visdm SEND
 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
 Message-ID: 99s9s2
 Byte-Range: 1-*/*
 Content-Type: message/cpim
 To: <sip:chatroom22@chat.example.com;transport=tcp>
 From: <sip:alice@atlanta.example.com>
 DateTime: 2009-03-02T15:02:31-03:00
 Content-Type: text/plain
 Hello guys, how are you today?
 -------3490visdm$
 F2: The MSRP switch acknowledges the reception of the SEND request
 with a 200 (OK) response.
 MSRP 3490visdm 200 OK
 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
 Message-ID: 99s9s2
 -------3490visdm$
 F3: The MSRP switch creates a new MSRP SEND request that contains the
 received Message/CPIM wrapper and sends it to Bob.
 MSRP 490ej23 SEND
 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
 From-Path: msrp://chat.example.com:5678/jofofo3;tcp
 Message-ID: 304sse2
 Byte-Range: 1-*/*
 Content-Type: message/cpim
 To: <sip:chatroom22@chat.example.com;transport=tcp>
 From: <sip:alice@atlanta.example.com>
 DateTime: 2009-03-02T15:02:31-03:00
 Content-Type: text/plain
 Hello guys, how are you today?
 -------490ej23$

Niemi, et al. Standards Track [Page 32] RFC 7701 Multi-party Chat MSRP December 2015

 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 to all participants in the chat room
 rather than a private message addressed to him.
 The rest of the message flows are analogous to the previous.  They
 are not shown here.

9.4. Sending a Private Message to a Participant

 Figure 6 is a flow diagram where Alice is sending a private message
 addressed to Bob's SIP AOR.  The MSRP switch distributes the message
 only to Bob.
 Alice               MSRP Switch                   Bob
   |                      |                        |
   | F1: (MSRP) SEND      |                        |
   |--------------------->|  F3: (MSRP) SEND       |
   | F2: (MSRP) 200       |----------------------->|
   |<---------------------|  F4: (MSRP) 200        |
   |                      |<-----------------------|
   |                      |                        |
              Figure 6: Sending a Private Message to Bob
 F1: Alice builds a text message and wraps it in a Message/CPIM
 wrapper.  She addresses the message to Bob's URI, which she learned
 from a notification in the conference event package.  She encloses
 the resulting Message/CPIM wrapper in an MSRP SEND request and sends
 it to the MSRP switch via the existing TCP connection.
 MSRP 6959ssdf SEND
 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
 Message-ID: okj3kw
 Byte-Range: 1-*/*
 Content-Type: message/cpim
 To: <sip:bob@example.com>
 From: <sip:alice@example.com>
 DateTime: 2009-03-02T15:02:31-03:00
 Content-Type: text/plain
 Hello Bob.
 -------6959ssdf$
 F2: The MSRP switch acknowledges the reception of the SEND request
 with a 200 (OK) response.

Niemi, et al. Standards Track [Page 33] RFC 7701 Multi-party Chat MSRP December 2015

 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$
 F3: The MSRP switch creates a new MSRP SEND request that contains the
 received Message/CPIM wrapper and sends it only to Bob. Bob can
 distinguish the sender in the From header of the Message/CPIM
 wrapper.  He also identifies this as a private message due to the
 presence of his own SIP AOR in the To header field of the Message/
 CPIM wrapper.
 MSRP 9v9s2 SEND
 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
 From-Path: msrp://chat.example.com:5678/jofofo3;tcp
 Message-ID: d9fghe982
 Byte-Range: 1-*/*
 Content-Type: message/cpim
 To: <sip:bob@example.com>
 From: <sip:alice@atlanta.example.com>
 DateTime: 2009-03-02T15:02:31-03:00
 Content-Type: text/plain
 Hello Bob.
 -------9v9s2$
 F4: Bob acknowledges the reception of the SEND request with a 200
 (OK) response.
 MSRP 9v9s2 200 OK
 To-Path: msrp://chat.example.com:5678/jofofo3;tcp
 From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
 Message-ID: d9fghe982
 -------9v9s2$

Niemi, et al. Standards Track [Page 34] RFC 7701 Multi-party Chat MSRP December 2015

9.5. Chunked Private Message

 The MSRP message below is a depiction of the same private message
 described in Section 9.4, but now the message is split in two chunks.
 The MSRP switch must wait for the complete set of Message/CPIM
 headers before distributing the messages.
 MSRP 7443ruls SEND
 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
 Message-ID: aft4to
 Byte-Range: 1-*/174
 Content-Type: message/cpim
 To: <sip:bob@example.com>
 From: <sip:alice@example.com>
 -------7443ruls$
 MSRP 7443ruls SEND
 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
 Message-ID: aft4to
 Byte-Range: 68-174/174
 Content-Type: message/cpim
 DateTime: 2009-03-02T15:02:31-03:00
 Content-Type: text/plain
 Hello Bob
 -------7443ruls$

9.6. Nickname in a Conference Information Document

 Figure 7 is a depiction of an XML conference information document
 received in a SIP NOTIFY request as a notification to the XCON
 Conference Event Package, RFC 6502 [RFC6502].  The conference
 information document follows the XCON Data Model specified in RFC
 6501 [RFC6501].
 The conference information document of Figure 7 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.

Niemi, et al. Standards Track [Page 35] RFC 7701 Multi-party Chat MSRP December 2015

    NOTE: The purpose of Figure 7 is to show the user-to-nickname
    relationship.  It is believed that the example is correct,
    according to RFC 6501 [RFC6501].  In case of contradictions
    between this specification and RFC 6501 [RFC6501], the latter has
    precedence.
  <?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>
 Figure 7: Nickname in a Conference Information Document

Niemi, et al. Standards Track [Page 36] RFC 7701 Multi-party Chat MSRP December 2015

10. IANA Considerations

10.1. New MSRP Method

 This specification defines a new MSRP method that has been added to
 the "Methods" subregistry of the "Message Session Relay Protocol
 (MSRP) Parameters" registry:
    NICKNAME
 See Section 7 for details.

10.2. New MSRP Header

 This specification defines a new MSRP header that has been added to
 the "Header Fields" subregistry of the "Message Session Relay
 Protocol (MSRP) Parameters" registry:
    Use-Nickname
 See Section 7 for details.

10.3. New MSRP Status Codes

 This specification defines four new MSRP status codes that have been
 added to the "Status Codes" subregistry of the "Message Session Relay
 Protocol (MSRP) parameters" registry.
 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 Section 6.2 for
 details.
 The 424 status code indicates a failure in allocating the requested
 nickname due to a malformed syntax in the Use-Nickname header field.
 See Section 7 for details.
 The 425 status code indicates a failure in allocating the requested
 nickname because the requested nickname in the Use-Nickname header
 field is reserved or is already in use by another user.  See
 Section 7 for details.
 The 428 status code indicates that the recipient of a SEND request
 does not support private messages.  See Section 6.2 for details.
 Table 1 summarizes the IANA registration data with respect to new
 MSRP status codes:

Niemi, et al. Standards Track [Page 37] RFC 7701 Multi-party Chat MSRP December 2015

      +-------+-------------------------------------+-----------+
      | Value | Description                         | Reference |
      +-------+-------------------------------------+-----------+
      |  404  | Failure to resolve recipient's URI  |  RFC 7701 |
      |  424  | Malformed nickname                  |  RFC 7701 |
      |  425  | Nickname reserved or already in use |  RFC 7701 |
      |  428  | Private messages not supported      |  RFC 7701 |
      +-------+-------------------------------------+-----------+
                       Table 1: New Status Codes

10.4. New SDP Attribute

 This specification defines a new media-level attribute in the
 "Session Description Protocol (SDP) Parameters" registry.  The
 registration data is as follows:
    Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
    Phone: +34 91 339 1000
    Attribute name: chatroom
    Long-form attribute name: Chat Room
    Type of attribute: media level only
    This attribute is not subject to the charset attribute
    Description: This attribute identifies support and local policy
    allowance for a number of chat room related functions
    Specification: RFC 7701 (this document)
 See Section 8 for details.

11. Security Considerations

 This document proposes extensions to the Message Session Relay
 Protocol [RFC4975].  Therefore, the security considerations of that
 document apply to this document as well.
 A chat room is, by its nature, a potential Denial-of-Service (DoS)
 accelerator as it takes a message from one entity and sends it to
 many.  Implementers of both UAs and switches need to carefully
 consider the set of anti-DoS measures that are appropriate for this
 application, and switch implementations, in particular, ought to

Niemi, et al. Standards Track [Page 38] RFC 7701 Multi-party Chat MSRP December 2015

 include appropriate anti-DoS features.  The details of what is
 appropriate will vary over time and will also depend on the specific
 needs of the implementation; thus, they cannot be specified here.
 If the participant's SIP UA does not understand the "isfocus" feature
 tag [RFC3840], it will not know that it is connected to a conference
 instance.  The participant might not be notified that its MSRP client
 will try to send messages having potential multiple recipients to the
 MSRP switch.  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 the Message/CPIM wrapper content type [RFC3862],
 and the MSRP switch will reject the request with a 415 response
 [RFC4975].  Still, if a participant's MSRP client does create a
 message with a valid Message/CPIM wrapper content type [RFC3862]
 having the To header set to the URI of the chat room and the From
 header set to the URI of which the participant that 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.
 To mitigate these problems, when the chat room detects that a UA does
 not support the procedures of this document (i.e., when the SIP UA is
 not chat room aware), the MSRP switch SHOULD send a regular MSRP
 message indicating that the SIP UA is actually part of a chat room
 and that all the messages that the user sends correctly formatted
 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.
 If a participant wants to avoid security concerns on the path between
 himself and the MSRP switch (e.g., eavesdropping, faked packet
 injection, or packet corruption), the participant's UA can force the
 usage of MSRP over a TLS [RFC5246] transport connection.  This is
 negotiated in the SDP offer/answer exchange as per the regular
 procedures of RFC 4975 [RFC4975].  This negotiation will result in
 both endpoints establishing a TLS [RFC5246] transport connection that
 is used to exchange MSRP messages.  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 the regular
 procedures of RFC 4975 [RFC4975].
 Nicknames are used to show the appearance of the participants of the
 chat room.  A successful takeover of a nickname from a participant
 might lead to private messages being sent to the wrong destination.
 The recipient's URI will be different from the URI associated with
 the original owner of the nickname, but the sender might not notice

Niemi, et al. Standards Track [Page 39] RFC 7701 Multi-party Chat MSRP December 2015

 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 for its holder, once it is no longer being used.  This
 allows, e.g., a user that accidentally loses its connectivity, to
 reconnect to the chat room and keep on using the same nickname.  It
 depends on the policy of the chat room if a nickname that has been
 previously used by another participant of the chat room can be
 reserved or not.
 Section 7.1 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.
 Recipients of IMs should be cautious with the rendering of content,
 which can be malicious in nature.  This includes, but is not limited
 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.
 It must be noted that endpoints using a TLS client side certificate
 with real names in the certificates will not be anonymous to the MSRP
 switch to which they connect.  While the name in the certificate
 might not be used by MSRP, the server will have a certificate with
 the actual name in it.

12. References

12.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            DOI 10.17487/RFC3261, June 2002,
            <http://www.rfc-editor.org/info/rfc3261>.
 [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
            with Session Description Protocol (SDP)", RFC 3264,
            DOI 10.17487/RFC3264, June 2002,
            <http://www.rfc-editor.org/info/rfc3264>.

Niemi, et al. Standards Track [Page 40] RFC 7701 Multi-party Chat MSRP December 2015

 [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
            Initiation Protocol (SIP)", RFC 3323,
            DOI 10.17487/RFC3323, November 2002,
            <http://www.rfc-editor.org/info/rfc3323>.
 [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
            10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
            2003, <http://www.rfc-editor.org/info/rfc3629>.
 [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
            "Indicating User Agent Capabilities in the Session
            Initiation Protocol (SIP)", RFC 3840,
            DOI 10.17487/RFC3840, August 2004,
            <http://www.rfc-editor.org/info/rfc3840>.
 [RFC3860]  Peterson, J., "Common Profile for Instant Messaging
            (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004,
            <http://www.rfc-editor.org/info/rfc3860>.
 [RFC3862]  Klyne, G. and D. Atkins, "Common Presence and Instant
            Messaging (CPIM): Message Format", RFC 3862,
            DOI 10.17487/RFC3862, August 2004,
            <http://www.rfc-editor.org/info/rfc3862>.
 [RFC4353]  Rosenberg, J., "A Framework for Conferencing with the
            Session Initiation Protocol (SIP)", RFC 4353,
            DOI 10.17487/RFC4353, February 2006,
            <http://www.rfc-editor.org/info/rfc4353>.
 [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
            Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
            July 2006, <http://www.rfc-editor.org/info/rfc4566>.
 [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
            Session Initiation Protocol (SIP) Event Package for
            Conference State", RFC 4575, DOI 10.17487/RFC4575, August
            2006, <http://www.rfc-editor.org/info/rfc4575>.
 [RFC4975]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
            "The Message Session Relay Protocol (MSRP)", RFC 4975,
            DOI 10.17487/RFC4975, September 2007,
            <http://www.rfc-editor.org/info/rfc4975>.
 [RFC4976]  Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
            for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
            DOI 10.17487/RFC4976, September 2007,
            <http://www.rfc-editor.org/info/rfc4976>.

Niemi, et al. Standards Track [Page 41] RFC 7701 Multi-party Chat MSRP December 2015

 [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", STD 68, RFC 5234,
            DOI 10.17487/RFC5234, January 2008,
            <http://www.rfc-editor.org/info/rfc5234>.
 [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
            Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239,
            June 2008, <http://www.rfc-editor.org/info/rfc5239>.
 [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.2", RFC 5246,
            DOI 10.17487/RFC5246, August 2008,
            <http://www.rfc-editor.org/info/rfc5246>.
 [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
            Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
            <http://www.rfc-editor.org/info/rfc5681>.
 [RFC6501]  Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
            "Conference Information Data Model for Centralized
            Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501,
            March 2012, <http://www.rfc-editor.org/info/rfc6501>.
 [RFC6502]  Camarillo, G., Srinivasan, S., Even, R., and J.
            Urpalainen, "Conference Event Package Data Format
            Extension for Centralized Conferencing (XCON)", RFC 6502,
            DOI 10.17487/RFC6502, March 2012,
            <http://www.rfc-editor.org/info/rfc6502>.
 [RFC7700]  Saint-Andre, P., "Preparation, Enforcement, and Comparison
            of Internationalized Strings Representing Nicknames",
            RFC 7700, DOI 10.17487/RFC7700, December 2015,
            <http://www.rfc-editor.org/info/rfc7700>.

Niemi, et al. Standards Track [Page 42] RFC 7701 Multi-party Chat MSRP December 2015

12.2. Informative References

 [RFC2810]  Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
            DOI 10.17487/RFC2810, April 2000,
            <http://www.rfc-editor.org/info/rfc2810>.
 [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
            Extensions to the Session Initiation Protocol (SIP) for
            Asserted Identity within Trusted Networks", RFC 3325,
            DOI 10.17487/RFC3325, November 2002,
            <http://www.rfc-editor.org/info/rfc3325>.
 [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
            RFC 3966, DOI 10.17487/RFC3966, December 2004,
            <http://www.rfc-editor.org/info/rfc3966>.
 [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
            Authenticated Identity Management in the Session
            Initiation Protocol (SIP)", RFC 4474,
            DOI 10.17487/RFC4474, August 2006,
            <http://www.rfc-editor.org/info/rfc4474>.
 [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
            Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
            March 2011, <http://www.rfc-editor.org/info/rfc6120>.

Acknowledgments

 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, Peter Saint-Andre, Stephen Farrell, and Martin Stiemerling
 for providing comments.

Contributors

 This work would have never been possible without the fruitful
 discussions on the SIMPLE WG mailing list, especially with Brian
 Rosen (Neustar) and Paul Kyzivat (Huawei), who provided extensive
 review and improvements throughout the document.

Niemi, et al. Standards Track [Page 43] RFC 7701 Multi-party Chat MSRP December 2015

Authors' Addresses

 Aki Niemi
 Email: aki.niemi@iki.fi
 Miguel A. Garcia-Martin
 Ericsson
 Calle Via de los Poblados 13
 Madrid, ES  28033
 Spain
 Email: miguel.a.garcia@ericsson.com
 Geir A. Sandbakken
 Cisco Systems
 Philip Pedersensvei 1
 1366 Lysaker
 Norway
 Email: geirsand@cisco.com

Niemi, et al. Standards Track [Page 44]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7701.txt · Last modified: 2015/12/15 04:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki