idnits 2.17.1 draft-ietf-simple-chat-16.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 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 (August 16, 2012) is 4271 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-00 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 3 errors (**), 0 flaws (~~), 3 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 Nokia 4 Intended status: Standards Track M. Garcia-Martin 5 Expires: February 17, 2013 Ericsson 6 G. Sandbakken, Ed. 7 Cisco Systems 8 August 16, 2012 10 Multi-party Chat Using the Message Session Relay Protocol (MSRP) 11 draft-ietf-simple-chat-16 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 February 17, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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 5. Creating, Joining, and Deleting a Chat Room . . . . . . . . . 10 73 5.1. Creating a Chat Room . . . . . . . . . . . . . . . . . . . 10 74 5.2. Joining a Chat Room . . . . . . . . . . . . . . . . . . . 10 75 5.3. Deleting a Chat Room . . . . . . . . . . . . . . . . . . . 11 76 6. Sending and Receiving Instant Messages . . . . . . . . . . . . 12 77 6.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 12 78 6.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 14 79 6.3. MSRP reports and responses . . . . . . . . . . . . . . . . 15 80 6.4. Congestion Avoidance . . . . . . . . . . . . . . . . . . . 16 81 7. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 7.1. Using Nicknames within a Chat Room . . . . . . . . . . . . 18 83 7.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 20 84 7.3. Removing a Nickname . . . . . . . . . . . . . . . . . . . 20 85 7.4. Nicknames in Conference Event Packages . . . . . . . . . . 20 86 8. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . . . 21 87 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 23 89 9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 25 90 9.3. Sending a regular message to the chat room . . . . . . . . 26 91 9.4. Sending a private message to a participant . . . . . . . . 28 92 9.5. Chunked private message . . . . . . . . . . . . . . . . . 29 93 9.6. Nickname in a conference information document . . . . . . 30 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 95 10.1. New MSRP Method . . . . . . . . . . . . . . . . . . . . . 31 96 10.2. New MSRP Header . . . . . . . . . . . . . . . . . . . . . 32 97 10.3. New MSRP Status Codes . . . . . . . . . . . . . . . . . . 32 98 10.4. New SDP Attribute . . . . . . . . . . . . . . . . . . . . 33 99 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 100 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 101 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 103 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 104 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 107 1. Introduction 109 The Message Session Relay Protocol (MSRP) [RFC4975] defines a 110 mechanism for sending a series of instant messages within a session. 111 The Session Initiation Protocol (SIP) [RFC3261] in combination with 112 the Session Description Protocol (SDP) [RFC4566] allows for two peers 113 to establish and manage such sessions. 115 In another application of SIP, a user agent can join in a multi-party 116 conversation called a conference that is hosted by a specialized user 117 agent called a focus [RFC4353]. Such a conference can naturally 118 involve MSRP sessions. It is the responsibility of an entity 119 handling the media to relay instant messages received from one 120 participant to the rest of the participants in the conference. 122 Several such systems already exist in the Internet. Participants in 123 a chat room can be identified with a pseudonym or nickname, and 124 decide whether their real identifier is disclosed to other 125 participants. Participants can also use a rich set of features such 126 as the ability to send private instant messages to other 127 participants. 129 Similar conferences supporting chat rooms are already available 130 today. For example, Internet Relay Chat (IRC) [RFC2810], Extensible 131 Messaging and Presence Protocol (XMPP): Core [RFC6120] based chat 132 rooms, and many other proprietary systems provide chat room 133 functionality. Specifying equivalent functionality for MSRP-based 134 systems provides competitive features and enables interworking 135 between the 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 155 [RFC2119], and indicate requirement levels for compliant 156 implementations. 158 This memo deals with tightly coupled SIP conferences defined in SIP 159 Conferencing Framework [RFC4353] and adopts the terminology from that 160 document. In addition to that terminology, we introduce some new 161 terms: 163 Nickname: a pseudonym or descriptive name associated to a 164 participant. See Section 7 for details 166 Multi-party chat: an instance of a tightly coupled conference, in 167 which the media exchanged between the participants consist of MSRP 168 based instant messages. Also known as a chat room. 170 Chat Room: a synonym for a multi-party chat. 172 Chat Room URI: a URI that identifies a particular chat room, and is 173 a synonym of a Conference URI defined in RFC 4353 [RFC4353]. 175 Sender: the chat room participant who originally created an instant 176 message and sent it to the chat room server for further delivery. 178 Recipient: the destination chat room participant(s). This defaults 179 to the full conference participant list minus the IM Sender. 181 MSRP switch: a media level entity that is a MSRP endpoint. It is a 182 special MSRP endpoint that receives MSRP messages and delivers 183 them to the other chat room participants. The MSRP switch has a 184 similar role to a conference mixer with the exception that the 185 MSRP switch does not actually "mix" together different input media 186 streams; it merely relays the messages between chat room 187 participants. 189 Private Instant Message: an instant message sent in a chat room 190 intended for a single participant. A private IM is usually 191 rendered distinctly from the rest of the IMs, indicating that the 192 message was a private communication. 194 Anonymous URI: a URI concealing the participant's SIP AOR from the 195 other participants in the chat room. The allocation of such a URI 196 is out of scope of this specification. An anonymous URI must be 197 valid for the length of the chat room session and will be utilized 198 by the MSRP switch to forward messages to and from anonymous 199 participants. 201 Conference Event Package: a notification mechanism that allows 202 conference participants to learn conference information including 203 roster and state changes in a conference. This would typically be 204 A Session Initiation Protocol (SIP) Event Package for Conference 205 State [RFC4575] or Conference Event Package Data Format Extension 206 for Centralized Conferencing [RFC6502]. 208 3. Motivations and Requirements 210 Although conference frameworks describing many types of conferencing 211 applications already exist, such as the Framework for Centralized 212 Conferencing [RFC5239] and the SIP Conferencing Framework [RFC4353], 213 the exact details of session-based instant messaging conferences 214 (chat rooms) are not well-defined at the moment. 216 To allow interoperable chat implementations, for both conference- 217 aware, and conference-unaware user agents, certain conventions for 218 MSRP chat rooms need to be defined. It also seems beneficial to 219 provide a set of features that enhance the baseline multi-party MSRP 220 in order to be able to create systems that have functionality on par 221 with existing chat systems, as well as enable building interworking 222 gateways to these existing chat systems. 224 We define the following requirements: 226 REQ-1: A basic requirement is the existence of a chat room, where 227 participants can join and leave the chat room and get instant 228 messages exchanged to the rest of the participants. 230 REQ-2: A recipient of an instant message in a chat room must be able 231 to determine the identifier of the sender of the message. 232 Note that the actual identifier depends on the one which was 233 used by the sender when he or she joined the chat room. 235 REQ-3: A recipient of an instant message in a chat room must be able 236 to determine the identifier of the recipient of received 237 messages. For instance, the recipient of the message might 238 be the entire chat room or a single participant (i.e., a 239 private message). Note that the actual identifier may depend 240 on the one which was used by the recipient when he or she 241 joined the chat room. 243 REQ-4: It must be possible to send a message to a single participant 244 within the chat room (i.e., a private instant message). 246 REQ-5: A chat room participant may have a nickname or pseudonym 247 associated with their real identifier. 249 REQ-6: It must be possible for a participant to change their 250 nickname during the progress of the chat room session. 252 REQ-7: It must be possible that a participant is only known by an 253 anonymous identifier and not their real identifier to the 254 rest of the chat room. 256 REQ-8: It must be possible for chat room participants to learn the 257 chat room capabilities described in this document. 259 4. Overview of Operation 261 In order to enter a chat room, one must first be created. Users 262 wishing to host a chat room themselves can of course do just that; 263 their User Agent (UA) simply morphs from an ordinary UA into a 264 special purpose one called a Focus UA. Another, commonly used setup 265 is one where a dedicated node in the network functions as a Focus UA. 267 Each chat room has an identifier of its own: a SIP URI that 268 participants use to join the chat room, e.g. by sending an INVITE 269 request to it. The conference focus processes the invitations, and 270 as such, maintains SIP dialogs with each participant. In a multi- 271 party chat, or chat room, MSRP is one of the established media 272 streams. Each chat room participant establishes an MSRP session with 273 the MSRP switch, which is a special purpose MSRP application. The 274 MSRP sessions can be relayed by one or more MSRP relays, which are 275 specified in RFC 4976 [RFC4976]. This is illustrated in Figure 1 276 MSRP Sessions 277 +---------------------------+ 278 | +-----------+ | 279 +---+--+ +---+--+ | | 280 | SIP | | SIP | | | 281 | MSRP | | MSRP | +--+---+----+ 282 |Client| |Client| | MSRP | 283 +---+--+ ++-----+ | Relay | 284 | | +-----+-----+ 285 SIP Dialogs | / | 286 | | | MSRP Sessions 287 +----+------+--+ | 288 | Conference | +-------+-----+ 289 | Focus UA | | MSRP | 290 | |........| Switch | 291 | | | | 292 +---+--------+-+ +-------+-----+ 293 | \ | 294 SIP Dialogs | | | MSRP Sessions 295 | \ | 296 +--+---+ +-+----+ +-----+------+ 297 | SIP | | SIP | | MSRP | 298 | MSRP | | MSRP | | Relay | 299 |Client| |Client| +-+-------+--+ 300 +---+--+ +--+---+ | | 301 | +-----------+ | 302 +------------------------------+ 303 MSRP sessions 305 Figure 1: Multi-party chat overview shown with MSRP Relays and a 306 conference Focus UA 308 The MSRP switch is similar to a conference mixer in that it handles 309 media sessions with each of the participants and bridges these 310 streams together. However, unlike a conference mixer, the MSRP 311 switch merely forwards messages between participants but doesn't 312 actually mix the streams in any way. The system is illustrated in 313 Figure 2. 315 +------+ 316 | MSRP | 317 |Client| 318 +------+ +--.---+ +------+ 319 | MSRP | | | MSRP | 320 |Client| | _|Client| 321 +------._ | ,' +------+ 322 `._ | ,' 323 `.. +----------+ ,' 324 `| |' 325 | MSRP | 326 | Switch | 327 ,| |_ 328 _,-'' +----------+ ``-._ 329 +------.-' | `--+------+ 330 | MSRP | | | MSRP | 331 |Client| | |Client| 332 +------+ | +------+ 333 +---'--+ 334 | MSRP | 335 |Client| 336 +------+ 338 Figure 2: Multi-party chat in a Centralized Chat Room 340 Typically chat room participants also subscribe to a conference event 341 package to gather information about the conference roster in the form 342 of conference state notifications. For example, participants can 343 learn about other participants' identifiers, including their 344 nicknames. 346 All messages in the chat room use the 'Message/CPIM' wrapper content 347 type [RFC3862], so that it is possible to distinguish between private 348 and regular messages. When a participant wants to send an instant 349 message to the chat room, it constructs an MSRP SEND request and 350 submits it to the MSRP switch including a regular payload (e.g. a 351 Message/CPIM message that contains a text, HTML, an image, etc.). 352 The Message/CPIM To header is set to the chat room URI. The switch 353 then fans out the SEND request to all of the other participants using 354 their existing MSRP sessions. 356 A participant can also send a private instant message addressed to a 357 participant whose identifier has been learned, e.g. via a conference 358 event package. In this case the sender creates an MSRP SEND request 359 with a Message/CPIM wrapper whose To header contains not the chat 360 room URI but the recipient's URI. The MSRP switch then forwards the 361 SEND request to that recipient. This specification supports the 362 sending of private messages to one and only one recipient. However, 363 if the recipient is logged from different endpoints, the MSRP switch 364 will distribute the private message to each endpoint the recipient is 365 logged. 367 We extend the current MSRP negotiation that takes place in SDP 368 [RFC4566] to allow participants to learn whether the chat room 369 supports and is willing to accept (e.g. due to local policy 370 restrictions) certain MSRP functions defined in this memo, such as 371 nicknames or private messaging. 373 Naturally, when a participant wishes to leave a chat room, it sends a 374 SIP BYE request to the Focus UA and terminates the SIP dialog with 375 the focus and MSRP sessions with the MSRP switch. 377 This document assumes that each chat room is allocated its own SIP 378 URI. A user joining a chat room sends an INVITE request to that SIP 379 URI, and as a result, a new MSRP session is established between the 380 user and the MSRP switch. It is assumed that an MSRP session is 381 mapped to a chat room. If a user wants to join a second chat room, 382 he creates a different INVITE request, through a different SIP 383 dialog, which leads to the creation of a second MSRP session between 384 the user and the MSRP switch. Notice that these two MSRP sessions 385 can still be multiplexed over the same TCP connection as per regular 386 MSRP procedures. However, each chat room is associated to a unique 387 MSRP session and a unique SIP dialog. 389 5. Creating, Joining, and Deleting a Chat Room 391 5.1. Creating a Chat Room 393 Since we consider a chat room a particular type of conference having 394 MSRP media, the methods defined by the SIP Conference Framework 395 [RFC4353] for creating conferences are directly applicable to a chat 396 room. 398 Once a chat room is created, it is identified by a SIP URI, like any 399 other conference. 401 5.2. Joining a Chat Room 403 Participants usually join the chat room by sending an INVITE request 404 to the chat room URI. As long as the chat room policy allows, the 405 INVITE request is accepted by the focus and the user is brought into 406 the actual chat room. 408 The MSRP switch needs to be aware of the URIs of the participant 409 (SIP, Tel, or IM URIs) in order to validate messages sent from this 410 participant prior to their forwarding. This information is known to 411 the focus of the conference. Therefore an interface between the 412 focus and the MSRP switch is assumed. However, the interface between 413 the focus and the MSRP switch is outside the scope of this document. 415 Conference-aware participants will detect that the peer is a focus 416 due to the presence of the "isfocus" feature tag [RFC3840] in the 417 Contact header field of the 200-class response to the INVITE request. 418 Conference-unaware participants will not notice it is a focus, and 419 can not apply the additional mechanisms defined in this document. 420 Participants are also aware that the mixer is an MSRP switch due to 421 the presence of a 'message' media type and either TCP/MSRP or TCP/ 422 TLS/MSRP as the protocol field in the media line of SDP [RFC4566]. 424 The conference focus of a chat room MUST include support for a 425 Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by 426 setting the 'accept-types' MSRP media line attribute in the SDP offer 427 or answer [RFC3264] to include 'Message/CPIM'. 429 Note that the 'Message/CPIM' wrapper is used to carry the sender 430 information that, otherwise, it will not be available to the 431 recipient. Additionally, 'Message/CPIM' wrapper carries the 432 recipient information (e.g. To and Cc: headers). 434 If a participant wants to remain anonymous to the rest of the 435 participants in the chat room, the participant's UA must provide an 436 anonymous URI to the conference focus. The URI will be used in the 437 From and To headers in the 'Message/CPIM' wrapper, and can be learned 438 by the other participants of the chat room. Notice that in order for 439 the anonymity mechanism to work, the anonymous URI must not reveal 440 the participant's SIP AOR. The mechanism for acquiring an anonymous 441 URI is outside the scope of this specification. 443 The conference focus of a chat room MUST learn the chat room 444 capabilities of each participant that joins the chat room. The 445 conference focus MUST inform the MSRP switch of such support in order 446 to prevent the MSRP switch from distributing private messages to 447 participants who do not support private messaging. The recipient 448 would not be able to render the message as private, and any potential 449 reply would be sent to the whole chat room. 451 5.3. Deleting a Chat Room 453 As with creating a conference, the methods defined by the SIP 454 Conference Framework [RFC4353] for deleting a conference are directly 455 applicable to a chat room. The MSRP switch will terminate the MSRP 456 sessions with all the participants. 458 Deleting a chat room is an action that heavily depends on the policy 459 of the chat room. The policy can determine that the chat room is 460 deleted when the creator leaves the chat room, or with any out of 461 band mechanism. 463 6. Sending and Receiving Instant Messages 465 6.1. Regular Messages 467 This section describes the conventions used to send and receive 468 instant messages that are addressed to all the participants in the 469 chat room. These are sent over a regular MSRP SEND request that 470 contains a Message/CPIM wrapper [RFC3862] that in turn contains the 471 desired payload (e.g. text, image, video-clip, etc.). 473 When a chat room participant wishes to send an instant message to all 474 the other participants in the chat room, it constructs an MSRP SEND 475 request according to the procedures specified in RFC 4975 [RFC4975]. 476 The sender MAY choose the desired MSRP report model (e.g., populate 477 the Success-Report and Failure-Report MSRP header fields). 479 The SEND request MUST contain a top-level wrapper of type 'Message/ 480 CPIM' according to RFC 3862 [RFC3862]. The actual instant message 481 payload MUST be included as payload of the 'Message/CPIM' wrapper and 482 MAY be of any type negotiated in the SDP 'accept-types' attribute 483 according to the MSRP rules. 485 On sending a regular message the sender MUST populate the To header 486 of the Message/CPIM wrapper with the URI of the chat room. The 487 sender SHOULD populate the From header of the Message/CPIM wrapper 488 with a proper identifier by which the user is recognized in the chat 489 room. Identifiers that can be used (among others) are: 491 o A SIP URI [RFC3261] representing the participant's address-of- 492 record 494 o A tel URI [RFC3966] representing the participant's telephone 495 number 497 o An IM URI [RFC3860] representing the participant's instant 498 messaging address 500 o An Anonymous URI representing the participant's anonymous address 502 An MSRP switch that receives a SEND request from a participant SHOULD 503 first verify that the From header field of the Message/CPIM wrapper 504 is correctly populated with a valid URI of a participant. This 505 imposes a requirement for the focus of the conference to inform the 506 MSRP switch of the URIs by which the participant is known, in order 507 for the MSRP switch to validate messages. Section 6.3 provides 508 further information with the actions to be taken in case this 509 validation fails. 511 Then the MSRP switch should inspect the To header field of the 512 Message/CPIM wrapper. If the MSRP switch receives a message 513 containing several To header fields in the Message/CPIM wrapper the 514 MSRP switch MUST reject the MSRP SEND request with a 403 response, as 515 per procedures in RFC 4975 [RFC4975]. Then, if the To header field 516 of the Message/CPIM wrapper contains the chat room URI and there are 517 no other To header fields, the MSRP switch can generate a copy of the 518 SEND request to each of the participants in the chat room except the 519 sender. The MSRP switch MUST NOT modify the content received in the 520 SEND request. However, the MSRP switch MAY re-chunk any of the 521 outbound MSRP SEND requests. 523 Note that the MSRP switch does not need to wait for the reception of 524 the complete MSRP chunk or MSRP message before it starts the 525 distribution to the rest of the participants. Instead, once the MSRP 526 switch has received the headers of the Message/CPIM wrapper it SHOULD 527 start the distribution process. 529 When forwarding chunked messages as soon as they are received, the 530 Message/CPIM wrapper is only present at the beginning of the message, 531 typically within the first chunk. Subsequent chunks will contain the 532 rest of the message, but not the Message/CPIM headers. Therefore, an 533 MSRP switch that receives a subsequent message may face challenges in 534 determining the correct list of recipients of the message. An MSRP 535 switch that uses this fast forwarding procedure MUST temporarily 536 store the Message-Id of the MSRP message to correlate the different 537 chunks, as well as it MUST temporarily store the list of recipients 538 to which the initial chunks were delivered. The MSRP switch SHOULD 539 forward subsequent chunks only to those recipients who were sent the 540 initial chunks, except if the MSRP switch has knowledge that one of 541 the recipients of the initial chunks has dropped from the chat room. 542 This behavior also avoids new participants who joined the chat room 543 when the first chunk has been distributed to receive subsequent 544 chunks that would otherwise need to be discarded. 546 An MSRP endpoint that receives a SEND request from the MSRP switch 547 containing a Message/CPIM wrapper SHOULD first inspect the To header 548 field of the Message/CPIM wrapper. If the To header field is set to 549 the chat room URI, it should render it as a regular message that has 550 been distributed to all the participants in the chat room. Then the 551 MSRP endpoint SHOULD inspect the From header field of the Message/ 552 CPIM wrapper to identify the sender. The From header field will 553 include a URI that identifies the sender. The endpoint might have 554 also received further identifier information through a subscription 555 to a conference event package. 557 6.2. Private Messages 559 This section describes the conventions used to send and receive 560 private instant messages, i.e., instant messages that are addressed 561 to one participant of the chat room rather to all of them. A chat 562 room can signal support for private messages using the 'chatroom' 563 attribute in SDP (see Section 8 for details). 565 When a chat room participant wishes to send a private instant message 566 to a participant in the chat room, it follows the same procedures for 567 creating a SEND request as for regular messages (Section 6.1). The 568 only difference is that the MSRP endpoint MUST populate a single To 569 header of the Message/CPIM wrapper with the identifier of the 570 intended recipient. The identifier can be SIP, TEL, and IM URIs 571 typically learned from the information received in notifications of a 572 conference event package. 574 As for regular messages, an MSRP switch that receives a SEND request 575 from a participant SHOULD first verify that the From header field of 576 the Message/CPIM wrapper is correctly populated with a valid URI 577 (i.e., the URI is a participant of this chat room). Section 6.3 578 provides further information with the actions to be taken in case 579 this validation fails. 581 Then the MSRP switch MUST inspect the To header field of the Message/ 582 CPIM wrapper. If the MSRP switch receives a message containing 583 several To header fields in the Message/CPIM wrapper the MSRP switch 584 MUST reject the MSRP SEND request with a 403 response, as per 585 procedures in RFC 4975 [RFC4975]. Then the MSRP switch MUST verify 586 that the To header of the Message/CPIM wrapper matches the URI of a 587 participant of the chat room. If this To header field does not 588 contain the URI of a participant of the chat room or if the To header 589 field cannot be resolved (e.g., caused by a mistyped URI), the MSRP 590 switch MUST reject the request with a 404 response. This new 404 591 status code indicates a failure to resolve the recipient URI in the 592 To header field of the Message/CPIM wrapper. 594 Notice the importance of the From and To headers in the Message/ 595 CPIM wrapper. If an intermediary modifies these values, the MSRP 596 switch might not be able to identify the source or intended 597 destination of the message, resulting in a rejection of the 598 message. 600 Finally, the MSRP switch MUST verify that the recipient supports 601 private messages. If the recipient does not support private 602 messages, the MSRP switch MUST reject the request with a 428 603 response. This new response 428 indicates that the recipient does 604 not support private messages. Any potential REPORT request that the 605 MSRP switch sends to the sender MUST include a Message/CPIM wrapper 606 containing the original From header field included in the SEND 607 request and the To header field of the original Message/CPIM wrapper. 608 The MSRP switch MUST NOT forward private messages to a recipient that 609 does not support private messaging. 611 If successful, the MSRP switch should search its mapping table to 612 find the MSRP sessions established towards the recipient. If a match 613 is found the MSRP switch MUST create a SEND request and MUST copy the 614 contents of the sender's message to it. 616 An MSRP endpoint that receives a SEND request from the MSRP switch 617 does the same validations as for regular messages (Section 6.1). If 618 the To header field is different from the chat room URI, the MSRP 619 endpoints knows that this is a private message. The endpoint should 620 render who it is from based on the value of the From header of the 621 Message/CPIM wrapper. The endpoint can also use the sender's 622 nickname, possibly learned via a conference event package, to render 623 such nickname rather than the sender's actual URI. 625 It is possible that a participant, identified by a SIP Address of 626 Record or other valid URI, joins a chat room from two or more 627 different SIP UAs. It is RECOMMENDED that the MSRP switch can map a 628 URI to two or more MSRP sessions. If the policy of the server allows 629 for this, the MSRP switch MUST copy all messages intended to the 630 recipient through each MSRP session mapped to the recipient's URI. 632 6.3. MSRP reports and responses 634 This section discusses the common procedures for regular and private 635 messages with respect to MSRP reports and responses. Any particular 636 procedure affecting only regular messages or only private messages is 637 discussed in the previous Section 6.1 or Section 6.2, respectively. 639 MSRP switches MUST follow the success report and failure report 640 handling described in section 7 of RFC 4975 [RFC4975], complemented 641 with the procedures described in this section. The MSRP switch MUST 642 act as an MSRP endpoint receiver of the request according to section 643 5.3 of RFC 4975 [RFC4975]. 645 If the MSRP switch receives an MSRP SEND request that does not 646 contain a Message/CPIM wrapper, the MSRP switch MUST reject the 647 request with a 415 response (specified in RFC 4975 [RFC4975]). 649 If the MSRP switch receives an MSRP SEND request where the URI 650 included in the From header field of the Message/CPIM wrapper is not 651 valid, (e.g, because it does not "belong" to the sender of the 652 message or is not a valid participant of the chat room), the MSRP 653 switch MUST reject the request with a 403 response. In non-error 654 cases, the MSRP switch MUST construct responses according to section 655 7.2 of RFC 4975 [RFC4975]. 657 When the MSRP switch forwards a SEND request, it MAY use any report 658 model in the copies intended for the recipients. The receiver 659 reports from the recipients MUST NOT be forwarded to the originator 660 of the original SEND request. This could lead to having the sender 661 receiving multiple reports for a single MSRP request. 663 6.4. Congestion Avoidance 665 Congestion can occur when multiple heterogeneous interfaces are used 666 by a diversity of users who are participating in a chat room. Some 667 of these users might have fast path capable of high throughputs while 668 other users might be slow paths with constrained throughputs. It is 669 therefore possible that a subset of the participants of the chat room 670 are able to send and receive messages at a high rate or with large 671 contents (e.g., pictures), whereas others are not able to keep the 672 pace. 674 Additionally, since MSRP uses a connection-oriented transport 675 protocol such as TCP, it is expected that the TCP congestion 676 avoidance mechanisms will also be activated should congestion occur. 678 While this document does not mandate a particular MSRP-specific 679 mechanism to avoid congestion in any of the paths, something that is 680 deemed outside the scope of this document, this document provides 681 some recommendations for implementors to consider. 683 It is RECOMMENDED that MSRP switches implement one or more MSRP- 684 specific strategies to detect and avoid congestion. Possible 685 strategies (but definitely not a comprehensive list) include: 687 o If the MSRP switch is writing data to a send buffer and detects 688 that the send buffer associated to that TCP connection is getting 689 full (e.g., close to 80% of its capacity), the MSRP switch marks 690 the associated MSRP sessions making use of that TCP connection as 691 "congested". 693 o Prior to sending a new MSRP message to a user, the MSRP switch 694 verifies the congested flag associated to that MSRP session. If 695 the MSRP session is marked as congested, the MSRP switch can apply 696 a congestion avoidance mechanism, such as: 698 o 700 * The MSRP switch can discard regular MSRP messages sent to that 701 user while the TCP send buffer is congested. In order to 702 inform the user of the congestion, the MSRP switch can send a 703 regular MSRP message indicating the user that some messages are 704 discarded due to network congestion. 706 * The MSRP can implement a temporary policy to disallow the 707 distribution of messages larger than a certain size to MSRP 708 sessions marked as congested. Similarly, the user should be 709 informed of this fact by the MSRP switch sending a regular MSRP 710 message indicating this condition. 712 7. Nicknames 714 A common characteristic of existing chat room services is that 715 participants have the ability to present themselves with a nickname 716 to the rest of the participants of the chat room. It is used for 717 easy reference of participants in the chat room, and can also provide 718 anonymous participants with a meaningful descriptive name. 720 A nickname is a useful construct in many use cases, of which MSRP 721 chat is but one example. It is associated with a URI of which the 722 participant is known to the focus. Therefore, if a user joins the 723 chat room under the same URI from multiple devices, he or she may 724 request the same nickname across all these devices. 726 A nickname is a user selectable appearance of which the participant 727 wants to be known to the other participants. It is not a 'display- 728 name', but it is used somewhat like a display name. A main 729 difference is that a nickname is unique inside a chat room to allow 730 an unambiguous reference to a participant in the chat. Nicknames may 731 be long lived, or may be temporary. Users also need to reserve a 732 nickname prior to its utilization. 734 This memo specifies the nickname as a string. The nickname string 735 MUST be unambiguous within the scope of the chat room (conference 736 instance). This scope is similar to having a nickname unique inside 737 a chat room from Extensible Messaging and Presence Protocol 738 [RFC6120]. The chat room may have policies associated with 739 nicknames. It may not accept nickname strings at all, or a it may 740 provide a wider unambiguous scope like a domain or server, similar to 741 Internet Relay Chat (IRC) [RFC2810]. 743 7.1. Using Nicknames within a Chat Room 745 This memo provides a mechanism to reserve a nickname for a 746 participant for as long as the participant is logged into the chat 747 room. The mechanism is based on a NICKNAME MSRP method (see below) 748 and a new "Use-Nickname" header. Note that other mechanisms may 749 exist (for example, a web page reservation system), although they are 750 outside the scope of this document. 752 A chat room participant who has established an MSRP session with the 753 MSRP switch, where the MSRP switch has indicated the support and 754 availability of nicknames with the 'nicknames' token in the 755 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP 756 switch. The NICKNAME request MUST include a new Use-Nickname header 757 that contains the nickname string that the participant wants to 758 reserve. MSRP NICKNAME requests MUST NOT include Success-Report or 759 Failure-Report header fields. 761 An MSRP switch that receives a NICKNAME request containing a 762 Use-Nickname header field SHOULD first verify whether the policy of 763 the chat room allows the nickname functionality. If not allowed, the 764 MSRP switch MUST reject the request with a 403 response, as per RFC 765 4975 [RFC4975]. 767 If the policy of the chat room allows the usage of nicknames, any new 768 nickname requested MUST be prepared and compared with nicknames 769 already in use or reserved following the rules defined in Preparation 770 and Comparison of Nicknames [I-D.ietf-precis-nickname]. 772 This mitigates the problem of nickname duplication, but it does not 773 solve a problem whereby users can choose similar (but different) 774 characters to represent two different nicknames. For example, "BOY" 775 and "B0Y" are different nicknames which can mislead users. The 776 former uses the capital letter "O" while the latter uses the number 777 zero "0". In many fonts the letter "O" and the number zero "0" might 778 be quite similar, and difficult to be perceived as different 779 characters. Chat rooms MAY provide a mechanism to mitigate 780 confusable nicknames. 782 In addition to preparing and comparing following the rules above, the 783 MSRP switch SHOULD validate that the SIP AOR identifying the user is 784 entitled to reserve the nickname. This may include, e.g., allowing 785 that the participant's URI may use the same nickname when the 786 participant has joined the chat room from different devices under the 787 same URI. The participant's authenticated identifier can be derived 788 after a successful SIP Digest Authentication [RFC3261], be included 789 in a trusted SIP P-Asserted-Identity header field [RFC3325], be 790 included in a valid SIP Identity header field [RFC4474], or be 791 derived from any other present or future SIP authentication 792 mechanism. Once the MSRP switch has validated that the participant 793 is entitled to reserve the requested nickname, the MSRP switch 794 verifies if the suggested nickname can be accepted (see below). 796 The reservation of a nickname can fail in several cases. If the 797 NICKNAME request contains a malformed value in the Use-Nickname 798 header field, the MSRP switch MUST answer the NICKNAME request with a 799 424 response code. This can be the case when the value of the 800 Use-Nickname header field does not conform to the syntax. 802 The reservation of a nickname can also fail if the value of the 803 Use-Nickname header field of the NICKNAME request is a reserved word 804 (not to be used as a nickname by any user) or that particular value 805 is already in use by another user. In this case the MSRP switch MUST 806 answer the NICKNAME request with a 425 response code. 808 In both error conditions (receiving a 424 or 425 respose code), the 809 nickname usage is considered failed; the nickname is not allocated to 810 this user. The user can select a different nickname and retry 811 another NICKNAME request. 813 If the MSRP switch is able to accept the suggested nickname to be 814 used by this user, the MSRP switch MUST answer the NICKNAME request 815 with a 200 response as per regular MSRP procedures. 817 As indicated earlier, this specification defines a new MSRP header 818 field: "Use-Nickname". The Use-Nickname header field carries a 819 nickname string. This specification defines the usage of the 820 Use-Nickname header field in NICKNAME requests. If need arises, 821 usages of the Use-Nickname header field in other MSRP methods should 822 be specified separately. 824 The syntax of the NICKNAME method and the "Use-Nickname" header field 825 is built upon the MSRP formal syntax [RFC4975] 827 ext-method =/ NICKNAMEm 828 NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps 829 ext-header =/ Use-Nickname 830 ; ext-header defined in RFC 4975 831 Use-Nickname = "Use-Nickname:" SP nickname 832 nickname = quoted-string 833 ; quoted-string defined in RFC 4975 835 Note that, according to RFC 4975 [RFC4975], "quoted-string" admits a 836 subset of UTF-8 characters [RFC3629]. Please refer to Section 9 of 837 RFC 4975 [RFC4975] for more details. 839 Once the MSRP switch has reserved a nickname and has bound it to a 840 URI (e.g., a SIP Address-of-Record), the MSRP server MAY allow the 841 usage of the same nickname by the same user (identified by the same 842 URI, such as a SIP AoR) over a second MSRP session. This might be 843 the case if the user joins the same chat room from a different SIP 844 User Agent. In this case, the user MAY request the same or a 845 different nickname than that used in conjunction with the first MSRP 846 session; the MSRP server MAY accept the usage of the same nickname by 847 the same user. The MSRP switch MUST NOT automatically assign the 848 same nickname to more than one MSRP session established from the same 849 URI, because this can create confusion to the user as whether the 850 same nickname is bound to the second MSRP session. 852 7.2. Modifying a Nickname 854 Typically a participant will reserve a nickname as soon as the 855 participant joins the chat room. But it is also possible for a 856 participant to modify his/her own nickname and replace it with a new 857 one at any time during the duration of the MSRP session. 858 Modification of the nickname is not different from the initial 859 reservation and usage of a nickname, thus the NICKNAME method is used 860 as described in Section 7.1. 862 If a NICKNAME request that attempts to modify the current nickname of 863 the user for some reason fails, the current nickname stays in effect. 864 A new nickname comes into effect and the old one is released only 865 after a NICKNAME request is accepted with a 200 response. 867 7.3. Removing a Nickname 869 If the participant no longer wants to be known by a nickname in the 870 chat room, the participant can follow the method described in 871 Section 7.2. The nickname element of the Use-Nickname header MUST be 872 set to an empty quoted string. 874 7.4. Nicknames in Conference Event Packages 876 Typically the conference focus acts as a notifier of the conference 877 event package, RFC 4575 [RFC4575]. It is RECOMMENDED that conference 878 foci and endpoints support RFC 6502 [RFC6502] for providing 879 information regarding the conference, and in particular, supplying 880 information of the roaster of the conference. It is also RECOMMENDED 881 that conference foci and endpoints support RFC 6501 [RFC6501], which 882 extends the element originally specified in RFC 4575 [RFC4575] 883 with a new 'nickname' attribute. This allows endpoints to learn the 884 nicknames of participants of the chat room. 886 8. The SDP 'chatroom' attribute 888 There are a handful of use cases where a participant would like to 889 learn the chat room capabilities supported by the MSRP switch and the 890 chat room. For example, a participant would like to learn if the 891 MSRP switch supports private messaging, otherwise, the participant 892 may send what he believes is a private instant message addressed to a 893 participant, but since the MSRP switch does not support the functions 894 specified in this memo, the message gets eventually distributed to 895 all the participants of the chat room. 897 The reverse case also exists. A participant, say Alice, whose user 898 agent does not support the extensions defined by this document joins 899 the chat room. The MSRP switch learns that Alice's application does 900 not support private messaging nor nicknames. If another participant, 901 say Bob, sends a private message to Alice, the MSRP switch does not 902 distribute it to Alice, because Alice is not able to differentiate it 903 from a regular message sent to the whole roster. Furthermore, if 904 Alice replied to this message, she would do it to the whole roster. 905 Because of this, the MSRP switch also keeps track of users who do not 906 support the extensions defined in this document. 908 In another scenario, the policy of a chat room may indicate that 909 certain functions are not allowed. For example, the policy may 910 indicate that nicknames or private messages are not allowed. 912 In order to provide the user with a good chat room experience, we 913 define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a 914 media-level value attribute [RFC4566] that MAY be included in 915 conjunction with an MSRP media stream (i.e., when an m= line in SDP 916 indicates "TCP/MSRP" or "TCP/TLS/MSRP"). The 'chatroom' attribute 917 without further modifiers (e.g., chat-tokens) indicates that the 918 endpoint supports the procedures described in this document for 919 transferring MSRP messages to/from a chat room. The 'chatroom' 920 attribute can be complemented with additional modifiers that further 921 indicate the intersection of support and local policy allowance for a 922 number of functions specified in this document. Specifically, we 923 provide the means for indicating support to use nicknames and private 924 messaging. 926 The 'chatroom' attribute merely indicates the capabilities supported 927 and allowed by the local policy. This attribute is not a negotiation 928 subject to the SDP offer/answer model [RFC3264], but instead a 929 declaration. Therefore, a 'chatroom' attribute included in an SDP 930 answer does not need to be a subset of the values included in the 931 'chatroom' attribute of its corresponding SDP offer. Consequently, 932 an SDP answer MAY contain a 'chatroom' attribute even if its 933 corresponding SDP offer did not include it. 935 On doing subsequent SDP offer/answer [RFC3264] exchanges pertaining 936 to the same session, the 'chatroom' attribute MAY be modified with 937 respect an earlier SDP offer/answer exchange. The new value of this 938 attribute indicate the current support and local policy, meaning that 939 some restrictions can apply now or might have been removed. If the 940 'chatroom' attribute is not included in a subsequent SDP offer/ 941 answer, but is corresponding MSRP stream is still in place, it 942 indicates that support for the procedures indicated in this document 943 are disabled. 945 The 'chatroom' SDP attribute has the following Augmented BNF (ABNF) 946 [RFC5234] syntax: 948 attribute =/ chatroom-attr 949 ; attribute defined in RFC 4566 950 chatroom-attr = chatroom-label [":" chat-token 951 *(SP chat-token)] 952 chatroom-label = "chatroom" 953 chat-token = (nicknames-token / private-msg-token / 954 ext-token) 955 nicknames-token = "nickname" 956 private-msg-token = "private-messages" 957 ext-token = private-token / standard-token 958 private-token = toplabel "." *(domainlabel ".") token 959 ; toplabel defined in RFC 3261 960 ; domainlabel defined in RFC 3261 961 ; token defined in RFC 3261 962 standard-token = token 964 A given 'chat-token' value MUST NOT appear more than once in a 965 'chatroom' attribute. 967 A conference focus that includes the 'nicknames' token in the session 968 description is signaling that the MSRP switch supports and the chat 969 room allows to use the procedures specified in Section 7. A 970 conference focus that includes the 'private-messages' in the SDP 971 description is signaling that the MSRP switch supports and the chat 972 room allows to use the procedures specified in Section 6.2. 974 Example of the 'chatroom' attribute for an MSRP media stream that 975 indicates the acceptance of nicknames and private messages: 977 a=chatroom:nickname private-messages 979 An example of a 'chatroom' attribute for an MSRP media stream where 980 the endpoint, e.g., an MSRP switch, does not allow either nicknames 981 nor private messages. 983 a=chatroom 985 The 'chatroom' attribute allows extensibility with the addition of 986 new tokens. No IANA registry is provided at this time, since no 987 extensions are expected at the time of this writing. Extensions to 988 the 'chatroom' attribute can be defined in IETF documents or as 989 private vendor extensions. 991 Extensions defined in IETF document MUST follow the 'standard-token' 992 ABNF previously defined. In this type of extensions, are must be 993 taken in the selection of the token to avoid a clash with any of the 994 tokens previously defined. 996 Private extensions MUST follow the 'private-token' ABNF previously 997 defined. The 'private-token' MUST include the DNS name of the vendor 998 in reverse order in the token, in order to avoid clashes of tokens. 999 The following is an example of a "chat.foo" extension by vendor 1000 "example.com" 1002 a=chatroom:nickname private-messages com.example.chat.foo 1004 9. Examples 1006 9.1. Joining a chat room 1008 Figure 3 presents a flow diagram where Alice joins a chat room by 1009 sending an INVITE request. This INVITE request contains a session 1010 description that includes the chatroom extensions defined in this 1011 document. 1013 Alice Conference focus 1014 | | 1015 |F1: (SIP) INVITE | 1016 |----------------------->| 1017 |F2: (SIP) 200 OK | 1018 |<-----------------------| 1019 |F3: (SIP) ACK | 1020 |----------------------->| 1021 | | 1023 Figure 3: Flow diagram of a user joining a chat room 1025 F1: Alice constructs an SDP description that includes an MSRP media 1026 stream. She also indicates her support for the chatroom extensions 1027 defined in this document. She sends the INVITE request to the chat 1028 room server. 1030 INVITE sip:chatroom22@chat.example.com SIP/2.0 1031 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1032 Max-Forwards: 70 1033 From: Alice ;tag=9fxced76sl 1034 To: Chatroom 22 1035 Call-ID: 3848276298220188511@atlanta.example.com 1036 CSeq: 1 INVITE 1037 Contact: 1038 Content-Type: application/sdp 1039 Content-Length: 290 1041 v=0 1042 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 1043 s=- 1044 c=IN IP4 client.atlanta.example.com 1045 m=message 7654 TCP/MSRP * 1046 a=accept-types:message/cpim text/plain text/html 1047 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1048 a=chatroom:nickname private-messages 1050 F2: The chat room server accepts the session establishment. It 1051 includes the 'isfocus' and other relevant feature tags in the Contact 1052 header field of the response. The chat room server also builds an 1053 SDP answer that forces the reception of messages wrapped in Message/ 1054 CPIM wrappers. It also includes the 'chatroom' attribute with the 1055 allowed extensions. 1057 SIP/2.0 200 OK 1058 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1059 ;received=192.0.2.101 1060 From: Alice ;tag=9fxced76sl 1061 To: Chatroom 22 ;tag=8321234356 1062 Call-ID: 3848276298220188511@atlanta.example.com 1063 CSeq: 1 INVITE 1064 Contact: \ 1065 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \ 1066 ;automata;isfocus;message;event="conference" 1067 Content-Type: application/sdp 1068 Content-Length: 290 1070 v=0 1071 o=chat 2890844527 2890844527 IN IP4 chat.example.com 1072 s=- 1073 c=IN IP4 chat.example.com 1074 m=message 12763 TCP/MSRP * 1075 a=accept-types:message/cpim 1076 a=accept-wrapped-types:text/plain text/html * 1077 a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1078 a=chatroom:nickname private-messages 1080 F3: The session established is acknowledged (details not shown). 1082 9.2. Setting up a nickname 1084 Figure 4 shows an example of Alice setting up a nickname using the 1085 chat room as provider. Her first proposal is not accepted because 1086 that proposed nickname is already in use. Then, she makes a second 1087 proposal with a new nickname. This second proposal is accepted. 1089 Alice MSRP switch 1090 | | 1091 |F1: (MSRP) NICKNAME | 1092 |----------------------->| 1093 |F2: (MSRP) 423 | 1094 |<-----------------------| 1095 |F3: (MSRP) NICKNAME | 1096 |----------------------->| 1097 |F4: (MSRP) 200 | 1098 |<-----------------------| 1099 | | 1101 Figure 4: Flow diagram of a user setting up her nickname 1103 F1: Alice sends an MSRP NICKNAME request that contains her proposed 1104 nicknames in the Use-Nickname header field. 1106 MSRP d93kswow NICKNAME 1107 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1108 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1109 Use-Nickname: "Alice the great" 1110 -------d93kswow$ 1112 F2: The MSRP switch analyzes the existing allocation of nicknames and 1113 detects that the nickname "Alice the great" is already provided to 1114 another participant in the chat room. The MSRP switch answers with a 1115 423 response. 1117 MSRP d93kswow 423 Nickname usage failed 1118 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1119 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1120 -------d93kswow$ 1122 F3: Alice receives the response. She proposes a new nickname in a 1123 second NICKNAME request. 1125 MSRP 09swk2d NICKNAME 1126 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1127 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1128 Use-Nickname: "Alice in Wonderland" 1129 -------09swk2d$ 1131 F4: The MSRP switch accepts the nickname proposal and answers with a 1132 200 response. 1134 MSRP 09swk2d 200 OK 1135 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1136 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1137 -------09swk2d$ 1139 9.3. Sending a regular message to the chat room 1141 Figure 5 depicts a flow diagram where Alice is sending a regular 1142 message addressed to the chat room. The MSRP switch distributes the 1143 message to the rest of the participants. 1145 Alice MSRP switch Bob Charlie 1146 | | | | 1147 | F1: (MSRP) SEND | | | 1148 |--------------------->| F3: (MSRP) SEND | | 1149 | F2: (MSRP) 200 |----------------------->| | 1150 |<---------------------| F4: (MSRP) SEND | | 1151 | |------------------------------->| 1152 | | F5: (MSRP) 200 OK | | 1153 | |<-----------------------| | 1154 | | F6: (MSRP) 200 OK | | 1155 | |<------------------------------ | 1156 | | | | 1157 | | | | 1159 Figure 5: Sending a regular message to the chat room 1161 F1: Alice builds a text message and wraps it in a Message/CPIM 1162 wrapper. She addresses the message to the chat room. She encloses 1163 the resulting Message/CPIM wrapper in an MSRP SEND request and sends 1164 it to the MSRP switch via the existing TCP connection. 1166 MSRP 3490visdm SEND 1167 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1168 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1169 Message-ID: 99s9s2 1170 Byte-Range: 1-*/* 1171 Content-Type: message/cpim 1173 To: 1174 From: 1175 DateTime: 2009-03-02T15:02:31-03:00 1176 Content-Type: text/plain 1178 Hello guys, how are you today? 1179 -------3490visdm$ 1181 F2: The MSRP switch acknowledges the reception of the SEND request 1182 with a 200 (OK) response. 1184 MSRP 3490visdm 200 OK 1185 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1186 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1187 Message-ID: 99s9s2 1188 -------3490visdm$ 1190 F3: The MSRP switch creates a new MSRP SEND request that contains the 1191 received Message/CPIM wrapper and sends it to Bob. 1193 MSRP 490ej23 SEND 1194 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1195 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1196 Message-ID: 304sse2 1197 Byte-Range: 1-*/* 1198 Content-Type: message/cpim 1200 To: 1201 From: 1202 DateTime: 2009-03-02T15:02:31-03:00 1203 Content-Type: text/plain 1205 Hello guys, how are you today? 1206 -------490ej23$ 1208 Since the received message is addressed to the chat room URI in the 1209 From header of the Message/CPIM header, Bob knows that this is a 1210 regular message distributed all participants in the chat room, rather 1211 that a private message addressed to him. 1213 The rest of the message flows are analogous to the previous. They 1214 are not shown here. 1216 9.4. Sending a private message to a participant 1218 Figure 6 depicts a flow diagram where Alice is sending a private 1219 message addressed to Bob's SIP AOR. The MSRP switch distributes the 1220 message only to Bob. 1222 Alice MSRP switch Bob 1223 | | | 1224 | F1: (MSRP) SEND | | 1225 |--------------------->| F3: (MSRP) SEND | 1226 | F2: (MSRP) 200 |----------------------->| 1227 |<---------------------| F4: (MSRP) 200 | 1228 | |<-----------------------| 1229 | | | 1231 Figure 6: Sending a private message to Bob 1233 F1: Alice builds a text message and wraps it in a Message/CPIM 1234 wrapper. She addresses the message to Bob's URI, which she learned 1235 from a notification in the conference event package. She encloses 1236 the resulting Message/CPIM wrapper in an MSRP SEND request and sends 1237 it to the MSRP switch via the existing TCP connection. 1239 MSRP 6959ssdf SEND 1240 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1241 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1242 Message-ID: okj3kw 1243 Byte-Range: 1-*/* 1244 Content-Type: message/cpim 1246 To: 1247 From: 1248 DateTime: 2009-03-02T15:02:31-03:00 1249 Content-Type: text/plain 1251 Hello Bob. 1252 -------6959ssdf$ 1254 F2: The MSRP switch acknowledges the reception of the SEND request 1255 with a 200 (OK) response. 1257 MSRP 6959ssdfm 200 OK 1258 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1259 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1260 Message-ID: okj3kw 1261 -------6959ssdfm$ 1262 F3: The MSRP switch creates a new MSRP SEND request that contains the 1263 received Message/CPIM wrapper and sends it only to Bob. Bob can 1264 distinguish the sender in the From header of the Message/CPIM 1265 wrapper. He also identifies this as a private message due to the 1266 presence of his own SIP AOR in the To header field of the Message/ 1267 CPIM wrapper. 1269 MSRP 9v9s2 SEND 1270 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1271 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1272 Message-ID: d9fghe982 1273 Byte-Range: 1-*/* 1274 Content-Type: message/cpim 1276 To: 1277 From: 1278 DateTime: 2009-03-02T15:02:31-03:00 1279 Content-Type: text/plain 1281 Hello Bob. 1282 -------9v9s2$ 1284 F4: Bob acknowledges the reception of the SEND request with a 200 1285 (OK) response. 1287 MSRP 9v9s2 200 OK 1288 To-Path: msrp://chat.example.com:5678/jofofo3;tcp 1289 From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1290 Message-ID: d9fghe982 1291 -------9v9s2$ 1293 9.5. Chunked private message 1295 The MSRP message below depicts the example of the same private 1296 message described in Section 9.4, but now the message is split in two 1297 chunks. The MSRP switch must wait for the complete set of Message/ 1298 CPIM headers before distributing the messages. 1300 MSRP 7443ruls SEND 1301 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1302 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1303 Message-ID: aft4to 1304 Byte-Range: 1-*/174 1305 Content-Type: message/cpim 1307 To: 1308 From: 1309 -------7443ruls$ 1311 MSRP 7443ruls SEND 1312 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1313 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1314 Message-ID: aft4to 1315 Byte-Range: 68-174/174 1316 Content-Type: message/cpim 1318 DateTime: 2009-03-02T15:02:31-03:00 1319 Content-Type: text/plain 1321 Hello Bob 1322 -------7443ruls$ 1324 9.6. Nickname in a conference information document 1326 Figure 7 depicts an XML Conference Information Document received in a 1327 SIP NOTIFY request as a notification to the XCON Conference Event 1328 Package, RFC 6502 [RFC6502]. The Conference Information Document 1329 follows the XCON Data Model specified in RFC 6501 [RFC6501]. 1331 The Conference Information Document of Figure 7 presents information 1332 of two users who are participating in the conference (see each of the 1333 elements). Each participant is bound to a nickname, shown in 1334 the 'nickname' attribute of the element. 1336 NOTE: The purpose of Figure 7 is to show the user-to-nickname 1337 relation. It is believed that the example is correct, according 1338 to RFC 6501 [RFC6501]. In case of contradictions between this 1339 specification and RFC 6501 [RFC6501], the latter has precedence 1340 over this one. 1342 1343 1348 1351 1352 MSRP nickname example 1353 1354 1357 1358 2 1359 1360 1363 1364 1367 Bob Hoskins 1368 1369 1372 1375 Alice Kay 1376 1377 1379 1381 Figure 7: Nickname in a conference information document 1383 10. IANA Considerations 1385 10.1. New MSRP Method 1387 This specification defines a new MSRP method to be added to the 1388 Methods sub-registry of the Message Session Relay Protocol (MSRP) 1389 Parameters registry: 1391 NICKNAME 1393 See section Section 7 for details. 1395 10.2. New MSRP Header 1397 This specification defines a new MSRP header to be added to the 1398 Header Field sub-registry of the Message Session Relay Protocol 1399 (MSRP) Parameters registry: 1401 Use-Nickname 1403 See Section 7 for details. 1405 10.3. New MSRP Status Codes 1407 This specification defines three new MSRP status codes to be added to 1408 the Status-Code sub-registry of the Message Session Relay Protocol 1409 (MSRP) parameters registry. 1411 The 404 status code indicates the failure to resolve the recipient's 1412 URI in the To header field of the Message/CPIM wrapper in the SEND 1413 request, e.g, due to an unknown recipient. See Section 6.2 for 1414 details. 1416 The 424 status code indicates a failure in allocating the requested 1417 nickname due to a malformed syntax in the Use-Nickname header field. 1418 See Section 7 for details. 1420 The 425 status code indicates a failure in allocating the requested 1421 nickname becuase the requested nickname in the Use-Nickname header 1422 field is reserved or is already in use by another user. See 1423 Section 7 for details. 1425 The 428 status code indicates that the recipient of a SEND request 1426 does not support private messages. See Section 6.2 for details. 1428 Table 1 summarizes the IANA registration data with respect to new 1429 MSRP status codes: 1431 +-------+-------------------------------------+-----------+ 1432 | Value | Description | Reference | 1433 +-------+-------------------------------------+-----------+ 1434 | 404 | Failure to resolve recipient's URI | RFC XXXX | 1435 | 424 | Malformed nickname | RFC XXXX | 1436 | 425 | Nickname reserved or already in use | RFC XXXX | 1437 | 428 | Private messages not supported | RFC XXXX | 1438 +-------+-------------------------------------+-----------+ 1440 Table 1: New status codes 1442 10.4. New SDP Attribute 1444 This specification defines a new media-level attribute in the Session 1445 Description Protocol (SDP) Parameters registry. The registration 1446 data is as follows: 1448 Contact: Miguel Garcia 1450 Phone: +34 91 339 1000 1452 Attribute name: chatroom 1454 Long-form attribute name: Chat Room 1456 Type of attribute: media level only 1458 This attribute is not subject to the charset attribute 1460 Description: This attribute identifies support and local policy 1461 allowance for a number of chat room related functions 1463 Specification: RFC XXXX 1465 See section Section 8 for details. 1467 11. Security Considerations 1469 This document proposes extensions to the Message Session Relay 1470 Protocol [RFC4975]. Therefore, the security considerations of that 1471 document apply to this document as well. 1473 If the participant's SIP user agent doesn't understand the "isfocus" 1474 feature tag [RFC3840], it will not know that it is connected to a 1475 conference instance. The participant might not be notified that the 1476 participant's MSRP client will try to send messages to the MSRP 1477 switch having potentially multiple recipients. If the participant's 1478 MSRP client doesn't support the extensions of this specification, it 1479 is unlikely that it will try to send a message using 'Message/CPIM' 1480 wrapper content type [RFC3862], and the MSRP switch will reject the 1481 request with a 415 response [RFC4975]. Still if a participant's MSRP 1482 client does create a message with a valid 'Message/CPIM' wrapper 1483 content type [RFC3862] having the To header set to the URI of the 1484 chat room and the From header set to the URI of which the participant 1485 is known to the chat room, the participant might be unaware that the 1486 message can be forwarded to multiple recipients. Equally if the To 1487 header is set to a valid URI of a recipient known to the chat room, 1488 the message can be forwarded as a private message without the 1489 participant knowing. 1491 To mitigate these problems, when the chat room detects that a user 1492 agent does not support the procedures of this document (i.e., when 1493 the SIP User Agent is not chat room aware), the MSRP switch SHOULD 1494 send a regular MSRP message indicating that the SIP User Agent is 1495 actually part of a chat room, and that all the messages that the user 1496 sends correctly formated will be distributed to a number of 1497 participants. Additionally, the MSRP switch SHOULD also send a 1498 regular MSRP text message including the list of participants in the 1499 chat room, so that the user becomes aware of the roster. 1501 If a participant wants to avoid eavesdropping, the participant's MSRP 1502 client can send the messages over a TLS [RFC5246] transport 1503 connection, as allowed by MSRP. It's up to the policy of the MSRP 1504 switch if the messages are forwarded to the other participant's in 1505 the chat room using TLS [RFC5246] transport. 1507 Nicknames are used to show the appearance of the participants of the 1508 chat room. A successful take over of a nickname from a participant 1509 might lead to private messages to be sent to the wrong destination. 1510 The recipient's URI will be different from the URI associated to the 1511 original owner of the nickname, but the sender might not notice this. 1512 To avoid takeovers the MSRP switch MUST make sure that a nickname is 1513 unique inside a chat room. Also the security consideration for any 1514 authenticated identity mechanisms used to validate the SIP AOR will 1515 apply to this document as well. It is up to the policy of the chat 1516 room to determine if a nickname that has been previously used by 1517 another participant of the chat room can be reserved or not. 1519 12. Contributors 1521 This work would have never been possible without the fruitful 1522 discussions in the SIMPLE WG mailing list, specially with Brian Rosen 1523 (Neustar) and Paul Kyzivat (Cisco), who provided extensive review and 1524 improvements throughout the document. 1526 13. Acknowledgments 1528 The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, 1529 Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrian 1530 Georgescu, Nancy Greene, Cullen Jennings, Flemming Andreasen, Suresh 1531 Krishnan, Christer Holmberg, Saul Ibarra, Enrico Marocco, Alexey 1532 Melnikov, and Peter Saint-Andre for providing comments. 1534 14. References 1536 14.1. Normative References 1538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1539 Requirement Levels", BCP 14, RFC 2119, March 1997. 1541 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1542 A., Peterson, J., Sparks, R., Handley, M., and E. 1543 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1544 June 2002. 1546 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1547 with Session Description Protocol (SDP)", RFC 3264, 1548 June 2002. 1550 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1551 10646", STD 63, RFC 3629, November 2003. 1553 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1554 "Indicating User Agent Capabilities in the Session 1555 Initiation Protocol (SIP)", RFC 3840, August 2004. 1557 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1558 (CPIM)", RFC 3860, August 2004. 1560 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1561 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1563 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1564 Session Initiation Protocol (SIP)", RFC 4353, 1565 February 2006. 1567 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1568 Description Protocol", RFC 4566, July 2006. 1570 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1571 Initiation Protocol (SIP) Event Package for Conference 1572 State", RFC 4575, August 2006. 1574 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1575 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1577 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1578 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1579 September 2007. 1581 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1582 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1584 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 1585 Centralized Conferencing", RFC 5239, June 2008. 1587 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1588 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1590 [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 1591 "Conference Information Data Model for Centralized 1592 Conferencing (XCON)", RFC 6501, March 2012. 1594 [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. 1595 Urpalainen, "Conference Event Package Data Format 1596 Extension for Centralized Conferencing (XCON)", RFC 6502, 1597 March 2012. 1599 [I-D.ietf-precis-nickname] 1600 Saint-Andre, P., "Preparation and Comparison of 1601 Nicknames", draft-ietf-precis-nickname-00 (work in 1602 progress), August 2012. 1604 14.2. Informative References 1606 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1607 April 2000. 1609 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1610 Extensions to the Session Initiation Protocol (SIP) for 1611 Asserted Identity within Trusted Networks", RFC 3325, 1612 November 2002. 1614 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1615 RFC 3966, December 2004. 1617 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1618 Authenticated Identity Management in the Session 1619 Initiation Protocol (SIP)", RFC 4474, August 2006. 1621 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1622 Protocol (XMPP): Core", RFC 6120, March 2011. 1624 Authors' Addresses 1626 Aki Niemi 1627 Nokia 1628 P.O. Box 407 1629 NOKIA GROUP, FIN 00045 1630 Finland 1632 Phone: +358 50 389 1644 1633 Email: aki.niemi@nokia.com 1635 Miguel A. Garcia-Martin 1636 Ericsson 1637 Calle Via de los Poblados 13 1638 Madrid, ES 28033 1639 Spain 1641 Email: miguel.a.garcia@ericsson.com 1643 Geir A. Sandbakken (editor) 1644 Cisco Systems 1645 Philip Pedersens vei 20 1646 N-1366 Lysaker 1647 Norway 1649 Phone: +47 67 125 125 1650 Email: geirsand@cisco.com 1651 URI: http://www.cisco.com