idnits 2.17.1 draft-ietf-simple-chat-13.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 (January 23, 2012) is 4475 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) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 3 errors (**), 0 flaws (~~), 2 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: July 26, 2012 Ericsson 6 G. Sandbakken, Ed. 7 Cisco Systems 8 January 23, 2012 10 Multi-party Chat Using the Message Session Relay Protocol (MSRP) 11 draft-ietf-simple-chat-13 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 26, 2012. 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 . . . . . . . . . . . . . . . . . . . . . 13 79 6.3. MSRP reports and responses . . . . . . . . . . . . . . . . 15 80 7. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 7.1. Using Nicknames within a Conference . . . . . . . . . . . 16 82 7.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 18 83 7.3. Removing a Nickname . . . . . . . . . . . . . . . . . . . 18 84 7.4. Nicknames in Conference Event Packages . . . . . . . . . . 18 85 8. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . . . 18 86 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 21 88 9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 23 89 9.3. Sending a regular message to the chat room . . . . . . . . 24 90 9.4. Sending a private message to a participant . . . . . . . . 26 91 9.5. Chunked private message . . . . . . . . . . . . . . . . . 27 92 9.6. Nickname in a conference information document . . . . . . 28 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 94 10.1. New MSRP Method . . . . . . . . . . . . . . . . . . . . . 29 95 10.2. New MSRP Header . . . . . . . . . . . . . . . . . . . . . 30 96 10.3. New MSRP Status Codes . . . . . . . . . . . . . . . . . . 30 97 10.4. New SDP Attribute . . . . . . . . . . . . . . . . . . . . 30 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 99 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 102 14.1. Normative References . . . . . . . . . . . . . . . . . . . 32 103 14.2. Informative References . . . . . . . . . . . . . . . . . . 34 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 106 1. Introduction 108 The Message Session Relay Protocol (MSRP) [RFC4975] defines a 109 mechanism for sending a series of instant messages within a session. 110 The Session Initiation Protocol (SIP) [RFC3261] in combination with 111 the Session Description Protocol (SDP) [RFC4566] allows for two peers 112 to establish and manage such sessions. 114 In another application of SIP, a user agent can join in a multi-party 115 conversation called a conference that is hosted by a specialized user 116 agent called a focus [RFC4353]. Such a conference can naturally 117 involve MSRP sessions. It is the responsibility of an entity 118 handling the media to relay instant messages received from one 119 participant to the rest of the participants in the conference. 121 Several such systems already exist in the Internet. Participants in 122 a chat room can be identified with a pseudonym or nickname, and 123 decide whether their real identifier is disclosed to other 124 participants. Participants can also use a rich set of features such 125 as the ability to send private instant messages to other 126 participants. 128 Similar conferences supporting chat rooms are already available 129 today. For example, Internet Relay Chat (IRC) [RFC2810], Extensible 130 Messaging and Presence Protocol (XMPP): Core [RFC6120] based chat 131 rooms, and many other proprietary systems provide chat room 132 functionality. Specifying equivalent functionality for MSRP-based 133 systems provides competitive features and enables interworking 134 between the systems. 136 This document defines requirements, conventions, and extensions for 137 providing private messages and nickname management in centralized 138 conferences with MSRP. Participants in a chat room can be identified 139 by a pseudonym, and decide if their real identifier is disclosed to 140 other participants. This memo uses the SIP Conferencing Framework 141 [RFC4353] as a design basis. It also aims to be compatible with the 142 A Framework for Centralized Conferencing [RFC5239]. Should 143 requirements arise, future mechanisms for providing similar 144 functionality in generic conferences might be developed, for example, 145 where the media is not only restricted to MSRP. The mechanisms 146 described in this document provide a future compatible short-term 147 solution for MSRP centralized conferences. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119, BCP 14 154 [RFC2119], and indicate requirement levels for compliant 155 implementations. 157 This memo deals with tightly coupled SIP conferences defined in SIP 158 Conferencing Framework [RFC4353] and adopts the terminology from that 159 document. In addition to that terminology, we introduce some new 160 terms: 162 Nickname: a pseudonym or descriptive name associated to a 163 participant. See Section 7 for details 165 Multi-party chat: an instance of a tightly coupled conference, in 166 which the media exchanged between the participants consist of MSRP 167 based instant messages. Also known as a chat room. 169 Chat Room: a synonym for a multi-party chat. 171 Chat Room URI: a URI that identifies a particular chat room, and is 172 a synonym of a Conference URI defined in RFC 4353 [RFC4353]. 174 Sender: the conference participant that originally created an 175 instant message and sent it to the chat room for delivery. 177 Recipient: the destination conference participant(s). This 178 defaults to the full conference participant list, minus the IM 179 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 conference 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 participants. 188 Private Instant Message: an instant message sent in a chat room 189 intended for a single participant. A private IM is usually 190 rendered distinctly from the rest of the IMs, indicating that the 191 message was a private communication. 193 Anonymous URI: a URI concealing the participant's SIP AOR from the 194 other participants in the conference. The allocation of such a 195 URI is out of scope of this specification. An anonymous URI must 196 be valid for the length of the conference, and will be utilized by 197 the MSRP switch to forward messages to and from anonymous 198 participants. 200 Conference Event Package: a notification mechanism that allows 201 conference participants to learn conference information including 202 roster and state changes in a conference. This would typically be 203 A Session Initiation Protocol (SIP) Event Package for Conference 204 State [RFC4575] or Conference Event Package Data Format Extension 205 for Centralized Conferencing [I-D.ietf-xcon-event-package]. 207 3. Motivations and Requirements 209 Although conference frameworks describing many types of conferencing 210 applications already exist, such as the Framework for Centralized 211 Conferencing [RFC5239] and the SIP Conferencing Framework [RFC4353], 212 the exact details of session-based instant messaging conferences are 213 not well-defined at the moment. 215 To allow interoperable chat implementations, for both conference- 216 aware, and conference-unaware user agents, certain conventions for 217 MSRP conferences need to be defined. It also seems beneficial to 218 provide a set of features that enhance the baseline multi-party MSRP 219 in order to be able to create systems that have functionality on par 220 with existing chat systems, as well as enable building interworking 221 gateways to these existing chat systems. 223 We define the following requirements: 225 REQ-1: A basic requirement is the existence of a multi-party 226 conference, where participants can join and leave the 227 conference and get instant messages exchanged to the rest of 228 the participants. 230 REQ-2: A conference participant must be able to determine the 231 identifiers of the sender and recipient of the received IMs. 232 Note that the actual identifiers depend no those which were 233 selected by the sender or recipient when he or she joined the 234 conference. 236 REQ-3: A conference participant must be able to determine the 237 recipient of the received message. For instance, the 238 recipient of the message might be the entire conference or a 239 single participant of the conference (i.e., a private 240 message). 242 REQ-4: It must be possible to send a message to a single participant 243 within the conference (i.e., a private instant message). 245 REQ-5: A conference participant may have a nickname or pseudonym 246 associated with their real identifier. 248 REQ-6: It must be possible for a participant to change their 249 nickname during the progress of the conference. 251 REQ-7: It must be possible that a participant is only known by an 252 anonymous identifier and not their real identifier to the 253 rest of the conference. 255 REQ-8: It must be possible for the conference participants to learn 256 the chat room capabilities described in this document. 258 4. Overview of Operation 260 In order to set up a conference, one must first be created. Users 261 wishing to host a conference themselves can of course do just that; 262 their User Agent (UA) simply morphs from an ordinary UA into a 263 special purpose one called a Focus UA. Another, commonly used setup 264 is one where a dedicated node in the network functions as a Focus UA. 266 Each chat room has an identifier of its own: a SIP URI that 267 participants use to join the conference, e.g. by sending an INVITE 268 request. The conference focus processes the invitations, and as 269 such, maintains SIP dialogs with each participant. In a multi-party 270 chat, or chat room, MSRP is one of the established media streams. 271 Each conference participant establishes an MSRP session with the MSRP 272 switch, which is a special purpose MSRP application. The MSRP 273 sessions can be relayed by one or more MSRP relays, which are 274 specified in RFC 4976 [RFC4976]. This is illustrated in Figure 1 275 MSRP Sessions 276 +---------------------------+ 277 | +-----------+ | 278 +---+--+ +---+--+ | | 279 | SIP | | SIP | | | 280 | MSRP | | MSRP | +--+---+----+ 281 |Client| |Client| | MSRP | 282 +---+--+ ++-----+ | Relay | 283 | | +-----+-----+ 284 SIP Dialogs | / | 285 | | | MSRP Sessions 286 +----+------+--+ | 287 | Conference | +-------+-----+ 288 | Focus UA | | MSRP | 289 | |........| Switch | 290 | | | | 291 +---+--------+-+ +-------+-----+ 292 | \ | 293 SIP Dialogs | | | MSRP Sessions 294 | \ | 295 +--+---+ +-+----+ +-----+------+ 296 | SIP | | SIP | | MSRP | 297 | MSRP | | MSRP | | Relay | 298 |Client| |Client| +-+-------+--+ 299 +---+--+ +--+---+ | | 300 | +-----------+ | 301 +------------------------------+ 302 MSRP sessions 304 Figure 1: Multi-party chat overview shown with MSRP Relays and a 305 conference Focus UA 307 The MSRP switch is similar to a conference mixer in that it handles 308 media sessions with each of the participants and bridges these 309 streams together. However, unlike a conference mixer, the MSRP 310 switch merely forwards messages between participants but doesn't 311 actually mix the streams in any way. The system is illustrated in 312 Figure 2. 314 +------+ 315 | MSRP | 316 |Client| 317 +------+ +--.---+ +------+ 318 | MSRP | | | MSRP | 319 |Client| | _|Client| 320 +------._ | ,' +------+ 321 `._ | ,' 322 `.. +----------+ ,' 323 `| |' 324 | MSRP | 325 | Switch | 326 ,| |_ 327 _,-'' +----------+ ``-._ 328 +------.-' | `--+------+ 329 | MSRP | | | MSRP | 330 |Client| | |Client| 331 +------+ | +------+ 332 +---'--+ 333 | MSRP | 334 |Client| 335 +------+ 337 Figure 2: Multi-party chat in a Centralized Conference 339 Typically conference participants also subscribe to a conference 340 event package to gather information about the conference roster in 341 the form of conference state notifications. For example, 342 participants can learn about other participants' identifiers, 343 including their nicknames. 345 All messages in the chat room use the 'Message/CPIM' wrapper content 346 type [RFC3862], so that it is possible to distinguish between private 347 and regular messages. When a participant wants to send an instant 348 message to the conference, it constructs an MSRP SEND request and 349 submits it to the MSRP switch including a regular payload (e.g. a 350 Message/CPIM message that contains a text, HTML, an image, etc.). 351 The Message/CPIM To header is set to the chat room URI. The switch 352 then fans out the SEND request to all of the other participants using 353 their existing MSRP sessions. 355 A participant can also send a private instant message addressed to a 356 participant whose identifier has been learned, e.g. via a conference 357 event package. In this case the sender creates an MSRP SEND request 358 with a Message/CPIM wrapper whose To header contains not the chat 359 room URI but the recipient's URI. The MSRP switch then forwards the 360 SEND request to that recipient. This specification supports the 361 sending of private messages to one and only one recipient. However, 362 if the recipient is logged from different endpoints, the MSRP switch 363 will distribute the private message to each endpoint the recipient is 364 logged. 366 We extend the current MSRP negotiation that takes place in SDP 367 [RFC4566] to allow participants to learn whether the chat room 368 supports and is willing to accept (e.g. due to local policy 369 restrictions) certain MSRP functions defined in this memo, such as 370 nicknames or private messaging. 372 Naturally, when a participant wishes to leave a chat room, it sends a 373 SIP BYE request to the Focus UA and terminates the SIP dialog with 374 the focus and MSRP sessions with the MSRP switch. 376 This document assumes that each chat room is allocated its own SIP 377 URI. A user joining a chat room sends an INVITE request to that SIP 378 URI, and as a result, a new MSRP session is established between the 379 user and the MSRP switch. It is assumed that an MSRP session is 380 mapped to a chat room. If a user wants to join a second chat room, 381 he creates a different INVITE request, through a different SIP 382 dialog, which leads to the creation of a second MSRP session between 383 the user and the MSRP switch. Notice that these two MSRP sessions 384 can still be multiplexed over the same TCP connection as per regular 385 MSRP procedures. However, each chat room is associated to a unique 386 MSRP session and a unique SIP dialog. 388 5. Creating, Joining, and Deleting a Chat Room 390 5.1. Creating a Chat Room 392 Since we consider a chat room a particular type of conference having 393 MSRP media, the methods defined by the SIP Conference Framework 394 [RFC4353] for creating conferences are directly applicable to a chat 395 room. 397 Once a chat room is created, it is identified by a SIP URI, like any 398 other conference. 400 5.2. Joining a Chat Room 402 Participants usually join the conference by sending an INVITE request 403 to the conference URI. As long as the conference policy allows, the 404 INVITE request is accepted by the focus and the user is brought into 405 the conference. 407 The MSRP switch needs to be aware of the URIs of the participant 408 (SIP, Tel, or IM URIs) in order to validate messages sent from this 409 participant prior to their forwarding. This information is known to 410 the focus of the conference. Therefore an interface between the 411 focus and the MSRP switch is assumed. However, the interface between 412 the focus and the MSRP switch is outside the scope of this document. 414 Conference aware participants will detect that the peer is a focus 415 due to the presence of the "isfocus" feature tag [RFC3840] in the 416 Contact header field of the 200-class response to the INVITE request. 417 Conference unaware participants will not notice it is a focus, and 418 can not apply the additional mechanisms defined in this document. 419 Participants are also aware that the mixer is an MSRP switch due to 420 the presence of a 'message' media type and either TCP/MSRP or TCP/ 421 TLS/MSRP as the protocol field in the media line of SDP [RFC4566]. 423 The conference focus of a chat room MUST include support for a 424 Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by 425 setting the 'accept-types' MSRP media line attribute in the SDP offer 426 or answer to include 'Message/CPIM'. 428 Note that the 'Message/CPIM' wrapper is used to carry the sender 429 information that, otherwise, it will not be available to the 430 recipient. Additionally, 'Message/CPIM' wrapper carries the 431 recipient information (e.g. To and Cc: headers). 433 If a participant wants to remain anonymous to the rest of the 434 participants in the conference, the participant's UA must provide an 435 anonymous URI to the conference focus. The URI will be used in the 436 From and To headers in the 'Message/CPIM' wrapper, and can be learned 437 by the other participants of the conference. Notice that in order 438 for the anonymity mechanism to work, the anonymous URI must not 439 reveal the participant's SIP AOR. The mechanism for acquiring an 440 anonymous URI is outside the scope of this specification. 442 The conference focus of a chat room MUST learn the chat room 443 capabilities of each participant that joins the chat room. The 444 conference focus MUST inform the MSRP switch of such support in order 445 to prevent the MSRP switch from distributing private messages to 446 participants who do not support private messaging. The recipient 447 would not be able to render the message as private, and any potential 448 reply would be sent to the whole chat room. 450 5.3. Deleting a Chat Room 452 As with creating a conference, the methods defined by the SIP 453 Conference Framework [RFC4353] for deleting a conference are directly 454 applicable to a chat room. The MSRP switch will terminate the MSRP 455 sessions with all the participants. 457 Deleting a chat room is an action that heavily depends on the policy 458 of the chat room. The policy can determine that the chat room is 459 deleted when the creator leaves the conference, or with any out of 460 band mechanism. 462 6. Sending and Receiving Instant Messages 464 6.1. Regular Messages 466 This section describes the conventions used to send and receive 467 instant messages that are addressed to all the participants in the 468 chat room. These are sent over a regular MSRP SEND request that 469 contains a Message/CPIM wrapper [RFC3862] that in turn contains the 470 desired payload (e.g. text, image, video-clip, etc.). 472 When a chat room participant wishes to send an instant message to all 473 the other participants in the chat room, it constructs an MSRP SEND 474 request according to the procedures specified in RFC 4975 [RFC4975]. 475 The sender MAY choose the desired MSRP report model (e.g., populate 476 the Success-Report and Failure-Report MSRP header fields). 478 The SEND request MUST contain a top-level wrapper of type 'Message/ 479 CPIM' according to RFC 3862 [RFC3862]. The actual instant message 480 payload MUST be included as payload of the 'Message/CPIM' wrapper and 481 MAY be of any type negotiated in the SDP 'accept-types' attribute 482 according to the MSRP rules. 484 On sending a regular message the sender MUST populate the To header 485 of the Message/CPIM wrapper with the URI of the chat room. The 486 sender SHOULD populate the From header of the Message/CPIM wrapper 487 with a proper identifier by which the user is recognized in the 488 conference. Identifiers that can be used (among others) are: 490 o A SIP URI [RFC3261] representing the participant's address-of- 491 record 493 o A tel URI [RFC3966] representing the participant's telephone 494 number 496 o An IM URI [RFC3860] representing the participant's instant 497 messaging address 499 o An Anonymous URI representing the participant's anonymous address 501 An MSRP switch that receives a SEND request from a participant SHOULD 502 first verify that the From header field of the Message/CPIM wrapper 503 is correctly populated with a valid URI of a participant. This 504 imposes a requirement for the focus of the conference to inform the 505 MSRP switch of the URIs by which the participant is known, in order 506 for the MSRP switch to validate messages. Section 6.3 provides 507 further information with the actions to be taken in case this 508 validation fails. 510 Then the MSRP switch should inspect the To header field of the 511 Message/CPIM wrapper. If the MSRP switch receives a message 512 containing several To header fields in the Message/CPIM wrapper the 513 MSRP switch MUST reject the MSRP SEND request with a 403 response, as 514 per procedures in RFC 4975 [RFC4975]. Then, if the To header field 515 of the Message/CPIM wrapper contains the chat room URI and there are 516 no other To header fields, the MSRP switch can generate a copy of the 517 SEND request to each of the participants in the conference except the 518 sender. The MSRP switch MUST NOT modify the content received in the 519 SEND request. However, the MSRP switch MAY re-chunk any of the 520 outbound MSRP SEND requests. 522 Note that the MSRP switch does not need to wait for the reception of 523 the complete MSRP chunk or MSRP message before it starts the 524 distribution to the rest of the participants. Instead, once the MSRP 525 switch has received the headers of the Message/CPIM wrapper it SHOULD 526 start the distribution process. Having the header of the Message/ 527 CPIM wrapper only in the first chunk, the MSRP switch MUST track the 528 Message-Id until the last chunk of the message has been distributed. 530 An MSRP endpoint that receives a SEND request from the MSRP switch 531 containing a Message/CPIM wrapper SHOULD first inspect the To header 532 field of the Message/CPIM wrapper. If the To header field is set to 533 the chat room URI, it should render it as a regular message that has 534 been distributed to all the participants in the conference. Then the 535 MSRP endpoint SHOULD inspect the From header field of the Message/ 536 CPIM wrapper to identify the sender. The From header field will 537 include a URI that identifies the sender. The endpoint might have 538 also received further identifier information through a subscription 539 to a conference event package. 541 6.2. Private Messages 543 This section describes the conventions used to send and receive 544 private instant messages, i.e., instant messages that are addressed 545 to one participant of the chat room rather to all of them. A chat 546 room can signal support for private messages using the 'chatroom' 547 attribute in SDP (see Section 8 for details). 549 When a chat room participant wishes to send a private instant message 550 to a participant in the chat room, it follows the same procedures for 551 creating a SEND request as for regular messages (Section 6.1). The 552 only difference is that the MSRP endpoint MUST populate a single To 553 header of the Message/CPIM wrapper with the identifier of the 554 intended recipient. The identifier can be SIP, TEL, and IM URIs 555 typically learned from the information received in notifications of a 556 conference event package. 558 As for regular messages, an MSRP switch that receives a SEND request 559 from a participant SHOULD first verify that the From header field of 560 the Message/CPIM wrapper is correctly populated with a valid URI 561 (i.e., the URI is a participant of this chat room). Section 6.3 562 provides further information with the actions to be taken in case 563 this validation fails. 565 Then the MSRP switch MUST inspect the To header field of the Message/ 566 CPIM wrapper. If the MSRP switch receives a message containing 567 several To header fields in the Message/CPIM wrapper the MSRP switch 568 MUST reject the MSRP SEND request with a 403 response, as per 569 procedures in RFC 4975 [RFC4975]. Then the MSRP switch MUST verify 570 that the To header of the Message/CPIM wrapper matches the URI of a 571 participant of the chat room. If this To header field does not 572 contain the URI of a participant of the chat room or if the To header 573 field cannot be resolved (e.g., caused by a mistyped URI), the MSRP 574 switch MUST reject the request with a 404 response. This new 404 575 status code indicates a failure to resolve the recipient URI in the 576 To header field of the Message/CPIM wrapper. 578 Notice the importance of the From and To headers in the Message/ 579 CPIM wrapper. If an intermediary modifies these values, the MSRP 580 switch might not be able to identify the source or intended 581 destination of the message, resulting in a rejection of the 582 message. 584 Finally, the MSRP switch MUST verify that the recipient supports 585 private messages. If the recipient does not support private 586 messages, the MSRP switch MUST reject the request with a 428 587 response. This new response 428 indicates that the recipient does 588 not support private messages. Any potential REPORT request that the 589 MSRP switch sends to the sender MUST include a Message/CPIM wrapper 590 containing the original From header field included in the SEND 591 request and the To header field of the original Message/CPIM wrapper. 592 The MSRP switch MUST NOT forward private messages to a recipient that 593 does not support private messaging. 595 If successful, the MSRP switch should search its mapping table to 596 find the MSRP sessions established towards the recipient. If a match 597 is found the MSRP switch MUST create a SEND request and MUST copy the 598 contents of the sender's message to it. 600 An MSRP endpoint that receives a SEND request from the MSRP switch 601 does the same validations as for regular messages (Section 6.1). If 602 the To header field is different from the chat room URI, the MSRP 603 endpoints knows that this is a private message. The endpoint should 604 render who it is from based on the value of the From header of the 605 Message/CPIM wrapper. The endpoint can also use the sender's 606 nickname, possibly learned via a conference event package, to render 607 such nickname rather than the sender's actual URI. 609 It is possible that a participant, identified by a SIP Address of 610 Record or other valid URI, joins a conference of instant messages 611 from two or more different SIP UAs. It is RECOMMENDED that the MSRP 612 switch can map a URI to two or more MSRP sessions. If the policy of 613 the server allows for this, the MSRP switch MUST copy all messages 614 intended to the recipient through each MSRP session mapped to the 615 recipient's URI. 617 6.3. MSRP reports and responses 619 This section discusses the common procedures for regular and private 620 messages with respect to MSRP reports and responses. Any particular 621 procedure affecting only regular messages or only private messages is 622 discussed in the previous Section 6.1 or Section 6.2, respectively. 624 MSRP switches MUST follow the success report and failure report 625 handling described in section 7 of RFC 4975 [RFC4975], complemented 626 with the procedures described in this section. The MSRP switch MUST 627 act as an MSRP endpoint receiver of the request according to section 628 5.3 of RFC 4975 [RFC4975]. 630 If the MSRP switch receives an MSRP SEND request that does not 631 contain a Message/CPIM wrapper, the MSRP switch MUST reject the 632 request with a 415 response (specified in RFC 4975 [RFC4975]). 634 If the MSRP switch receives an MSRP SEND request where the URI 635 included in the From header field of the Message/CPIM wrapper is not 636 valid, (e.g, because it does not "belong" to the sender of the 637 message or is not a valid participant of the chat room), the MSRP 638 switch MUST reject the request with a 403 response. In non-error 639 cases, the MSRP switch MUST construct responses according to section 640 7.2 of RFC 4975 [RFC4975]. 642 When the MSRP switch forwards a SEND request, it MAY use any report 643 model in the copies intended for the recipients. The receiver 644 reports from the recipients MUST NOT be forwarded to the originator 645 of the original SEND request. This could lead to having the sender 646 receiving multiple reports for a single MSRP request. 648 7. Nicknames 650 A common characteristic of existing chat room services is that 651 participants have the ability to present themselves with a nickname 652 to the rest of the participants of the conference. It is used for 653 easy reference of participants in the chat room, and can also provide 654 anonymous participants with a meaningful descriptive name. 656 A nickname is a useful construct in many use cases, of which MSRP 657 chat is but one example. It is associated with a URI of which the 658 participant is known to the focus. Therefore, if a user joins the 659 chat room under the same URI from multiple devices, he or she may 660 request the same nickname across all these devices. 662 A nickname is a user selectable appearance of which the participant 663 wants to be known to the other participants. It is not a 'display- 664 name', but it is used somewhat like a display name. A main 665 difference is that a nickname is unique inside a chat room to allow 666 an unambiguous reference to a participant in the chat. Nicknames may 667 be long lived, or may be temporary. Users also need to reserve a 668 nickname prior to its utilization. 670 This memo specifies the nickname as a string. The nickname string 671 MUST be unambiguous within the scope of the chat room (conference 672 instance). This scope is similar to having a nickname unique inside 673 a chat room from Extensible Messaging and Presence Protocol 674 [RFC6120]. The chat room may have policies associated with 675 nicknames. It may not accept nickname strings at all, or a it may 676 provide a wider unambiguous scope like a domain or server, similar to 677 Internet Relay Chat (IRC) [RFC2810]. 679 7.1. Using Nicknames within a Conference 681 This memo provides a mechanism to reserve a nickname for a 682 participant for as long as the participant is logged into the chat 683 room. The mechanism is based on a NICKNAME MSRP method (see below) 684 and a new "Use-Nickname" header. Note that other mechanisms may 685 exist (for example, a web page reservation system), although they are 686 outside the scope of this document. 688 A conference participant who has established an MSRP session with the 689 MSRP switch, where the MSRP switch has indicated the support and 690 availability of nicknames with the 'nicknames' token in the 691 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP 692 switch. The NICKNAME request MUST include a new Use-Nickname header 693 that contains the nickname string that the participant wants to 694 reserve. MSRP NICKNAME requests MUST NOT include Success-Report or 695 Failure-Report header fields. 697 An MSRP switch that receives a NICKNAME request containing a nickname 698 in the Use-Nickname header field SHOULD first verify whether the 699 policy of the chat room allows the nickname functionality. If not 700 allowed, the MSRP switch MUST reject the request with a 501 response, 701 as per RFC 4975 [RFC4975]. 703 If the policy of the chat room allows the usage of nicknames, the 704 MSRP switch SHOULD validate that the SIP AOR is entitled to reserve 705 the nickname. This may include, e.g., allowing that the 706 participant's URI may use the same nickname when the participant has 707 joined the chat room from different devices under the same URI. The 708 participant's authenticated identifier can be derived after a 709 successful SIP Digest Authentication [RFC3261], be included in a 710 trusted SIP P-Asserted-Identity header field [RFC3325], be included 711 in a valid SIP Identity header field [RFC4474], or be derived from 712 any other present or future SIP authentication mechanism. Once the 713 MSRP switch has validated that the participant is entitled to reserve 714 the requested nickname, the MSRP switch MUST answer the NICKNAME 715 request with a 200 response as per regular MSRP procedures. 717 The reservation of a nickname can fail, e.g. if the NICKNAME request 718 contains a malformed or non-existent Use-Nickname header field, or if 719 the same nickname has already been reserved by another participant 720 (i.e., by another URI) in the chat room. The validation can also 721 fail where the sender of the message is not entitled to reserve the 722 nickname. In any of these cases the MSRP switch MUST answer the 723 NICKNAME request with a 423 response. The semantics of the 423 724 response are: "Nickname usage failed; the nickname is not allocated 725 to this user". 727 As indicated earlier, this specification defines a new MSRP header 728 field: "Use-Nickname". The Use-Nickname header field carries a 729 nickname string, and SHOULD be included in the NICKNAME requests. 731 The syntax of the NICKNAME method and the "Use-Nickname" header field 732 is built upon the MSRP formal syntax [RFC4975] 734 ext-method =/ NICKNAMEm 735 NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps 736 ext-header =/ Use-Nickname 737 ; ext-header defined in RFC 4975 738 Use-Nickname = "Use-Nickname:" SP nickname 739 nickname = quoted-string 740 ; quoted-string defined in RFC 4975 742 Once the MSRP switch has reserved a nickname and has bound it to a 743 URI (e.g., a SIP Address-of-Record), the MSRP server MAY allow the 744 usage of the same nickname by the same user (identified by the same 745 URI, such as a SIP AoR) over a second MSRP session. This might be 746 the case if the user joins the same chat room from a different SIP 747 User Agent. In this case, the user MAY request the same or a 748 different nickname than that used in conjunction with the first MSRP 749 session; the MSRP server MAY accept the usage of the same nickname by 750 the same user. The MSRP switch MUST NOT automatically assign the 751 same nickname to more than one MSRP session established from the same 752 URI, because this can create confusion to the user as whether the 753 same nickname is bound to the second MSRP session. 755 7.2. Modifying a Nickname 757 Typically a participant will reserve a nickname as soon as the 758 participant joins the chat room. But it is also possible for a 759 participant to modify his/her own nickname and replace it with a new 760 one at any time during the duration of the MSRP session. 761 Modification of the nickname is not different from the initial 762 reservation and usage of a nickname, thus the NICKNAME method is used 763 as described in Section 7.1. 765 If a NICKNAME request that attempts to modify the current nickname of 766 the user for some reason fails, the current nickname stays in effect. 767 A new nickname comes into effect and the old one is released only 768 after a NICKNAME request is accepted with a 200 response. 770 7.3. Removing a Nickname 772 If the participant no longer wants to be known by a nickname in the 773 conference, the participant can follow the method described in 774 Section 7.2. The nickname element of the Use-Nickname header MUST be 775 set to an empty quoted string. 777 7.4. Nicknames in Conference Event Packages 779 Typically the conference focus acts as a notifier of the conference 780 event package. To notify subscribers of the nickname reserved for a 781 given participant, it is RECOMMENDED that conference focus and 782 endpoints support Conference Event Package Data Format Extension for 783 Centralized Conferencing [I-D.ietf-xcon-event-package]. The 784 Conference Information Data Model for Centralized Conferencing 785 [I-D.ietf-xcon-common-data-model] extends the user element from RFC 786 4575 [RFC4575] with a 'nickname' attribute. 788 8. The SDP 'chatroom' attribute 790 There are a handful of use cases where a participant would like to 791 learn the chat room capabilities supported by the MSRP switch and the 792 chat room. For example, a participant would like to learn if the 793 MSRP switch supports private messaging, otherwise, the participant 794 may send what he believes is a private instant message addressed to a 795 participant, but since the MSRP switch does not support the functions 796 specified in this memo, the message gets eventually distributed to 797 all the participants of the chat room. 799 The reverse case also exists. A participant, say Alice, whose user 800 agent does not support the extensions defined by this document joins 801 the chat room. The MSRP switch learns that Alice's application does 802 not support private messaging nor nicknames. If another participant, 803 say Bob, sends a private message to Alice, the MSRP switch does not 804 distribute it to Alice, because Alice is not able to differentiate it 805 from a regular message sent to the whole roster. Furthermore, if 806 Alice replied to this message, she would do it to the whole roster. 807 Because of this, the MSRP switch also keeps track of users who do not 808 support the extensions defined in this document. 810 In another scenario, the policy of a chat room may indicate that 811 certain functions are not allowed. For example, the policy may 812 indicate that nicknames or private messages are not allowed. 814 In order to provide the user with a good chat room experience, we 815 define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a 816 media-level value attribute [RFC4566] that MAY be included in 817 conjunction with an MSRP media stream (i.e., when an m= line in SDP 818 indicates "TCP/MSRP" or "TCP/TLS/MSRP"). The 'chatroom' attribute 819 without further modifiers (e.g., chat-tokens) indicates that the 820 endpoint supports the procedures described in this document for 821 transferring MSRP messages to/from a multi-party conference. The 822 'chatroom' attribute can be complemented with additional modifiers 823 that further indicate the intersection of support and chat room local 824 policy allowance for a number of functions specified in this 825 document. Specifically, we provide the means for indicating support 826 to use nicknames and private messaging. 828 The 'chatroom' SDP attribute has the following Augmented BNF (ABNF) 829 [RFC5234] syntax: 831 attribute =/ chatroom-attr 832 ; attribute defined in RFC 4566 833 chatroom-attr = chatroom-label [":" chat-token 834 *(SP chat-token)] 835 chatroom-label = "chatroom" 836 chat-token = (nicknames-token / private-msg-token / 837 ext-token) 838 nicknames-token = "nickname" 839 private-msg-token = "private-messages" 840 ext-token = private-token / standard-token 841 private-token = toplabel "." *(domainlabel ".") token 842 ; toplabel defined in RFC 3261 843 ; domainlabel defined in RFC 3261 844 ; token defined in RFC 3261 845 standard-token = token 847 A given 'chat-token' value MUST NOT appear more than once in a 848 'chatroom' attribute. 850 A conference focus that includes the 'nicknames' token in the session 851 description is signaling that the MSRP switch supports and the chat 852 room allows to use the procedures specified in Section 7. A 853 conference focus that includes the 'private-messages' in the SDP 854 description is signaling that the MSRP switch supports and the chat 855 room allows to use the procedures specified in Section 6.2. 857 Example of the 'chatroom' attribute for an MSRP media stream that 858 indicates the acceptance of nicknames and private messages: 860 a=chatroom:nickname private-messages 862 An example of a 'chatroom' attribute for an MSRP media stream where 863 the endpoint, e.g., an MSRP switch, does not allow either nicknames 864 nor private messages. 866 a=chatroom 868 The 'chatroom' attribute allows extensibility with the addition of 869 new tokens. No IANA registry is provided at this time, since no 870 extensions are expected at the time of this writing. Extensions to 871 the 'chatroom' attribute can be defined in IETF documents or as 872 private vendor extensions. 874 Extensions defined in IETF document MUST follow the 'standard-token' 875 ABNF previously defined. In this type of extensions, are must be 876 taken in the selection of the token to avoid a clash with any of the 877 tokens previously defined. 879 Private extensions MUST follow the 'private-token' ABNF previously 880 defined. The 'private-token' MUST include the DNS name of the vendor 881 in reverse order in the token, in order to avoid clashes of tokens. 882 The following is an example of a "chat.foo" extension by vendor 883 "example.com" 885 a=chatroom:nickname private-messages com.example.chat.foo 887 9. Examples 889 9.1. Joining a chat room 891 Figure 3 presents a flow diagram where Alice joins a chat room by 892 sending an INVITE request. This INVITE request contains a session 893 description that includes the chatroom extensions defined in this 894 document. 896 Alice Conference focus 897 | | 898 |F1: (SIP) INVITE | 899 |----------------------->| 900 |F2: (SIP) 200 OK | 901 |<-----------------------| 902 |F3: (SIP) ACK | 903 |----------------------->| 904 | | 906 Figure 3: Flow diagram of a user joining a chat room 908 F1: Alice constructs an SDP description that includes an MSRP media 909 stream. She also indicates her support for the chatroom extensions 910 defined in this document. She sends the INVITE request to the chat 911 room server. 913 INVITE sip:chatroom22@chat.example.com SIP/2.0 914 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 915 Max-Forwards: 70 916 From: Alice ;tag=9fxced76sl 917 To: Chatroom 22 918 Call-ID: 3848276298220188511@atlanta.example.com 919 CSeq: 1 INVITE 920 Contact: 921 Content-Type: application/sdp 922 Content-Length: 290 924 v=0 925 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 926 s=- 927 c=IN IP4 client.atlanta.example.com 928 m=message 7654 TCP/MSRP * 929 a=accept-types:message/cpim text/plain text/html 930 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 931 a=chatroom:nickname private-messages 933 F2: The chat room server accepts the session establishment. It 934 includes the 'isfocus' and other relevant feature tags in the Contact 935 header field of the response. The chat room server also builds an 936 SDP answer that forces the reception of messages wrapped in Message/ 937 CPIM wrappers. It also includes the 'chatroom' attribute with the 938 allowed extensions. 940 SIP/2.0 200 OK 941 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 942 ;received=192.0.2.101 943 From: Alice ;tag=9fxced76sl 944 To: Chatroom 22 ;tag=8321234356 945 Call-ID: 3848276298220188511@atlanta.example.com 946 CSeq: 1 INVITE 947 Contact: \ 948 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \ 949 ;automata;isfocus;message;event="conference" 950 Content-Type: application/sdp 951 Content-Length: 290 953 v=0 954 o=chat 2890844527 2890844527 IN IP4 chat.example.com 955 s=- 956 c=IN IP4 chat.example.com 957 m=message 12763 TCP/MSRP * 958 a=accept-types:message/cpim 959 a=accept-wrapped-types:text/plain text/html * 960 a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 961 a=chatroom:nickname private-messages 963 F3: The session established is acknowledged (details not shown). 965 9.2. Setting up a nickname 967 Figure 4 shows an example of Alice setting up a nickname using the 968 conference as provider. Her first proposal is not accepted because 969 that proposed nickname is already in use. Then, she makes a second 970 proposal with a new nickname. This second proposal is accepted. 972 Alice MSRP switch 973 | | 974 |F1: (MSRP) NICKNAME | 975 |----------------------->| 976 |F2: (MSRP) 423 | 977 |<-----------------------| 978 |F3: (MSRP) NICKNAME | 979 |----------------------->| 980 |F4: (MSRP) 200 | 981 |<-----------------------| 982 | | 984 Figure 4: Flow diagram of a user setting up her nickname 986 F1: Alice sends an MSRP NICKNAME request that contains her proposed 987 nicknames in the Use-Nickname header field. 989 MSRP d93kswow NICKNAME 990 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 991 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 992 Use-Nickname: "Alice the great" 993 -------d93kswow$ 995 F2: The MSRP switch analyzes the existing allocation of nicknames and 996 detects that the nickname "Alice the great" is already provided to 997 another participant in the chat room. The MSRP switch answers with a 998 423 response. 1000 MSRP d93kswow 423 Nickname usage failed 1001 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1002 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1003 -------d93kswow$ 1005 F3: Alice receives the response. She proposes a new nickname in a 1006 second NICKNAME request. 1008 MSRP 09swk2d NICKNAME 1009 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1010 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1011 Use-Nickname: "Alice in Wonderland" 1012 -------09swk2d$ 1014 F4: The MSRP switch accepts the nickname proposal and answers with a 1015 200 response. 1017 MSRP 09swk2d 200 OK 1018 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1019 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1020 -------09swk2d$ 1022 9.3. Sending a regular message to the chat room 1024 Figure 5 depicts a flow diagram where Alice is sending a regular 1025 message addressed to the chat room. The MSRP switch distributes the 1026 message to the rest of the participants. 1028 Alice MSRP switch Bob Charlie 1029 | | | | 1030 | F1: (MSRP) SEND | | | 1031 |--------------------->| F3: (MSRP) SEND | | 1032 | F2: (MSRP) 200 |----------------------->| | 1033 |<---------------------| F4: (MSRP) SEND | | 1034 | |------------------------------->| 1035 | | F5: (MSRP) 200 OK | | 1036 | |<-----------------------| | 1037 | | F6: (MSRP) 200 OK | | 1038 | |<------------------------------ | 1039 | | | | 1040 | | | | 1042 Figure 5: Sending a regular message to the chat room 1044 F1: Alice builds a text message and wraps it in a Message/CPIM 1045 wrapper. She addresses the message to the chat room. She encloses 1046 the resulting Message/CPIM wrapper in an MSRP SEND request and sends 1047 it to the MSRP switch via the existing TCP connection. 1049 MSRP 3490visdm SEND 1050 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1051 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1052 Message-ID: 99s9s2 1053 Byte-Range: 1-*/* 1054 Content-Type: message/cpim 1056 To: 1057 From: 1058 DateTime: 2009-03-02T15:02:31-03:00 1059 Content-Type: text/plain 1061 Hello guys, how are you today? 1062 -------3490visdm$ 1064 F2: The MSRP switch acknowledges the reception of the SEND request 1065 with a 200 (OK) response. 1067 MSRP 3490visdm 200 OK 1068 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1069 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1070 Message-ID: 99s9s2 1071 -------3490visdm$ 1073 F3: The MSRP switch creates a new MSRP SEND request that contains the 1074 received Message/CPIM wrapper and sends it to Bob. 1076 MSRP 490ej23 SEND 1077 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1078 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1079 Message-ID: 304sse2 1080 Byte-Range: 1-*/* 1081 Content-Type: message/cpim 1083 To: 1084 From: 1085 DateTime: 2009-03-02T15:02:31-03:00 1086 Content-Type: text/plain 1088 Hello guys, how are you today? 1089 -------490ej23$ 1091 Since the received message is addressed to the chat room URI in the 1092 From header of the Message/CPIM header, Bob knows that this is a 1093 regular message distributed all participants in the chat room, rather 1094 that a private message addressed to him. 1096 The rest of the message flows are analogous to the previous. They 1097 are not shown here. 1099 9.4. Sending a private message to a participant 1101 Figure 6 depicts a flow diagram where Alice is sending a private 1102 message addressed to Bob's SIP AOR. The MSRP switch distributes the 1103 message only to Bob. 1105 Alice MSRP switch Bob 1106 | | | 1107 | F1: (MSRP) SEND | | 1108 |--------------------->| F3: (MSRP) SEND | 1109 | F2: (MSRP) 200 |----------------------->| 1110 |<---------------------| F4: (MSRP) 200 | 1111 | |<-----------------------| 1112 | | | 1114 Figure 6: Sending a private message to Bob 1116 F1: Alice builds a text message and wraps it in a Message/CPIM 1117 wrapper. She addresses the message to Bob's URI, which she learned 1118 from a notification in the conference event package. She encloses 1119 the resulting Message/CPIM wrapper in an MSRP SEND request and sends 1120 it to the MSRP switch via the existing TCP connection. 1122 MSRP 6959ssdf SEND 1123 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1124 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1125 Message-ID: okj3kw 1126 Byte-Range: 1-*/* 1127 Content-Type: message/cpim 1129 To: 1130 From: 1131 DateTime: 2009-03-02T15:02:31-03:00 1132 Content-Type: text/plain 1134 Hello Bob. 1135 -------6959ssdf$ 1137 F2: The MSRP switch acknowledges the reception of the SEND request 1138 with a 200 (OK) response. 1140 MSRP 6959ssdfm 200 OK 1141 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1142 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1143 Message-ID: okj3kw 1144 -------6959ssdfm$ 1145 F3: The MSRP switch creates a new MSRP SEND request that contains the 1146 received Message/CPIM wrapper and sends it only to Bob. Bob can 1147 distinguish the sender in the From header of the Message/CPIM 1148 wrapper. He also identifies this as a private message due to the 1149 presence of his own SIP AOR in the To header field of the Message/ 1150 CPIM wrapper. 1152 MSRP 9v9s2 SEND 1153 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1154 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1155 Message-ID: d9fghe982 1156 Byte-Range: 1-*/* 1157 Content-Type: message/cpim 1159 To: 1160 From: 1161 DateTime: 2009-03-02T15:02:31-03:00 1162 Content-Type: text/plain 1164 Hello Bob. 1165 -------9v9s2$ 1167 F4: Bob acknowledges the reception of the SEND request with a 200 1168 (OK) response. 1170 MSRP 9v9s2 200 OK 1171 To-Path: msrp://chat.example.com:5678/jofofo3;tcp 1172 From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1173 Message-ID: d9fghe982 1174 -------9v9s2$ 1176 9.5. Chunked private message 1178 The MSRP message below depicts the example of the same private 1179 message described in Section 9.4, but now the message is split in two 1180 chunks. The MSRP switch must wait for the complete set of Message/ 1181 CPIM headers before distributing the messages. 1183 MSRP 7443ruls SEND 1184 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1185 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1186 Message-ID: aft4to 1187 Byte-Range: 1-*/174 1188 Content-Type: message/cpim 1190 To: 1191 From: 1192 -------7443ruls$ 1194 MSRP 7443ruls SEND 1195 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1196 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1197 Message-ID: aft4to 1198 Byte-Range: 68-174/174 1199 Content-Type: message/cpim 1201 DateTime: 2009-03-02T15:02:31-03:00 1202 Content-Type: text/plain 1204 Hello Bob 1205 -------7443ruls$ 1207 9.6. Nickname in a conference information document 1209 Figure 7 depicts two user elements in a conference information 1210 document both having the nickname element with a nickname string. 1212 1213 1217 1220 1221 MSRP nickname example 1222 1223 1226 1227 2 1228 1229 1232 1233 1234 Dopey Donkey 1235 1236 1239 1240 Alice the great 1241 1242 1243 1245 Figure 7: Nickname in a conference information document 1247 10. IANA Considerations 1249 10.1. New MSRP Method 1251 This specification defines a new MSRP method to be added to the 1252 Methods sub-registry of the Message Session Relay Protocol (MSRP) 1253 Parameters registry: 1255 NICKNAME 1257 See section Section 7 for details. 1259 10.2. New MSRP Header 1261 This specification defines a new MSRP header to be added to the 1262 Header Field sub-registry of the Message Session Relay Protocol 1263 (MSRP) Parameters registry: 1265 Use-Nickname 1267 See Section 7 for details. 1269 10.3. New MSRP Status Codes 1271 This specification defines three new MSRP status codes to be added to 1272 the Status-Code sub-registry of the Message Session Relay Protocol 1273 (MSRP) parameters registry. 1275 The 404 status code indicates the failure to resolve the recipient 1276 URI in the To header field of the Message/CPIM wrapper in the SEND 1277 request, e.g, due to an unknown recipient. See Section 6.2 for 1278 details. 1280 The 423 response indicates a failure in allocating the requested 1281 NICKNAME. This can be caused by a malformed NICKNAME request (e.g., 1282 no Use-Nickname header field), an already allocated nickname, or a 1283 policy that prevents the sender to use nicknames. See Section 7 for 1284 details. 1286 The 428 status code indicates that the recipient of a SEND request 1287 does not support private messages. See Section 6.2 for details. 1289 Table 1 summarizes the IANA registration data with respect to new 1290 MSRP status codes: 1292 +-------+---------------------------------------+-----------+ 1293 | Value | Description | Reference | 1294 +-------+---------------------------------------+-----------+ 1295 | 404 | Failure to resolve recipient's URI | RFC XXXX | 1296 | 423 | Unable to allocate requested nickname | RFC XXXX | 1297 | 428 | Private messages not supported | RFC XXXX | 1298 +-------+---------------------------------------+-----------+ 1300 Table 1: New status codes 1302 10.4. New SDP Attribute 1304 This specification defines a new media-level attribute in the Session 1305 Description Protocol (SDP) Parameters registry. The registration 1306 data is as follows: 1308 Contact: Miguel Garcia 1310 Phone: +34 91 339 1000 1312 Attribute name: chatroom 1314 Long-form attribute name: Chat Room 1316 Type of attribute: media level only 1318 This attribute is not subject to the charset attribute 1320 Description: This attribute identifies support and local policy 1321 allowance for a number of chat room related functions 1323 Specification: RFC XXXX 1325 See section Section 8 for details. 1327 11. Security Considerations 1329 This document proposes extensions to the Message Session Relay 1330 Protocol [RFC4975]. Therefore, the security considerations of that 1331 document apply to this document as well. 1333 If the participant's SIP user agent doesn't understand the "isfocus" 1334 feature tag [RFC3840], it will not know that it is connected to a 1335 conference instance. The participant might not be notified that the 1336 participant's MSRP client will try to send messages to the MSRP 1337 switch having potentially multiple recipients. If the participant's 1338 MSRP client doesn't support the extensions of this specification, it 1339 is unlikely that it will try to send a message using 'Message/CPIM' 1340 wrapper content type [RFC3862], and the MSRP switch will reject the 1341 request with a 415 response [RFC4975]. Still if a participant's MSRP 1342 client does create a message with a valid 'Message/CPIM' wrapper 1343 content type [RFC3862] having the To header set to the URI of the 1344 chat room and the From header set to the URI of which the participant 1345 is known to the conference, the participant might be unaware that the 1346 message can be forwarded to multiple recipients. Equally if the To 1347 header is set to a valid URI of a recipient known to the conference, 1348 the message can be forwarded as a private message without the 1349 participant knowing. 1351 If a participant wants to avoid eavesdropping, the participant's MSRP 1352 client can send the messages over a TLS [RFC5246] transport 1353 connection, as allowed by MSRP. It's up to the policy of the MSRP 1354 switch if the messages are forwarded to the other participant's in 1355 the chat room using TLS [RFC5246] transport. 1357 Nicknames will be used to show the appearances of the participants of 1358 the conference. A successful take over of a nickname from a 1359 participant might lead to private messages to be sent to the wrong 1360 destination. The recipient's URI will be different from the URI 1361 associated to the original owner of the nickname, but the sender 1362 might not notice this. To avoid takeovers the MSRP switch MUST make 1363 sure that a nickname is unique inside a chat room. Also the security 1364 consideration for any authenticated identity mechanisms used to 1365 validate the SIP AOR will apply to this document as well. If a 1366 nickname can be reserved if it previously has been used by another 1367 participant in the chat room, is up to the policy of the chat room. 1369 12. Contributors 1371 This work would have never been possible without the fruitful 1372 discussions in the SIMPLE WG mailing list, specially with Brian Rosen 1373 (Neustar) and Paul Kyzivat (Cisco), who provided extensive review and 1374 improvements throughout the document. 1376 13. Acknowledgments 1378 The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, 1379 Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrian 1380 Georgescu, Nancy Greene, and Flemming Andreasen for providing 1381 comments. 1383 14. References 1385 14.1. Normative References 1387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1388 Requirement Levels", BCP 14, RFC 2119, March 1997. 1390 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1391 A., Peterson, J., Sparks, R., Handley, M., and E. 1392 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1393 June 2002. 1395 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1396 "Indicating User Agent Capabilities in the Session 1397 Initiation Protocol (SIP)", RFC 3840, August 2004. 1399 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1400 (CPIM)", RFC 3860, August 2004. 1402 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1403 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1405 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1406 Session Initiation Protocol (SIP)", RFC 4353, 1407 February 2006. 1409 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1410 Description Protocol", RFC 4566, July 2006. 1412 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1413 Initiation Protocol (SIP) Event Package for Conference 1414 State", RFC 4575, August 2006. 1416 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1417 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1419 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1420 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1421 September 2007. 1423 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1424 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1426 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 1427 Centralized Conferencing", RFC 5239, June 2008. 1429 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1430 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1432 [I-D.ietf-xcon-common-data-model] 1433 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 1434 "Conference Information Data Model for Centralized 1435 Conferencing (XCON)", draft-ietf-xcon-common-data-model-32 1436 (work in progress), September 2011. 1438 [I-D.ietf-xcon-event-package] 1439 Camarillo, G., Srinivasan, S., Even, R., and J. 1440 Urpalainen, "Conference Event Package Data Format 1441 Extension for Centralized Conferencing (XCON)", 1442 draft-ietf-xcon-event-package-01 (work in progress), 1443 September 2008. 1445 14.2. Informative References 1447 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1448 April 2000. 1450 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1451 Extensions to the Session Initiation Protocol (SIP) for 1452 Asserted Identity within Trusted Networks", RFC 3325, 1453 November 2002. 1455 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1456 RFC 3966, December 2004. 1458 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1459 Authenticated Identity Management in the Session 1460 Initiation Protocol (SIP)", RFC 4474, August 2006. 1462 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1463 Protocol (XMPP): Core", RFC 6120, March 2011. 1465 Authors' Addresses 1467 Aki Niemi 1468 Nokia 1469 P.O. Box 407 1470 NOKIA GROUP, FIN 00045 1471 Finland 1473 Phone: +358 50 389 1644 1474 Email: aki.niemi@nokia.com 1476 Miguel A. Garcia-Martin 1477 Ericsson 1478 Calle Via de los Poblados 13 1479 Madrid, ES 28033 1480 Spain 1482 Email: miguel.a.garcia@ericsson.com 1483 Geir A. Sandbakken (editor) 1484 Cisco Systems 1485 Philip Pedersens vei 20 1486 N-1366 Lysaker 1487 Norway 1489 Phone: +47 67 125 125 1490 Email: geirsand@cisco.com 1491 URI: http://www.cisco.com