RFC 7701
Multi-party Chat Using the Message Session Relay Protocol (MSRP)
Pages: 42
Proposed Standard
Proposed Standard
Part 2 of 2 – Pages 21 to 42
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.
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"
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.
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.
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.
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.
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.
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
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
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.
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
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$
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.
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$
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.
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
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:
+-------+-------------------------------------+-----------+ | 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 Codes10.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
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
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>.
[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>.
[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>.
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.
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