Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7701

Multi-party Chat Using the Message Session Relay Protocol (MSRP)

Pages: 42
Proposed Standard
Part 1 of 2 – Pages 1 to 21
None   None   Next

Top   ToC   RFC7701 - Page 1
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.
Top   ToC   RFC7701 - Page 2
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.
Top   ToC   RFC7701 - Page 3

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
Top   ToC   RFC7701 - Page 4

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.
Top   ToC   RFC7701 - Page 5

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
Top   ToC   RFC7701 - Page 6
      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.
Top   ToC   RFC7701 - Page 7
   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.
Top   ToC   RFC7701 - Page 8
                        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.
Top   ToC   RFC7701 - Page 9
                     +------+
                     | 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
Top   ToC   RFC7701 - Page 10
   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.
Top   ToC   RFC7701 - Page 11
   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.
Top   ToC   RFC7701 - Page 12

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
Top   ToC   RFC7701 - Page 13
   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.
Top   ToC   RFC7701 - Page 14
   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:
Top   ToC   RFC7701 - Page 15
   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
Top   ToC   RFC7701 - Page 16
   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.
Top   ToC   RFC7701 - Page 17
   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
Top   ToC   RFC7701 - Page 18
   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
Top   ToC   RFC7701 - Page 19
   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
Top   ToC   RFC7701 - Page 20
   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:
Top   ToC   RFC7701 - Page 21
      *  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.



(page 21 continued on part 2)

Next Section