idnits 2.17.1 draft-ietf-simple-chat-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 11, 2013) is 4094 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4353 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-19) exists of draft-ietf-precis-nickname-05 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft 4 Intended status: Standards Track M. Garcia-Martin 5 Expires: July 15, 2013 Ericsson 6 G. Sandbakken 7 Cisco Systems 8 January 11, 2013 10 Multi-party Chat Using the Message Session Relay Protocol (MSRP) 11 draft-ietf-simple-chat-18 13 Abstract 15 The Message Session Relay Protocol (MSRP) defines a mechanism for 16 sending instant messages within a peer-to-peer session, negotiated 17 using the Session Initiation Protocol (SIP) and the Session 18 Description Protocol (SDP). This document defines the necessary 19 tools for establishing multi-party chat sessions, or chat rooms, 20 using MSRP. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 15, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Motivations and Requirements . . . . . . . . . . . . . . . . . 6 71 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Policy Attributes of the Chat Room . . . . . . . . . . . . 10 73 5. Creating, Joining, and Deleting a Chat Room . . . . . . . . . 11 74 5.1. Creating a Chat Room . . . . . . . . . . . . . . . . . . . 11 75 5.2. Joining a Chat Room . . . . . . . . . . . . . . . . . . . 12 76 5.3. Deleting a Chat Room . . . . . . . . . . . . . . . . . . . 14 77 6. Sending and Receiving Instant Messages . . . . . . . . . . . . 14 78 6.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 14 79 6.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 17 80 6.3. MSRP reports and responses . . . . . . . . . . . . . . . . 19 81 6.4. Congestion Avoidance . . . . . . . . . . . . . . . . . . . 20 82 7. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 7.1. Using Nicknames within a Chat Room . . . . . . . . . . . . 22 84 7.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 24 85 7.3. Removing a Nickname . . . . . . . . . . . . . . . . . . . 24 86 7.4. Nicknames in Conference Event Packages . . . . . . . . . . 25 87 8. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . . . 25 88 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 27 90 9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 29 91 9.3. Sending a regular message to the chat room . . . . . . . . 30 92 9.4. Sending a private message to a participant . . . . . . . . 32 93 9.5. Chunked private message . . . . . . . . . . . . . . . . . 34 94 9.6. Nickname in a conference information document . . . . . . 34 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 96 10.1. New MSRP Method . . . . . . . . . . . . . . . . . . . . . 36 97 10.2. New MSRP Header . . . . . . . . . . . . . . . . . . . . . 36 98 10.3. New MSRP Status Codes . . . . . . . . . . . . . . . . . . 36 99 10.4. New SDP Attribute . . . . . . . . . . . . . . . . . . . . 37 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 101 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 102 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 104 14.1. Normative References . . . . . . . . . . . . . . . . . . . 40 105 14.2. Informative References . . . . . . . . . . . . . . . . . . 41 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 108 1. Introduction 110 The Message Session Relay Protocol (MSRP) [RFC4975] defines a 111 mechanism for sending a series of instant messages within a session. 112 The Session Initiation Protocol (SIP) [RFC3261] in combination with 113 the Session Description Protocol (SDP) [RFC4566] allows for two peers 114 to establish and manage such sessions. 116 In another application of SIP, a user agent can join in a multi-party 117 conversation called a conference that is hosted by a specialized user 118 agent called a focus [RFC4353]. Such a conference can naturally 119 involve MSRP sessions. It is the responsibility of an entity 120 handling the media to relay instant messages received from one 121 participant to the rest of the participants in the conference. 123 Several such systems already exist in the Internet. Participants in 124 a chat room can be identified with a pseudonym or nickname, and 125 decide whether their real identifier is disclosed to other 126 participants. Participants can also use a rich set of features such 127 as the ability to send private instant messages to other 128 participants. 130 Similar conferences supporting chat rooms are already available 131 today. For example, Internet Relay Chat (IRC) [RFC2810], Extensible 132 Messaging and Presence Protocol (XMPP): Core [RFC6120] based chat 133 rooms, and many other proprietary systems provide chat room 134 functionality. Specifying equivalent functionality for MSRP-based 135 systems eases interworking between these systems. 137 This document defines requirements, conventions, and extensions for 138 providing private messages and nickname management in centralized 139 chat rooms with MSRP. Participants in a chat room can be identified 140 by a pseudonym, and decide if their real identifier is disclosed to 141 other participants. This memo uses the SIP Conferencing Framework 142 [RFC4353] as a design basis. It also aims to be compatible with the 143 A Framework for Centralized Conferencing [RFC5239]. Should 144 requirements arise, future mechanisms for providing similar 145 functionality in generic conferences might be developed, for example, 146 where the media is not only restricted to MSRP. The mechanisms 147 described in this document provide a future compatible short-term 148 solution for MSRP centralized chat rooms. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119, BCP 14 156 [RFC2119], and indicate requirement levels for compliant 157 implementations. 159 This memo deals with tightly coupled SIP conferences defined in SIP 160 Conferencing Framework [RFC4353] and adopts the terminology from that 161 document. In addition to that terminology, we introduce some new 162 terms: 164 Nickname: a pseudonym or descriptive name associated to a 165 participant. See Section 7 for details. 167 Multi-party chat: an instance of a tightly coupled conference, in 168 which the media exchanged between the participants consist of MSRP 169 based instant messages. Also known as a chat room. 171 Chat Room: a synonym for a multi-party chat. 173 Chat Room URI: a URI that identifies a particular chat room, and is 174 a synonym of a Conference URI defined in RFC 4353 [RFC4353]. 176 Sender: the chat room participant who originally created an instant 177 message and sent it to the chat room server for further delivery. 179 Recipient: the destination chat room participant(s). This defaults 180 to the full conference participant list minus the Instant Message 181 (IM) Sender. 183 MSRP switch: a media level entity that is a MSRP endpoint. It is a 184 special MSRP endpoint that receives MSRP messages and delivers 185 them to the other chat room participants. The MSRP switch has a 186 similar role to a conference mixer with the exception that the 187 MSRP switch does not actually "mix" together different input media 188 streams; it merely relays the messages between chat room 189 participants. 191 Private Instant Message: an instant message sent in a chat room 192 intended for a single participant. Generally speaking, a private 193 IM is seen by the MSRP switch, in addition to the sender and 194 recipient. A private IM is usually rendered distinctly from the 195 rest of the IMs, indicating that the message was a private 196 communication. 198 Anonymous URI: a URI concealing the participant's SIP AOR from the 199 other participants in the chat room. The allocation of such a URI 200 is out of scope of this specification. An anonymous URI must be 201 valid for the length of the chat room session and will be utilized 202 by the MSRP switch to forward messages to and from anonymous 203 participants. Privacy and anonymity are discussed in greater 204 detail in RFC 3323 [RFC3323] and RFC 3325 [RFC3325]. 206 Conference Event Package: a notification mechanism that allows 207 conference participants to learn conference information including 208 roster and state changes in a conference. This would typically be 209 A Session Initiation Protocol (SIP) Event Package for Conference 210 State [RFC4575] or Conference Event Package Data Format Extension 211 for Centralized Conferencing [RFC6502]. 213 Identifier: a string used to recognize or establish as being a 214 particular user. 216 To log in: to enter identifying data, as a name or password, into a 217 chat room, so as to be able to do work with the chat room. 219 3. Motivations and Requirements 221 Although conference frameworks describing many types of conferencing 222 applications already exist, such as the Framework for Centralized 223 Conferencing [RFC5239] and the SIP Conferencing Framework [RFC4353], 224 the exact details of session-based instant messaging conferences 225 (chat rooms) are not well-defined at the moment. 227 To allow interoperable chat implementations, for both conference- 228 aware, and conference-unaware user agents, certain conventions for 229 MSRP chat rooms need to be defined. It also seems beneficial to 230 provide a set of features that enhance the baseline multi-party MSRP 231 in order to be able to create systems that have functionality on par 232 with existing chat systems, as well as enable building interworking 233 gateways to these existing chat systems. 235 We define the following requirements: 237 REQ-1: A basic requirement is the existence of a chat room, where 238 participants can join and leave the chat room and get instant 239 messages exchanged to the rest of the participants. 241 REQ-2: A recipient of an instant message in a chat room must be able 242 to determine the identifier of the sender of the message. 243 Note that the actual identifier depends on the one which was 244 used by the sender when they joined the chat room. 246 REQ-3: A recipient of an instant message in a chat room must be able 247 to determine the identifier of the recipient of received 248 messages. For instance, the recipient of the message might 249 be the entire chat room or a single participant (i.e., a 250 private message). Note that the actual identifier may depend 251 on the one which was used by the recipient when he or she 252 joined the chat room. 254 REQ-4: It must be possible to send a message to a single participant 255 within the chat room (i.e., a private instant message). 257 REQ-5: A chat room participant may have a nickname or pseudonym 258 associated with their real identifier. 260 REQ-6: It must be possible for a participant to change their 261 nickname during the progress of the chat room session. 263 REQ-7: It must be possible that a participant is only known by an 264 anonymous identifier and not their real identifier to the 265 rest of the chat room. 267 REQ-8: It must be possible for chat room participants to learn the 268 chat room capabilities described in this document. 270 4. Overview of Operation 272 Before a chat room can be entered, it must be created. Users wishing 273 to host a chat room themselves can of course do just that; their User 274 Agent (UA) simply morphs from an ordinary UA into a special purpose 275 one called a Focus UA. Another, commonly used setup is one where a 276 dedicated node in the network functions as a Focus UA. 278 Each chat room has an identifier of its own: a SIP URI that 279 participants use to join the chat room, e.g. by sending an INVITE 280 request to it. The conference focus processes the invitations, and 281 as such, maintains SIP dialogs with each participant. In a multi- 282 party chat, or chat room, MSRP is one of the established media 283 streams. Each chat room participant establishes an MSRP session with 284 the MSRP switch, which is a special purpose MSRP application. The 285 MSRP sessions can be relayed by one or more MSRP relays, which are 286 specified in RFC 4976 [RFC4976]. This is illustrated in Figure 1. 288 MSRP Sessions 289 +--------------------------+ 290 | | 291 +---+--+ +---+--+ | 292 | SIP | | SIP | | 293 | MSRP | | MSRP | +-----+-----+ 294 |Client| |Client| | MSRP | 295 +---+--+ ++--+--+ | Relay | 296 | | \ +-----+-----+ 297 SIP Dialogs | / +----+ | 298 | | \ | MSRP Sessions 299 +----+------+--+ | | 300 | | +-+-----+-----+ 301 | Conference | | MSRP | 302 | Focus UA |........| Switch | 303 | | | | 304 +----+-------+-+ +-+-----+-----+ 305 | \ | | 306 SIP Dialogs | | +------+ | MSRP Sessions 307 | \ / | 308 +---+--+ +-+--+-+ +-----+-----+ 309 | SIP | | SIP | | MSRP | 310 | MSRP | | MSRP | | Relay | 311 |Client| |Client| +-----+-----+ 312 +---+--+ +------+ | 313 | | 314 +--------------------------+ 315 MSRP sessions 317 Figure 1: Multi-party chat overview shown with MSRP Relays and a 318 conference Focus UA 320 The MSRP switch is similar to a conference mixer in that it handles 321 media sessions with each of the participants and bridges these 322 streams together. However, unlike a conference mixer, the MSRP 323 switch merely forwards messages between participants but doesn't 324 actually mix the streams in any way. The system is illustrated in 325 Figure 2. 327 +------+ 328 | MSRP | 329 |Client| 330 +------+ +--.---+ +------+ 331 | MSRP | | | MSRP | 332 |Client| | _|Client| 333 +------._ | ,' +------+ 334 `._ | ,' 335 `.. +----------+ ,' 336 `| |' 337 | MSRP | 338 | Switch | 339 ,| |_ 340 _,-'' +----------+ ``-._ 341 +------.-' | `--+------+ 342 | MSRP | | | MSRP | 343 |Client| | |Client| 344 +------+ | +------+ 345 +---'--+ 346 | MSRP | 347 |Client| 348 +------+ 350 Figure 2: Multi-party chat in a Centralized Chat Room 352 Typically chat room participants also subscribe to a conference event 353 package to gather information about the conference roster in the form 354 of conference state notifications. For example, participants can 355 learn about other participants' identifiers, including their 356 nicknames. 358 All messages in the chat room use the 'Message/CPIM' wrapper content 359 type [RFC3862], so that it is possible to distinguish between private 360 and regular messages. When a participant wants to send an instant 361 message to the chat room, it constructs an MSRP SEND request and 362 submits it to the MSRP switch including a regular payload (e.g. a 363 Message/CPIM message that contains text, HTML, an image, etc.). The 364 Message/CPIM To header is set to the chat room URI. The switch then 365 fans out the SEND request to all of the other participants using 366 their existing MSRP sessions. 368 A participant can also send a private instant message addressed to a 369 participant whose identifier has been learned, e.g. via a conference 370 event package. In this case the sender creates an MSRP SEND request 371 with a Message/CPIM wrapper whose To header contains not the chat 372 room URI but the recipient's URI. The MSRP switch then forwards the 373 SEND request to that recipient. This specification supports the 374 sending of private messages to one and only one recipient. However, 375 if the recipient is logged in from different endpoints, the MSRP 376 switch will distribute the private message to each endpoint the 377 recipient is logged in. 379 We extend the current MSRP negotiation that takes place in SDP 380 [RFC4566] to allow participants to learn whether the chat room 381 supports and is willing to accept (e.g. due to local policy 382 restrictions) certain MSRP functions defined in this memo, such as 383 nicknames or private messaging. This is achieved by a new 'chatroom' 384 attribute in SDP (please refer to Section 8 for a detailed 385 description). 387 Naturally, when a participant wishes to leave a chat room, it sends a 388 SIP BYE request to the Focus UA and terminates the SIP dialog with 389 the focus and MSRP sessions with the MSRP switch. 391 This document assumes that each chat room is allocated its own SIP 392 URI. A user joining a chat room sends an INVITE request to that SIP 393 URI, and as a result, a new MSRP session is established between the 394 user and the MSRP switch. It is assumed that an MSRP session is 395 mapped to a chat room. If a user wants to join a second chat room, 396 he creates a different INVITE request, through a different SIP 397 dialog, which leads to the creation of a second MSRP session between 398 the user and the MSRP switch. Notice that these two MSRP sessions 399 can still be multiplexed over the same TCP connection as per regular 400 MSRP procedures. However, each chat room is associated to a unique 401 MSRP session and a unique SIP dialog. 403 4.1. Policy Attributes of the Chat Room 405 The Conference Framework with SIP [RFC4353] introduces the notion of 406 a Conference Policy as a complete set of rules governing a particular 407 conference. In the case of chat rooms, since they are a specialized 408 type of conferences, the notion of a Conference Policy exists and it 409 is sometimes extended with new chat-specific rules. This section 410 lists all the Conference Policy attributes used by the present 411 document and refers to sections in the document where the usage of 412 these attributes are described in greater detail. 414 Nicknames: Whether the chat room accepts users to be recognized 415 with a nickname. See Section 7, Section 7.1, and Section 8 for 416 details. Also, the scope of uniqueness of the nickname: the chat 417 room (conference instance), a realm or domain, a server, etc. 419 Nickname quarantine: The quarantine to be imposed to a nickname 420 once it is not currently in use (e.g., because the participant 421 holding this nickname abandons the chat room), prior to the wide 422 availability of this nickname to other users. This allows the 423 initial holder of the nickname to join the chat room during the 424 quarantine period and claim the same nickname they were previously 425 using. See Section 11 for details. 427 Private messaging: Whether the chat room accepts users to send 428 private messages to other users of the chat room through the MSRP 429 switch. See Section 6.2 and Section 8 for details. 431 Deletion of the chat room: Whether the chat room can be deleted 432 when the creator leaves the chat room or through an out of band 433 mechanism. See Section 5.3 for details. 435 Simultaneous access: Whether a user can log from different 436 endpoints using the same identity. See Section 6.1 and 437 Section 6.2 for details. 439 Force TLS transport: Whether the MSRP switch accepts only TLS as an 440 MSRP transport, in an effort to guarantee confidentiality and 441 privacy. See Section 11 for details. 443 Maximum message size in congested MSRP sessions: The maximum size 444 of messages that can be distributed to a user over a congested 445 MSRP session. See Section 6.4 for details. 447 Chunk reception timer: The value of a time that controls the 448 maximum time that the MSRP switch is waiting for the reception of 449 different chunks belonging to the same message. If the timer 450 expires, the MSRP switch will discard the associated message 451 state. See Section 6.1 for details. 453 Supported wrapped media types: The list of media types that the 454 MSRP switch accepts in Message/CPIM wrappers sent from 455 participants. This list is included in the 'accept-wrapped-types' 456 attribute of the MSRP message media line in SDP. If the MSRP 457 switch accepts additional media types than those explicitly 458 listed, a "*" is added to the list. A single "*" indicates that 459 the chat room accepts any wrapped media type. 461 5. Creating, Joining, and Deleting a Chat Room 463 5.1. Creating a Chat Room 465 Since we consider a chat room a particular type of conference having 466 MSRP media, the methods defined by the SIP Conference Framework 467 [RFC4353] for creating conferences are directly applicable to a chat 468 room. 470 Once a chat room is created, it is identified by a SIP URI, like any 471 other conference. 473 5.2. Joining a Chat Room 475 Participants usually join the chat room by sending an INVITE request 476 to the chat room URI. The chat room then uses regular SIP mechanisms 477 to authenticate the participant. This may include, e.g., client 478 certificates, SIP Digest authentication [RFC3261], asserted network 479 identity [RFC3325], SIP Identity header field [RFC4474], etc. As 480 long as the user is authenticated, the INVITE request is accepted by 481 the focus and the user is brought into the actual chat room. 483 This specification requires all instant messages to be wrapped in a 484 Message/CPIM wrapper [RFC3862]. Therefore, the 'accept-types' 485 attribute for the MSRP message media in both the SDP offer and answer 486 need to include at least the value 'Message/CPIM' (Notice that RFC 487 4575 [RFC4575] mandates this 'accept-types' attribute in SDP). If 488 the 'accept-types' attribute does not contain the value 'Message/ 489 CPIM', the conference focus will reject the request. The actual 490 instant message payload type is negotiated in the 'accept-wrapped- 491 types' attribute in SDP (see RFC 4975 [RFC4975] for details). There 492 is no default wrapped type. Typical wrapped type values can include: 493 text/plain, text/html, image/jpeg, image/png, audio/mp3, etc. It is 494 RECOMMENDED that participant endpoints add an 'accept-wrapped-types' 495 attribute to the MSRP 'message' media line in SDP, where the 496 supported wrapped types are declared, as per RFC 4975 procedures 497 [RFC4975]. 499 The MSRP switch needs to be aware of the URIs of the participant 500 (SIP, Tel, or IM URIs) in order to validate messages sent from this 501 participant prior to their forwarding. This information is known to 502 the focus of the conference. Therefore an interface between the 503 focus and the MSRP switch is assumed. However, the interface between 504 the focus and the MSRP switch is outside the scope of this document. 506 Conference-aware participants will detect that the peer is a focus 507 due to the presence of the "isfocus" feature tag [RFC3840] in the 508 Contact header field of the 200-class response to the INVITE request. 509 Conference-unaware participants will not notice it is a focus, and 510 can not apply the additional mechanisms defined in this document. 511 Participants are also aware that the mixer is an MSRP switch due to 512 the presence of a 'message' media type and either TCP/MSRP or TCP/ 513 TLS/MSRP as the protocol field in the media line of SDP [RFC4566]. 515 The conference focus of a chat room MUST only use a Message/CPIM 516 [RFC3862] top-level wrapper as a payload of MSRP messages, and the 517 focus MUST declare it in the SDP offer or answer as per regular RFC 518 4975 procedures [RFC4975]. This implies that if the conference focus 519 receives from a participant's endpoint an SDP offer that does not 520 include the value 'Message/CPIM' in the 'accept-types' attribute for 521 the MSRP message media line, the conference focus SHOULD either 522 reject the MSRP message media stream or the complete SDP offer by 523 using regular SIP or SDP procedures (e.g., creating an SDP answer 524 that sets to zero the port of the MSRP message media line, responding 525 the INVITE with a 488 response, etc.). 527 If the conference focus accepts the participant's SDP offer, when the 528 conference focus generates the SDP answer, it MUST set the 'accept- 529 types' attribute for the MSRP message media line to a value of 530 'Message/CPIM'. This specification requires all instant messages to 531 be wrapped in a Message/CPIM wrapper, therefore, the 'accept-types' 532 attribute in this SDP body contains a single value of 'Message/CPIM'. 533 The actual instant message payload type is negotiated in the 'accept- 534 wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details). 535 The conference focus MAY also add an 'accept-wrapped-types' attribute 536 to the MSRP message media line in SDP containing the supported 537 wrapped types, according to the supported wrapped media types policy. 539 Note that the 'Message/CPIM' wrapper is used to carry the sender 540 information that, otherwise, it will not be available to the 541 recipient. Additionally, 'Message/CPIM' wrapper carries the 542 recipient information (e.g. To and Cc: headers). 544 If the user agent supports anonymous participation and the user 545 chooses to use it, the participant's UA SHOULD do at least one of 546 these options: 548 (a) provide an anonymous URI in SIP headers that otherwise reveal 549 identifiers. Please refer to RFC 3323 [RFC3323] for a detailed 550 description of which headers are subject to reveal identifiers 551 and how to populate them; or 553 (b) trust the conference focus and request privacy of their URI, 554 e.g, by means of the SIP Privacy header field [RFC3323], Network 555 asserted identity [RFC3325], or similar privacy mechanism. 557 If the participant has requested privacy, the conference focus MUST 558 expose a participant's anonymous URI through the conference event 559 package [RFC4575]. 561 The conference focus of a chat room learns the supported chat room 562 capabilities in the endpoint by means of the 'chatroom' attribute 563 exchanged in the SDP offer/answer (please refer to Section 8 for a 564 detailed description). The conference focus MUST inform the MSRP 565 switch of the chat room capabilities of each participant that joins 566 the chat room (note that the interface defined between the conference 567 focus and the MSRP switch is outside the scope of this 568 specification). This information allows the MSRP switch, e.g., to 569 avoid the distribution of private messages to participants whose 570 endpoints do not support private messaging. 572 5.3. Deleting a Chat Room 574 As with creating a conference, the methods defined by the SIP 575 Conference Framework [RFC4353] for deleting a conference are directly 576 applicable to a chat room. The MSRP switch will terminate the MSRP 577 sessions with all the participants. 579 Deleting a chat room is an action that heavily depends on the policy 580 of the chat room. The policy can determine that the chat room is 581 deleted when the creator leaves the chat room, or with any out of 582 band mechanism. 584 6. Sending and Receiving Instant Messages 586 6.1. Regular Messages 588 This section describes the conventions used to send and receive 589 instant messages that are addressed to all the participants in the 590 chat room. These are sent over a regular MSRP SEND request that 591 contains a Message/CPIM wrapper [RFC3862] that in turn contains the 592 desired payload (e.g. text, image, video-clip, etc.). 594 When a chat room participant wishes to send an instant message to all 595 the other participants in the chat room, it constructs an MSRP SEND 596 request according to the procedures specified in RFC 4975 [RFC4975]. 597 The sender MAY choose the desired MSRP report model (e.g., populate 598 the Success-Report and Failure-Report MSRP header fields). 600 On sending a regular message the sender MUST populate the To header 601 of the Message/CPIM wrapper with the URI of the chat room. The 602 sender MUST also populate the From header of the Message/CPIM wrapper 603 with a proper identifier by which the user is recognized in the chat 604 room. Identifiers that can be used (among others) are: 606 o A SIP URI [RFC3261] representing the participant's address-of- 607 record 609 o A tel URI [RFC3966] representing the participant's telephone 610 number 612 o An IM URI [RFC3860] representing the participant's instant 613 messaging address 615 o An Anonymous URI representing the participant's anonymous address 617 If the participant wants to remain anonymous, the participant's 618 endpoint MUST populate an anonymous URI in the From header of the 619 'Message/CPIM' wrapper. Other participants of the chat room will use 620 this anonymous URI in the To header of the 'Message/CPIM' wrapper 621 when sending private messages. Notice that in order for the 622 anonymity mechanism to work, the anonymous URI MUST NOT reveal the 623 participant's SIP AOR. The mechanism for acquiring an anonymous URI 624 is outside the scope of this specification. 626 An MSRP switch that receives a SEND request from a participant SHOULD 627 first verify that the From header field of the Message/CPIM wrapper 628 is correctly populated with a valid URI of a participant. This 629 imposes a requirement for the focus of the conference to inform the 630 MSRP switch of the URIs by which the participant is known, in order 631 for the MSRP switch to validate messages. Section 6.3 provides 632 further information with the actions to be taken in case this 633 validation fails. 635 Then the MSRP switch should inspect the To header field of the 636 Message/CPIM wrapper. If the MSRP switch receives a message 637 containing several To header fields in the Message/CPIM wrapper the 638 MSRP switch MUST reject the MSRP SEND request with a 403 response, as 639 per procedures in RFC 4975 [RFC4975]. Then, if the To header field 640 of the Message/CPIM wrapper contains the chat room URI and there are 641 no other To header fields, the MSRP switch can generate a copy of the 642 SEND request to each of the participants in the chat room except the 643 sender. The MSRP switch MUST NOT modify the content received in the 644 SEND request. However, the MSRP switch MAY re-chunk any of the 645 outbound MSRP SEND requests. 647 When generating a copy of the SEND request to each participant in the 648 chat room, the MSRP switch MUST evaluate the wrapped media types that 649 the recipient is able to accept. This was learned through the 650 'accept-wrapped-types' attribute of the MSRP message media line in 651 SDP. If the MSRP switch is aware that the media type of the wrapped 652 content is not acceptable to the recipient, the MSRP switch SHOULD 653 NOT forward this message to that endpoint. Note that this version of 654 the specification does not require the MSRP switch to notify the 655 sender about this failure. Extensions to this specification may 656 improve handling of unknown media types. 658 Note that the MSRP switch does not need to wait for the reception of 659 the complete MSRP chunk or MSRP message before it starts the 660 distribution to the rest of the participants. Instead, once the MSRP 661 switch has received the headers of the Message/CPIM wrapper it SHOULD 662 start the distribution process. But bear in mind that still the MSRP 663 switch SHOULD implement some sanity checking. Please refer to the 664 security considerations in Section 11 for further details. 666 When forwarding chunked messages as soon as they are received, the 667 Message/CPIM wrapper is only present at the beginning of the message, 668 typically within the first chunk. Subsequent chunks will contain the 669 rest of the message, but not the Message/CPIM headers. Therefore, an 670 MSRP switch that receives a subsequent message may face challenges in 671 determining the correct list of recipients of the message. An MSRP 672 switch that uses this fast forwarding procedure MUST temporarily 673 store the Message-Id of the MSRP message to correlate the different 674 chunks, as well as it MUST temporarily store the list of recipients 675 to which the initial chunks were delivered. The MSRP switch SHOULD 676 forward subsequent chunks only to those recipients who were sent the 677 initial chunks, except if the MSRP switch has knowledge that one of 678 the recipients of the initial chunks has dropped from the chat room. 679 This behavior also avoids new participants who joined the chat room 680 when the first chunk has been distributed to receive subsequent 681 chunks that would otherwise need to be discarded. 683 Once the MSRP switch receives the last chunk of a message, and that 684 chunk is successfully sent to each of the recipients, the MSRP switch 685 discards the temporary storage of MSRP Message-ID and the associated 686 list of recipients. 688 In some occasions, a sender might suffer a transport error condition 689 (such as loss of connectivity or depletion of battery) that makes the 690 sending of a message incomplete, e.g., some chunks were received by 691 the MSRP switch, but not all of them. This is a behavior already 692 considered in the core MSRP specification (see RFC 4975 [RFC4975] 693 Section 5.4). The problem in the context of a chat room lies with 694 the usage of temporary storage for fast forwarding. In order to 695 prevent attacks related to the exhaustion of temporary storage of 696 chunked messages, on receiving a first chunk of a message, where the 697 MSRP switch is using the fast forward method, the MSRP switch MUST 698 set a chunk reception timer for controlling the reception of the 699 remaining chunks. 701 This chunk reception timer can be re-set every time a new chunk of 702 the same message is received. When this timer fires, the MSRP switch 703 MUST consider that the sending of the message was aborted, and MAY 704 discard all the message state associated to it, including the 705 Message-ID and the list of recipients. Additionally, if this chunk 706 reception timer fires, the MSRP switch MAY choose to send an abort 707 chunk (i.e., one with the "#" flag set) to each to the recipients. 709 This is just an optimization, since MSRP endpoints need to be able to 710 handle incomplete messages as per regular MSRP. 712 The specific value of this chunk reception timer is not standardized; 713 it is subject of local policy. However, it is recommended not to be 714 a short value. For example a time interval on the order of a normal 715 TCP timeout (i.e., around 540 seconds) would be reasonable. A value 716 on the order of a few seconds would not. 718 An MSRP endpoint that receives a SEND request from the MSRP switch 719 containing a Message/CPIM wrapper SHOULD first inspect the To header 720 field of the Message/CPIM wrapper. If the To header field is set to 721 the chat room URI, it should render it as a regular message that has 722 been distributed to all the participants in the chat room. Then the 723 MSRP endpoint SHOULD inspect the From header field of the Message/ 724 CPIM wrapper to identify the sender. The From header field will 725 include a URI that identifies the sender. The endpoint might have 726 also received further identifier information through a subscription 727 to a conference event package. 729 It is possible that a participant, identified by a SIP Address of 730 Record or other valid URI, joins a chat room simultaneously from two 731 or more different SIP UAs. It is recommended that the MSRP switch 732 implements means to map a URI to two or more MSRP sessions. If the 733 policy of the chat room allows simultaneous access, the MSRP switch 734 MUST copy all regular messages intended to the recipient through each 735 MSRP session mapped to the recipient's URI. 737 6.2. Private Messages 739 This section describes the conventions used to send and receive 740 private instant messages, i.e., instant messages that are addressed 741 to one participant of the chat room rather to all of them. The chat 742 room has local policy that determines whether private messages are 743 supported or not. A chat room can signal support for private 744 messages using the 'chatroom' attribute in SDP (please refer to 745 Section 8 for a detailed description). 747 When a chat room participant wishes to send a private instant message 748 to a participant in the chat room, it follows the same procedures for 749 creating a SEND request as for regular messages (Section 6.1). The 750 only difference is that the MSRP endpoint MUST populate a single To 751 header of the Message/CPIM wrapper with the identifier of the 752 intended recipient. The identifier can be SIP, TEL, and IM URIs 753 typically learned from the information received in notifications of a 754 conference event package. 756 This version of the specification does not support sending a 757 private message to multiple recipients, i.e., the presence of 758 multiple To headers in the Message/CPIM wrapper of the MSRP SEND 759 request. This is due to added complexity, for example, with the 760 need to determine whether a message was not deliver to some of the 761 intended recipients. Implementations that still want to recreate 762 this function can send a series of single private messages, one 763 private message per intended recipient. The endpoint can 764 correlate this series of messages and create the effect of a 765 private message addressed to multiple recipients. 767 As for regular messages, an MSRP switch that receives a SEND request 768 from a participant SHOULD first verify that the From header field of 769 the Message/CPIM wrapper is correctly populated with a valid URI 770 (i.e., the URI is a participant of this chat room). Section 6.3 771 provides further information with the actions to be taken in case 772 this validation fails. 774 Then the MSRP switch inspects the To header field of the Message/CPIM 775 wrapper. If the MSRP switch receives a message containing several To 776 header fields in the Message/CPIM wrapper the MSRP switch MUST reject 777 the MSRP SEND request with a 403 response, as per procedures in RFC 778 4975 [RFC4975]. Then the MSRP switch verifies that the To header of 779 the Message/CPIM wrapper matches the URI of a participant of the chat 780 room. If this To header field does not contain the URI of a 781 participant of the chat room or if the To header field cannot be 782 resolved (e.g., caused by a mistyped URI), the MSRP switch MUST 783 reject the request with a 404 response. This new 404 status code 784 indicates a failure to resolve the recipient URI in the To header 785 field of the Message/CPIM wrapper. 787 Notice the importance of the From and To headers in the Message/ 788 CPIM wrapper. If an intermediary modifies these values, the MSRP 789 switch might not be able to identify the source or intended 790 destination of the message, resulting in a rejection of the 791 message. 793 Finally, the MSRP switch verifies that the recipient supports private 794 messages. If the recipient does not support private messages, the 795 MSRP switch MUST reject the request with a 428 response. This new 796 response 428 indicates that the recipient does not support private 797 messages. Any potential REPORT request that the MSRP switch sends to 798 the sender MUST include a Message/CPIM wrapper containing the 799 original From header field included in the SEND request and the To 800 header field of the original Message/CPIM wrapper. The MSRP switch 801 MUST NOT forward private messages to a recipient that does not 802 support private messaging. 804 If successful, the MSRP switch should search its mapping table to 805 find the MSRP sessions established toward the recipient. If a match 806 is found the MSRP switch MUST create a SEND request and MUST copy the 807 contents of the sender's message to it. 809 An MSRP endpoint that receives a SEND request from the MSRP switch 810 does the same validations as for regular messages (Section 6.1). If 811 the To header field is different from the chat room URI, the MSRP 812 endpoints knows that this is a private message. The endpoint should 813 render who it is from based on the value of the From header of the 814 Message/CPIM wrapper. The endpoint can also use the sender's 815 nickname, possibly learned via a conference event package, to render 816 such nickname rather than the sender's actual URI. 818 As with regular messages, if the policy of the chat room allows 819 simultaneous access, the MSRP switch MUST copy all private messages 820 intended to the recipient through each MSRP session mapped to the 821 recipient's URI. 823 6.3. MSRP reports and responses 825 This section discusses the common procedures for regular and private 826 messages with respect to MSRP reports and responses. Any particular 827 procedure affecting only regular messages or only private messages is 828 discussed in the previous Section 6.1 or Section 6.2, respectively. 830 MSRP switches MUST follow the success report and failure report 831 handling described in section 7 of RFC 4975 [RFC4975], complemented 832 with the procedures described in this section. The MSRP switch MUST 833 act as an MSRP endpoint receiver of the request according to section 834 5.3 of RFC 4975 [RFC4975]. 836 If the MSRP switch receives an MSRP SEND request that does not 837 contain a Message/CPIM wrapper, the MSRP switch MUST reject the 838 request with a 415 response (specified in RFC 4975 [RFC4975]). 840 If the MSRP switch receives an MSRP SEND request where the URI 841 included in the From header field of the Message/CPIM wrapper is not 842 valid, (e.g, because it does not "belong" to the sender of the 843 message or is not a valid participant of the chat room), the MSRP 844 switch MUST reject the request with a 403 response. In non-error 845 cases, the MSRP switch MUST construct responses according to section 846 7.2 of RFC 4975 [RFC4975]. 848 When the MSRP switch forwards a SEND request, it MAY use any report 849 model in the copies intended for the recipients. The receiver 850 reports from the recipients MUST NOT be forwarded to the originator 851 of the original SEND request. This could lead to having the sender 852 receiving multiple reports for a single MSRP request. 854 6.4. Congestion Avoidance 856 Congestion can occur when multiple heterogeneous interfaces are used 857 by a diversity of users who are participating in a chat room, and, in 858 particular, when paths become overloaded by any application. Some of 859 these users might have fast path capable of high throughputs while 860 other users might be slow paths with constrained throughputs. Some 861 paths might become congested only by the chat application; other 862 paths gets congested by other applications different than the chat 863 one. It is therefore possible that a subset of the participants of 864 the chat room are able to send and receive a large number of messages 865 in a short time or with large contents (e.g., pictures), whereas 866 others are not able to keep the pace. 868 Additionally, since MSRP uses a connection-oriented transport 869 protocol such as TCP, it is expected that TCP congestion control 870 mechanisms are activated if congestion occurs. Details on congestion 871 control are specified in RFC 5681 [RFC5681]. 873 While this document does not mandate a particular MSRP-specific 874 mechanism to avoid congestion in any of the paths, something that is 875 deemed outside the scope of this document, this document provides 876 some recommendations for implementors to consider. 878 It is RECOMMENDED that MSRP switches implement one or more MSRP- 879 specific strategies to detect and avoid congestion. Possible 880 strategies (but definitely not a comprehensive list) include: 882 o If the MSRP switch is writing data to a send buffer and detects 883 that the send buffer associated to that TCP connection is getting 884 full (e.g., close to 80% of its capacity), the MSRP switch marks 885 the associated MSRP sessions making use of that TCP connection as 886 "congested". 888 o Prior to sending a new MSRP message to a user, the MSRP switch 889 verifies the congested flag associated to that MSRP session. If 890 the MSRP session is marked as congested, the MSRP switch can apply 891 a congestion avoidance mechanism, such as: 893 * The MSRP switch MAY discard regular MSRP messages sent to that 894 user while the congestion flag is raised for the user's TCP 895 connection. In order to inform the user of the congestion, the 896 MSRP switch MAY send a regular MSRP message to the user whose 897 congestion flag is raised. This message indicates that some 898 other messages are being discarded due to network congestion. 899 However, it should be noted that this message can get stuck at 900 MSRP switch, if the path is fully congested, i.e., it may not 901 be delivered anyhow. 903 * The MSRP can implement a temporary policy to disallow the 904 distribution of messages larger than a certain size to MSRP 905 sessions marked as congested. Similarly, the user should be 906 informed of this fact by the MSRP switch sending a regular MSRP 907 message indicating this condition. 909 o If the MSRP switch determines that the congestion flag associated 910 to a given TCP connection has been raised for quite some time (on 911 the order of a few minutes), or if the interface is down, this may 912 be considered as an indication that the TCP connection has not 913 been able to recover from a congestion state. The MSRP switch MAY 914 close this congested TCP connection, as well as the MSRP session 915 and SIP session. 917 7. Nicknames 919 A common characteristic of existing chat room services is that 920 participants have the ability to present themselves with a nickname 921 to the rest of the participants of the chat room. It is used for 922 easy reference of participants in the chat room, and can also provide 923 anonymous participants with a meaningful descriptive name. 925 A nickname is a useful construct in many use cases, of which MSRP 926 chat is but one example. It is associated with a URI of which the 927 participant is known to the focus. Therefore, if a user joins the 928 chat room under the same URI from multiple devices, he or she may 929 request the same nickname across all these devices. 931 A nickname is a user selectable appearance of which the participant 932 wants to be known to the other participants. It is not a 'display- 933 name', but it is used somewhat like a display name. A main 934 difference is that a nickname is unique inside a chat room to allow 935 an unambiguous reference to a participant in the chat. Nicknames may 936 be long lived, or may be temporary. Users also need to reserve a 937 nickname prior to its utilization. 939 This memo specifies the nickname as a string. The nickname string 940 MUST unambiguously be associated to a single user in the scope of the 941 chat room (conference instance). This scope is similar to having a 942 nickname unique per user inside a chat room from Extensible Messaging 943 and Presence Protocol [RFC6120]. The chat room may have policies 944 associated with nicknames. It may not accept nickname strings at 945 all, or a it may provide a wider unambiguous scope like a domain or 946 server, similar to Internet Relay Chat (IRC) [RFC2810]. 948 7.1. Using Nicknames within a Chat Room 950 This memo provides a mechanism to reserve a nickname for a 951 participant for as long as the participant is logged into the chat 952 room. The mechanism is based on a NICKNAME MSRP method (see below) 953 and a new "Use-Nickname" header. Note that other mechanisms may 954 exist (for example, a web page reservation system), although they are 955 outside the scope of this document. 957 A chat room participant who has established an MSRP session with the 958 MSRP switch, where the MSRP switch has indicated the support and 959 availability of nicknames with the 'nicknames' token in the 960 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP 961 switch. The NICKNAME request MUST include a new Use-Nickname header 962 that contains the nickname string that the participant wants to 963 reserve. This nickname string MUST NOT be zero octets in length and 964 MUST NOT be more than 1023 octets in length. Last, MSRP NICKNAME 965 requests MUST NOT include Success-Report or Failure-Report header 966 fields. 968 Bear in mind that nickname strings, like the rest of the MSRP 969 message, use the UTF-8 transformation format [RFC3629]. 970 Therefore, a character may result encoded in more than one octet. 972 An MSRP switch that receives a NICKNAME request containing a 973 Use-Nickname header field SHOULD first verify whether the policy of 974 the chat room allows the nickname functionality. If not allowed, the 975 MSRP switch MUST reject the request with a 403 response, as per RFC 976 4975 [RFC4975]. 978 If the policy of the chat room allows the usage of nicknames, any new 979 nickname requested MUST be prepared and compared with nicknames 980 already in use or reserved following the rules defined in Preparation 981 and Comparison of Nicknames [I-D.ietf-precis-nickname]. 983 This mitigates the problem of nickname duplication, but it does not 984 solve a problem whereby users can choose similar (but different) 985 characters to represent two different nicknames. For example, "BOY" 986 and "B0Y" are different nicknames which can mislead users. The 987 former uses the capital letter "O" while the latter uses the number 988 zero "0". In many fonts the letter "O" and the number zero "0" might 989 be quite similar, and difficult to be perceived as different 990 characters. Chat rooms MAY provide a mechanism to mitigate 991 confusable nicknames. 993 In addition to preparing and comparing following the rules above, the 994 MSRP switch SHOULD only allow the reservation of an already used 995 nickname, if the same user (e.g., identified by the SIP AOR) that is 996 currently using the nickname is making this subsequent request. This 997 may include, e.g., allowing that the participant's URI may use the 998 same nickname when the participant has joined the chat room from 999 different devices under the same URI. The participant's 1000 authenticated identifier can be derived after a successful SIP Digest 1001 Authentication [RFC3261], be included in a trusted SIP P-Asserted- 1002 Identity header field [RFC3325], be included in a valid SIP Identity 1003 header field [RFC4474], or be derived from any other present or 1004 future SIP authentication mechanism. Once the MSRP switch has 1005 validated that the participant is entitled to reserve the requested 1006 nickname, the MSRP switch verifies if the suggested nickname can be 1007 accepted (see below). 1009 The reservation of a nickname can fail in several cases. If the 1010 NICKNAME request contains a malformed value in the Use-Nickname 1011 header field, the MSRP switch MUST answer the NICKNAME request with a 1012 424 response code. This can be the case when the value of the 1013 Use-Nickname header field does not conform to the syntax. 1015 The reservation of a nickname can also fail if the value of the 1016 Use-Nickname header field of the NICKNAME request is a reserved word 1017 (not to be used as a nickname by any user) or that particular value 1018 is already in use by another user. In this case the MSRP switch MUST 1019 answer the NICKNAME request with a 425 response code. 1021 In both error conditions (receiving a 424 or 425 response code), the 1022 nickname usage is considered failed; the nickname is not allocated to 1023 this user. The user can select a different nickname and retry 1024 another NICKNAME request. 1026 If the MSRP switch is able to accept the suggested nickname to be 1027 used by this user, the MSRP switch MUST answer the NICKNAME request 1028 with a 200 response as per regular MSRP procedures. 1030 As indicated earlier, this specification defines a new MSRP header 1031 field: "Use-Nickname". The Use-Nickname header field carries a 1032 nickname string. This specification defines the usage of the 1033 Use-Nickname header field in NICKNAME requests. If need arises, 1034 usages of the Use-Nickname header field in other MSRP methods should 1035 be specified separately. 1037 According to RFC 4975 [RFC4975], MSRP uses the UTF-8 transformation 1038 format [RFC3629]. The syntax of the MSRP NICKNAME method and the 1039 "Use-Nickname" header field is built upon the MSRP formal syntax 1040 [RFC4975] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. 1042 ext-method =/ NICKNAMEm 1043 NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps 1044 ext-header =/ Use-Nickname 1045 ; ext-header defined in RFC 4975 1046 Use-Nickname = "Use-Nickname:" SP nickname 1047 nickname = DQUOTE 1*1023(qdtext / qd-esc) DQUOTE 1048 ; qdtext and qd-esc defined in RFC 4975 1050 Note that, according to RFC 4975 [RFC4975], "quoted-string" admits a 1051 subset of UTF-8 characters [RFC3629]. Please refer to Section 9 of 1052 RFC 4975 [RFC4975] for more details. 1054 Once the MSRP switch has reserved a nickname and has bound it to a 1055 URI (e.g., a SIP Address-of-Record), the MSRP server MAY allow the 1056 usage of the same nickname by the same user (identified by the same 1057 URI, such as a SIP AoR) over a second MSRP session. This might be 1058 the case if the user joins the same chat room from a different SIP 1059 User Agent. In this case, the user MAY request the same or a 1060 different nickname than that used in conjunction with the first MSRP 1061 session; the MSRP server MAY accept the usage of the same nickname by 1062 the same user. The MSRP switch MUST NOT automatically assign the 1063 same nickname to more than one MSRP session established from the same 1064 URI, because this can create confusion to the user as whether the 1065 same nickname is bound to the second MSRP session. 1067 7.2. Modifying a Nickname 1069 Typically a participant will reserve a nickname as soon as the 1070 participant joins the chat room. But it is also possible for a 1071 participant to modify his/her own nickname and replace it with a new 1072 one at any time during the duration of the MSRP session. 1073 Modification of the nickname is not different from the initial 1074 reservation and usage of a nickname, thus the NICKNAME method is used 1075 as described in Section 7.1. 1077 If a NICKNAME request that attempts to modify the current nickname of 1078 the user for some reason fails, the current nickname stays in effect. 1079 A new nickname comes into effect and the old one is released only 1080 after a NICKNAME request is accepted with a 200 response. 1082 7.3. Removing a Nickname 1084 If the participant no longer wants to be known by a nickname in the 1085 chat room, the participant can follow the method described in 1086 Section 7.2. The nickname element of the Use-Nickname header MUST be 1087 set to an empty quoted string. 1089 7.4. Nicknames in Conference Event Packages 1091 Typically the conference focus acts as a notifier of the conference 1092 event package, RFC 4575 [RFC4575]. It is RECOMMENDED that conference 1093 foci and endpoints support RFC 6502 [RFC6502] for providing 1094 information regarding the conference, and in particular, supplying 1095 information of the roaster of the conference. It is also RECOMMENDED 1096 that conference foci and endpoints support RFC 6501 [RFC6501], which 1097 extends the element originally specified in RFC 4575 [RFC4575] 1098 with a new 'nickname' attribute. This allows endpoints to learn the 1099 nicknames of participants of the chat room. 1101 8. The SDP 'chatroom' attribute 1103 There are a handful of use cases where a participant would like to 1104 learn the chat room capabilities supported by the local policy of the 1105 MSRP switch and the chat room. For example, a participant would like 1106 to learn if the MSRP switch supports private messaging, otherwise, 1107 the participant may send what he believes is a private instant 1108 message addressed to a participant, but since the MSRP switch does 1109 not support the functions specified in this memo, the message gets 1110 eventually distributed to all the participants of the chat room. 1112 The reverse case also exists. A participant, say Alice, whose user 1113 agent does not support the extensions defined by this document joins 1114 the chat room. The MSRP switch learns that Alice's application does 1115 not support private messaging nor nicknames. If another participant, 1116 say Bob, sends a private message to Alice, the MSRP switch does not 1117 distribute it to Alice, because Alice is not able to differentiate it 1118 from a regular message sent to the whole roster. Furthermore, if 1119 Alice replied to this message, she would do it to the whole roster. 1120 Because of this, the MSRP switch also keeps track of users who do not 1121 support the extensions defined in this document. 1123 In another scenario, the policy of a chat room may indicate that 1124 certain functions are not allowed. For example, the policy may 1125 indicate that nicknames or private messages are not allowed. 1127 In order to provide the user with a good chat room experience, we 1128 define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a 1129 media-level value attribute [RFC4566] that MAY be included in 1130 conjunction with an MSRP media stream (i.e., when an m= line in SDP 1131 indicates "TCP/MSRP" or "TCP/TLS/MSRP"). The 'chatroom' attribute 1132 without further modifiers (e.g., chat-tokens) indicates that the 1133 endpoint supports the procedures described in this document for 1134 transferring MSRP messages to/from a chat room. The 'chatroom' 1135 attribute can be complemented with additional modifiers that further 1136 indicate the intersection of support and local policy allowance for a 1137 number of functions specified in this document. Specifically, we 1138 provide the means for indicating support to use nicknames and private 1139 messaging. 1141 The 'chatroom' attribute merely indicates the capabilities supported 1142 and allowed by the local policy. This attribute is not a negotiation 1143 subject to the SDP offer/answer model [RFC3264], but instead a 1144 declaration. Therefore, a 'chatroom' attribute included in an SDP 1145 answer does not need to be a subset of the values included in the 1146 'chatroom' attribute of its corresponding SDP offer. Consequently, 1147 an SDP answer MAY contain a 'chatroom' attribute even if its 1148 corresponding SDP offer did not include it. 1150 On doing subsequent SDP offer/answer [RFC3264] exchanges pertaining 1151 to the same session, the 'chatroom' attribute MAY be modified with 1152 respect an earlier SDP offer/answer exchange. The new value of this 1153 attribute indicate the current support and local policy, meaning that 1154 some restrictions can apply now or might have been removed. If the 1155 'chatroom' attribute is not included in a subsequent SDP offer/ 1156 answer, but is corresponding MSRP stream is still in place, it 1157 indicates that support for the procedures indicated in this document 1158 are disabled. 1160 The 'chatroom' SDP attribute has the following Augmented BNF (ABNF) 1161 [RFC5234] syntax: 1163 attribute =/ chatroom-attr 1164 ; attribute defined in RFC 4566 1165 chatroom-attr = chatroom-label [":" chat-token 1166 *(SP chat-token)] 1167 chatroom-label = "chatroom" 1168 chat-token = (nicknames-token / private-msg-token / 1169 ext-token) 1170 nicknames-token = "nickname" 1171 private-msg-token = "private-messages" 1172 ext-token = private-token / standard-token 1173 private-token = toplabel "." *(domainlabel ".") token 1174 ; toplabel defined in RFC 3261 1175 ; domainlabel defined in RFC 3261 1176 ; token defined in RFC 3261 1177 standard-token = token 1179 A given 'chat-token' value MUST NOT appear more than once in a 1180 'chatroom' attribute. 1182 A conference focus that includes the 'nicknames' token in the session 1183 description is signaling that the MSRP switch supports and the chat 1184 room allows to use the procedures specified in Section 7. A 1185 conference focus that includes the 'private-messages' in the SDP 1186 description is signaling that the MSRP switch supports and the chat 1187 room allows to use the procedures specified in Section 6.2. 1189 Example of the 'chatroom' attribute for an MSRP media stream that 1190 indicates the acceptance of nicknames and private messages: 1192 a=chatroom:nickname private-messages 1194 An example of a 'chatroom' attribute for an MSRP media stream where 1195 the endpoint, e.g., an MSRP switch, does not allow either nicknames 1196 nor private messages. 1198 a=chatroom 1200 The 'chatroom' attribute allows extensibility with the addition of 1201 new tokens. No IANA registry is provided at this time, since no 1202 extensions are expected at the time of this writing. Extensions to 1203 the 'chatroom' attribute can be defined in IETF documents or as 1204 private vendor extensions. 1206 Extensions defined in IETF document MUST follow the 'standard-token' 1207 ABNF previously defined. In this type of extensions, care must be 1208 taken in the selection of the token to avoid a clash with any of the 1209 tokens previously defined. 1211 Private extensions MUST follow the 'private-token' ABNF previously 1212 defined. The 'private-token' MUST include the DNS name of the 1213 vendor. Then the token is reversed in order to avoid clashes of 1214 tokens. The following is an example of a extension named "foo.chat" 1215 by a vendor "example.com" 1217 a=chatroom:nickname private-messages com.example.chat.foo 1219 Note that feature names created by different organizations are not 1220 intended to have the same semantics or even interoperate. 1222 9. Examples 1224 9.1. Joining a chat room 1226 Figure 3 presents a flow diagram where Alice joins a chat room by 1227 sending an INVITE request. This INVITE request contains a session 1228 description that includes the chatroom extensions defined in this 1229 document. 1231 Alice Conference focus 1232 | | 1233 |F1: (SIP) INVITE | 1234 |----------------------->| 1235 |F2: (SIP) 200 OK | 1236 |<-----------------------| 1237 |F3: (SIP) ACK | 1238 |----------------------->| 1239 | | 1241 Figure 3: Flow diagram of a user joining a chat room 1243 F1: Alice constructs an SDP description that includes an MSRP media 1244 stream. She also indicates her support for the chatroom extensions 1245 defined in this document. She sends the INVITE request to the chat 1246 room server. 1248 INVITE sip:chatroom22@chat.example.com SIP/2.0 1249 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1250 Max-Forwards: 70 1251 From: Alice ;tag=9fxced76sl 1252 To: Chatroom 22 1253 Call-ID: 3848276298220188511@atlanta.example.com 1254 CSeq: 1 INVITE 1255 Contact: 1256 Content-Type: application/sdp 1257 Content-Length: 290 1259 v=0 1260 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 1261 s=- 1262 c=IN IP4 client.atlanta.example.com 1263 m=message 7654 TCP/MSRP * 1264 a=accept-types:message/cpim text/plain text/html 1265 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1266 a=chatroom:nickname private-messages 1268 F2: The chat room server accepts the session establishment. It 1269 includes the 'isfocus' and other relevant feature tags in the Contact 1270 header field of the response. The chat room server also builds an 1271 SDP answer that forces the reception of messages wrapped in Message/ 1272 CPIM wrappers. It also includes the 'chatroom' attribute with the 1273 allowed extensions. 1275 SIP/2.0 200 OK 1276 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1277 ;received=192.0.2.101 1278 From: Alice ;tag=9fxced76sl 1279 To: Chatroom 22 ;tag=8321234356 1280 Call-ID: 3848276298220188511@atlanta.example.com 1281 CSeq: 1 INVITE 1282 Contact: \ 1283 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \ 1284 ;automata;isfocus;message;event="conference" 1285 Content-Type: application/sdp 1286 Content-Length: 290 1288 v=0 1289 o=chat 2890844527 2890844527 IN IP4 chat.example.com 1290 s=- 1291 c=IN IP4 chat.example.com 1292 m=message 12763 TCP/MSRP * 1293 a=accept-types:message/cpim 1294 a=accept-wrapped-types:text/plain text/html * 1295 a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1296 a=chatroom:nickname private-messages 1298 F3: The session established is acknowledged (details not shown). 1300 9.2. Setting up a nickname 1302 Figure 4 shows an example of Alice setting up a nickname using the 1303 chat room as provider. Her first proposal is not accepted because 1304 that proposed nickname is already in use. Then, she makes a second 1305 proposal with a new nickname. This second proposal is accepted. 1307 Alice MSRP switch 1308 | | 1309 |F1: (MSRP) NICKNAME | 1310 |----------------------->| 1311 |F2: (MSRP) 425 | 1312 |<-----------------------| 1313 |F3: (MSRP) NICKNAME | 1314 |----------------------->| 1315 |F4: (MSRP) 200 | 1316 |<-----------------------| 1317 | | 1319 Figure 4: Flow diagram of a user setting up her nickname 1321 F1: Alice sends an MSRP NICKNAME request that contains her proposed 1322 nicknames in the Use-Nickname header field. 1324 MSRP d93kswow NICKNAME 1325 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1326 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1327 Use-Nickname: "Alice the great" 1328 -------d93kswow$ 1330 F2: The MSRP switch analyzes the existing allocation of nicknames and 1331 detects that the nickname "Alice the great" is already provided to 1332 another participant in the chat room. The MSRP switch answers with a 1333 425 response. 1335 MSRP d93kswow 425 Nickname reserved or already in use 1336 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1337 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1338 -------d93kswow$ 1340 F3: Alice receives the response. She proposes a new nickname in a 1341 second NICKNAME request. 1343 MSRP 09swk2d NICKNAME 1344 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1345 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1346 Use-Nickname: "Alice in Wonderland" 1347 -------09swk2d$ 1349 F4: The MSRP switch accepts the nickname proposal and answers with a 1350 200 response. 1352 MSRP 09swk2d 200 OK 1353 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1354 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1355 -------09swk2d$ 1357 9.3. Sending a regular message to the chat room 1359 Figure 5 depicts a flow diagram where Alice is sending a regular 1360 message addressed to the chat room. The MSRP switch distributes the 1361 message to the rest of the participants. 1363 Alice MSRP switch Bob Charlie 1364 | | | | 1365 | F1: (MSRP) SEND | | | 1366 |--------------------->| F3: (MSRP) SEND | | 1367 | F2: (MSRP) 200 |----------------------->| | 1368 |<---------------------| F4: (MSRP) SEND | | 1369 | |------------------------------->| 1370 | | F5: (MSRP) 200 OK | | 1371 | |<-----------------------| | 1372 | | F6: (MSRP) 200 OK | | 1373 | |<------------------------------ | 1374 | | | | 1375 | | | | 1377 Figure 5: Sending a regular message to the chat room 1379 F1: Alice builds a text message and wraps it in a Message/CPIM 1380 wrapper. She addresses the message to the chat room. She encloses 1381 the resulting Message/CPIM wrapper in an MSRP SEND request and sends 1382 it to the MSRP switch via the existing TCP connection. 1384 MSRP 3490visdm SEND 1385 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1386 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1387 Message-ID: 99s9s2 1388 Byte-Range: 1-*/* 1389 Content-Type: message/cpim 1391 To: 1392 From: 1393 DateTime: 2009-03-02T15:02:31-03:00 1394 Content-Type: text/plain 1396 Hello guys, how are you today? 1397 -------3490visdm$ 1399 F2: The MSRP switch acknowledges the reception of the SEND request 1400 with a 200 (OK) response. 1402 MSRP 3490visdm 200 OK 1403 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1404 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1405 Message-ID: 99s9s2 1406 -------3490visdm$ 1408 F3: The MSRP switch creates a new MSRP SEND request that contains the 1409 received Message/CPIM wrapper and sends it to Bob. 1411 MSRP 490ej23 SEND 1412 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1413 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1414 Message-ID: 304sse2 1415 Byte-Range: 1-*/* 1416 Content-Type: message/cpim 1418 To: 1419 From: 1420 DateTime: 2009-03-02T15:02:31-03:00 1421 Content-Type: text/plain 1423 Hello guys, how are you today? 1424 -------490ej23$ 1426 Since the received message is addressed to the chat room URI in the 1427 From header of the Message/CPIM header, Bob knows that this is a 1428 regular message distributed all participants in the chat room, rather 1429 that a private message addressed to him. 1431 The rest of the message flows are analogous to the previous. They 1432 are not shown here. 1434 9.4. Sending a private message to a participant 1436 Figure 6 depicts a flow diagram where Alice is sending a private 1437 message addressed to Bob's SIP AOR. The MSRP switch distributes the 1438 message only to Bob. 1440 Alice MSRP switch Bob 1441 | | | 1442 | F1: (MSRP) SEND | | 1443 |--------------------->| F3: (MSRP) SEND | 1444 | F2: (MSRP) 200 |----------------------->| 1445 |<---------------------| F4: (MSRP) 200 | 1446 | |<-----------------------| 1447 | | | 1449 Figure 6: Sending a private message to Bob 1451 F1: Alice builds a text message and wraps it in a Message/CPIM 1452 wrapper. She addresses the message to Bob's URI, which she learned 1453 from a notification in the conference event package. She encloses 1454 the resulting Message/CPIM wrapper in an MSRP SEND request and sends 1455 it to the MSRP switch via the existing TCP connection. 1457 MSRP 6959ssdf SEND 1458 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1459 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1460 Message-ID: okj3kw 1461 Byte-Range: 1-*/* 1462 Content-Type: message/cpim 1464 To: 1465 From: 1466 DateTime: 2009-03-02T15:02:31-03:00 1467 Content-Type: text/plain 1469 Hello Bob. 1470 -------6959ssdf$ 1472 F2: The MSRP switch acknowledges the reception of the SEND request 1473 with a 200 (OK) response. 1475 MSRP 6959ssdfm 200 OK 1476 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1477 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1478 Message-ID: okj3kw 1479 -------6959ssdfm$ 1481 F3: The MSRP switch creates a new MSRP SEND request that contains the 1482 received Message/CPIM wrapper and sends it only to Bob. Bob can 1483 distinguish the sender in the From header of the Message/CPIM 1484 wrapper. He also identifies this as a private message due to the 1485 presence of his own SIP AOR in the To header field of the Message/ 1486 CPIM wrapper. 1488 MSRP 9v9s2 SEND 1489 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1490 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1491 Message-ID: d9fghe982 1492 Byte-Range: 1-*/* 1493 Content-Type: message/cpim 1495 To: 1496 From: 1497 DateTime: 2009-03-02T15:02:31-03:00 1498 Content-Type: text/plain 1500 Hello Bob. 1501 -------9v9s2$ 1503 F4: Bob acknowledges the reception of the SEND request with a 200 1504 (OK) response. 1506 MSRP 9v9s2 200 OK 1507 To-Path: msrp://chat.example.com:5678/jofofo3;tcp 1508 From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1509 Message-ID: d9fghe982 1510 -------9v9s2$ 1512 9.5. Chunked private message 1514 The MSRP message below depicts the example of the same private 1515 message described in Section 9.4, but now the message is split in two 1516 chunks. The MSRP switch must wait for the complete set of Message/ 1517 CPIM headers before distributing the messages. 1519 MSRP 7443ruls SEND 1520 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1521 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1522 Message-ID: aft4to 1523 Byte-Range: 1-*/174 1524 Content-Type: message/cpim 1526 To: 1527 From: 1528 -------7443ruls$ 1530 MSRP 7443ruls SEND 1531 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1532 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1533 Message-ID: aft4to 1534 Byte-Range: 68-174/174 1535 Content-Type: message/cpim 1537 DateTime: 2009-03-02T15:02:31-03:00 1538 Content-Type: text/plain 1540 Hello Bob 1541 -------7443ruls$ 1543 9.6. Nickname in a conference information document 1545 Figure 7 depicts an XML Conference Information Document received in a 1546 SIP NOTIFY request as a notification to the XCON Conference Event 1547 Package, RFC 6502 [RFC6502]. The Conference Information Document 1548 follows the XCON Data Model specified in RFC 6501 [RFC6501]. 1550 The Conference Information Document of Figure 7 presents information 1551 of two users who are participating in the conference (see each of the 1552 elements). Each participant is bound to a nickname, shown in 1553 the 'nickname' attribute of the element. 1555 NOTE: The purpose of Figure 7 is to show the user-to-nickname 1556 relation. It is believed that the example is correct, according 1557 to RFC 6501 [RFC6501]. In case of contradictions between this 1558 specification and RFC 6501 [RFC6501], the latter has precedence 1559 over this one. 1561 1562 1567 1570 1571 MSRP nickname example 1572 1573 1576 1577 2 1578 1579 1582 1583 1586 Bob Hoskins 1587 1588 1591 1594 Alice Kay 1595 1596 1598 1600 Figure 7: Nickname in a conference information document 1602 10. IANA Considerations 1604 10.1. New MSRP Method 1606 This specification defines a new MSRP method to be added to the 1607 Methods sub-registry of the Message Session Relay Protocol (MSRP) 1608 Parameters registry: 1610 NICKNAME 1612 See section Section 7 for details. 1614 10.2. New MSRP Header 1616 This specification defines a new MSRP header to be added to the 1617 Header Field sub-registry of the Message Session Relay Protocol 1618 (MSRP) Parameters registry: 1620 Use-Nickname 1622 See Section 7 for details. 1624 10.3. New MSRP Status Codes 1626 This specification defines three new MSRP status codes to be added to 1627 the Status-Code sub-registry of the Message Session Relay Protocol 1628 (MSRP) parameters registry. 1630 The 404 status code indicates the failure to resolve the recipient's 1631 URI in the To header field of the Message/CPIM wrapper in the SEND 1632 request, e.g, due to an unknown recipient. See Section 6.2 for 1633 details. 1635 The 424 status code indicates a failure in allocating the requested 1636 nickname due to a malformed syntax in the Use-Nickname header field. 1637 See Section 7 for details. 1639 The 425 status code indicates a failure in allocating the requested 1640 nickname because the requested nickname in the Use-Nickname header 1641 field is reserved or is already in use by another user. See 1642 Section 7 for details. 1644 The 428 status code indicates that the recipient of a SEND request 1645 does not support private messages. See Section 6.2 for details. 1647 Table 1 summarizes the IANA registration data with respect to new 1648 MSRP status codes: 1650 +-------+-------------------------------------+-----------+ 1651 | Value | Description | Reference | 1652 +-------+-------------------------------------+-----------+ 1653 | 404 | Failure to resolve recipient's URI | RFC XXXX | 1654 | 424 | Malformed nickname | RFC XXXX | 1655 | 425 | Nickname reserved or already in use | RFC XXXX | 1656 | 428 | Private messages not supported | RFC XXXX | 1657 +-------+-------------------------------------+-----------+ 1659 Table 1: New status codes 1661 10.4. New SDP Attribute 1663 This specification defines a new media-level attribute in the Session 1664 Description Protocol (SDP) Parameters registry. The registration 1665 data is as follows: 1667 Contact: Miguel Garcia 1669 Phone: +34 91 339 1000 1671 Attribute name: chatroom 1673 Long-form attribute name: Chat Room 1675 Type of attribute: media level only 1677 This attribute is not subject to the charset attribute 1679 Description: This attribute identifies support and local policy 1680 allowance for a number of chat room related functions 1682 Specification: RFC XXXX 1684 See section Section 8 for details. 1686 11. Security Considerations 1688 This document proposes extensions to the Message Session Relay 1689 Protocol [RFC4975]. Therefore, the security considerations of that 1690 document apply to this document as well. 1692 A chat room is by its nature a potential Denial-of-Service (DoS) 1693 accellerator as it takes a message from one entity and sends that to 1694 many. Implementers of both UAs and switches need to carefully 1695 consider the set of anti-DoS measures that are appropriate for this 1696 application and switch implementations in particular ought to include 1697 appropriate anti-DoS features. The details of what is appropriate 1698 will vary over time and will also depend on the specific needs of the 1699 implementation and so cannot be specified here. 1701 If the participant's SIP user agent does not understand the "isfocus" 1702 feature tag [RFC3840], it will not know that it is connected to a 1703 conference instance. The participant might not be notified that the 1704 participant's MSRP client will try to send messages to the MSRP 1705 switch having potentially multiple recipients. If the participant's 1706 MSRP client does not support the extensions of this specification, it 1707 is unlikely that it will try to send a message using 'Message/CPIM' 1708 wrapper content type [RFC3862], and the MSRP switch will reject the 1709 request with a 415 response [RFC4975]. Still if a participant's MSRP 1710 client does create a message with a valid 'Message/CPIM' wrapper 1711 content type [RFC3862] having the To header set to the URI of the 1712 chat room and the From header set to the URI of which the participant 1713 is known to the chat room, the participant might be unaware that the 1714 message can be forwarded to multiple recipients. Equally if the To 1715 header is set to a valid URI of a recipient known to the chat room, 1716 the message can be forwarded as a private message without the 1717 participant knowing. 1719 To mitigate these problems, when the chat room detects that a user 1720 agent does not support the procedures of this document (i.e., when 1721 the SIP User Agent is not chat room aware), the MSRP switch SHOULD 1722 send a regular MSRP message indicating that the SIP User Agent is 1723 actually part of a chat room, and that all the messages that the user 1724 sends correctly formated will be distributed to a number of 1725 participants. Additionally, the MSRP switch SHOULD also send a 1726 regular MSRP text message including the list of participants in the 1727 chat room, so that the user becomes aware of the roster. 1729 If a participant wants to avoid security concerns on the path between 1730 himself and the MSRP switch (e.g., being eavesdropped, faked packet 1731 injection, or packet corruption), the participant's user agent can 1732 force the usage of MSRP over a TLS [RFC5246] transport connection. 1733 This is negotiated in the SDP offer/answer exchange as per regular 1734 RFC 4975 [RFC4975] procedures. This negotiation will result in both 1735 endpoints establishing a TLS [RFC5246] transport connection that is 1736 used to exchange MSRP messages. The MSRP switch may also have local 1737 policy that forces the usage of TLS transport for all MSRP sessions, 1738 something that is also negotiated in SDP as per regular RFC 4975 1739 [RFC4975] procedures. 1741 Nicknames are used to show the appearance of the participants of the 1742 chat room. A successful take over of a nickname from a participant 1743 might lead to private messages to be sent to the wrong destination. 1744 The recipient's URI will be different from the URI associated to the 1745 original owner of the nickname, but the sender might not notice this. 1746 To avoid takeovers the MSRP switch MUST make sure that a nickname is 1747 unique inside a chat room. Also the security consideration for any 1748 authenticated identity mechanisms used to validate the SIP AOR will 1749 apply to this document as well. The chat room has a policy that 1750 determines the time that a nickname is still reserved to its holder, 1751 once it is no longer in used. This allows, e.g., a user that 1752 accidentally looses its connectivity, to re-connect to the chat room 1753 and keep on using the same nickname. It is up to the policy of the 1754 chat room to determine if a nickname that has been previously used by 1755 another participant of the chat room can be reserved or not. 1757 Section 7.1 discusses the problem of similar but different nicknames 1758 (e.g., thanks to the use of similar characters), and chat rooms MAY 1759 provide a mechanism to mitigate confusable nicknames. 1761 Recipients of instant messages should be cautious with the rendering 1762 of content, which can be malicious in nature. This includes, but it 1763 is not only restricted to, the reception of HTML and Javascript 1764 scripts, executable code, phishing attempts, etc. Endpoints SHOULD 1765 always request permission from the user before executing one of these 1766 actions. 1768 It must be noted that endpoints using TLS client side certificate 1769 with real names in the certificates will not be anonymous to the MSRP 1770 switch they connect to. While the name in the certificate might not 1771 be used by MSRP, the server will have a certificate with the actual 1772 name in it. 1774 12. Contributors 1776 This work would have never been possible without the fruitful 1777 discussions in the SIMPLE WG mailing list, specially with Brian Rosen 1778 (Neustar) and Paul Kyzivat (Huawei), who provided extensive review 1779 and improvements throughout the document. 1781 13. Acknowledgments 1783 The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, 1784 Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrian 1785 Georgescu, Nancy Greene, Cullen Jennings, Flemming Andreasen, Suresh 1786 Krishnan, Christer Holmberg, Saul Ibarra, Enrico Marocco, Alexey 1787 Melnikov, Peter Saint-Andre, Stephen Farrel, and Martin Stiemerling 1788 for providing comments. 1790 14. References 1792 14.1. Normative References 1794 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1795 Requirement Levels", BCP 14, RFC 2119, March 1997. 1797 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1798 A., Peterson, J., Sparks, R., Handley, M., and E. 1799 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1800 June 2002. 1802 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1803 with Session Description Protocol (SDP)", RFC 3264, 1804 June 2002. 1806 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1807 Initiation Protocol (SIP)", RFC 3323, November 2002. 1809 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1810 10646", STD 63, RFC 3629, November 2003. 1812 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1813 "Indicating User Agent Capabilities in the Session 1814 Initiation Protocol (SIP)", RFC 3840, August 2004. 1816 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1817 (CPIM)", RFC 3860, August 2004. 1819 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1820 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1822 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1823 Session Initiation Protocol (SIP)", RFC 4353, 1824 February 2006. 1826 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1827 Description Protocol", RFC 4566, July 2006. 1829 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1830 Initiation Protocol (SIP) Event Package for Conference 1831 State", RFC 4575, August 2006. 1833 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1834 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1836 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1837 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1838 September 2007. 1840 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1841 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1843 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 1844 Centralized Conferencing", RFC 5239, June 2008. 1846 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1847 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1849 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1850 Control", RFC 5681, September 2009. 1852 [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 1853 "Conference Information Data Model for Centralized 1854 Conferencing (XCON)", RFC 6501, March 2012. 1856 [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. 1857 Urpalainen, "Conference Event Package Data Format 1858 Extension for Centralized Conferencing (XCON)", RFC 6502, 1859 March 2012. 1861 [I-D.ietf-precis-nickname] 1862 Saint-Andre, P., "Preparation and Comparison of 1863 Nicknames", draft-ietf-precis-nickname-05 (work in 1864 progress), November 2012. 1866 14.2. Informative References 1868 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1869 April 2000. 1871 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1872 Extensions to the Session Initiation Protocol (SIP) for 1873 Asserted Identity within Trusted Networks", RFC 3325, 1874 November 2002. 1876 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1877 RFC 3966, December 2004. 1879 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1880 Authenticated Identity Management in the Session 1881 Initiation Protocol (SIP)", RFC 4474, August 2006. 1883 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1884 Protocol (XMPP): Core", RFC 6120, March 2011. 1886 Authors' Addresses 1888 Aki Niemi 1890 Email: aki.niemi@iki.fi 1892 Miguel A. Garcia-Martin 1893 Ericsson 1894 Calle Via de los Poblados 13 1895 Madrid, ES 28033 1896 Spain 1898 Email: miguel.a.garcia@ericsson.com 1900 Geir A. Sandbakken 1901 Cisco Systems 1902 Philip Pedersens vei 20 1903 N-1366 Lysaker 1904 Norway 1906 Phone: +47 67 125 125 1907 Email: geirsand@cisco.com 1908 URI: http://www.cisco.com