tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7701

 
 
 

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

Part 2 of 2, p. 21 to 42
Prev RFC Part

 


prevText      Top      ToC       Page 21 
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.

Top      Up      ToC       Page 22 
   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"

Top      Up      ToC       Page 23 
   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.

Top      Up      ToC       Page 24 
   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.

Top      Up      ToC       Page 25 
   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.

Top      Up      ToC       Page 26 
   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.

Top      Up      ToC       Page 27 
   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.

Top      Up      ToC       Page 28 
   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

Top      Up      ToC       Page 29 
   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

Top      Up      ToC       Page 30 
   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.

Top      Up      ToC       Page 31 
   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

Top      Up      ToC       Page 32 
   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$

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
   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$

Top      Up      ToC       Page 35 
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.

Top      Up      ToC       Page 36 
      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

Top      Up      ToC       Page 37 
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:

Top      Up      ToC       Page 38 
        +-------+-------------------------------------+-----------+
        | 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

Top      Up      ToC       Page 39 
   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

Top      Up      ToC       Page 40 
   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>.

Top      Up      ToC       Page 41 
   [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>.

Top      Up      ToC       Page 42 
   [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>.

Top      Up      ToC       Page 43 
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.

Top      Up      ToC       Page 44 
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