idnits 2.17.1 draft-ietf-simple-chat-10.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 : ---------------------------------------------------------------------------- No issues found here. 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 (September 20, 2011) is 4602 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 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: March 23, 2012 Ericsson 6 G. Sandbakken, Ed. 7 Cisco Systems 8 September 20, 2011 10 Multi-party Chat Using the Message Session Relay Protocol (MSRP) 11 draft-ietf-simple-chat-10 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 March 23, 2012. 39 Copyright Notice 41 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 19 88 9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 21 89 9.3. Sending a regular message to the chat room . . . . . . . . 22 90 9.4. Sending a private message to a participant . . . . . . . . 24 91 9.5. Chuncked private message . . . . . . . . . . . . . . . . . 26 92 9.6. Nickname in a conference information document . . . . . . 26 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 94 10.1. New MSRP Method . . . . . . . . . . . . . . . . . . . . . 27 95 10.2. New MSRP Header . . . . . . . . . . . . . . . . . . . . . 28 96 10.3. New MSRP Status Codes . . . . . . . . . . . . . . . . . . 28 97 10.4. New SDP Attribute . . . . . . . . . . . . . . . . . . . . 29 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 99 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 14.1. Normative References . . . . . . . . . . . . . . . . . . . 30 103 14.2. Informative References . . . . . . . . . . . . . . . . . . 32 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 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) [RFC3264] 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 identity 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 identity 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]. It is expected 143 that future mechanisms will be developed for providing similar 144 functionality in generic conferences, i.e., where the media is not 145 only restricted to MSRP. The mechanisms described in this document 146 provide a future compatible short-term solution for MSRP centralized 147 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 allow 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 identities of the sender and recipient of the received IMs. 233 REQ-3: A conference participant must be able to determine the 234 recipient of the received message. For instance, the 235 recipient of the message might be the entire conference or a 236 single participant of the conference (i.e., a private 237 message). 239 REQ-4: It must be possible to send a message to a single participant 240 within the conference (i.e., a private instant message). 242 REQ-5: A conference participant may have a nickname or pseudonym 243 associated with their real identity. 245 REQ-6: It must be possible for a participant to change their 246 nickname during the progress of the conference. 248 REQ-7: It must be possible that a participant is only known by an 249 anonymous identity and not their real identity to the rest of 250 the conference. 252 REQ-8: It must be possible for the conference participants to learn 253 the chat room capabilities described in this document. 255 4. Overview of Operation 257 In order to set up a conference, one must first be created. Users 258 wishing to host a conference themselves can of course do just that; 259 their User Agent (UA) simply morphs from an ordinary UA into a 260 special purpose one called a Focus UA. Another, commonly used setup 261 is one where a dedicated node in the network functions as a Focus UA. 263 Each chat room has an identity of its own: a SIP URI that 264 participants use to join the conference, e.g. by sending an INVITE 265 request. The conference focus processes the invitations, and as 266 such, maintains SIP dialogs with each participant. In a multi-party 267 chat, or chat room, MSRP is one of the established media streams. 268 Each conference participant establishes an MSRP session with the MSRP 269 switch, which is a special purpose MSRP application. The MSRP 270 sessions can be relayed by one or more MSRP relays, which are 271 specified in RFC 4976 [RFC4976]. This is illustrated in Figure 1 272 MSRP Sessions 273 +---------------------------+ 274 | +-----------+ | 275 +---+--+ +---+--+ | | 276 | SIP | | SIP | | | 277 | MSRP | | MSRP | +--+---+----+ 278 |Client| |Client| | MSRP | 279 +---+--+ ++-----+ | Relay | 280 | | +-----+-----+ 281 SIP Dialogs | / | 282 | | | MSRP Sessions 283 +----+------+--+ | 284 | Conference | +-------+-----+ 285 | Focus UA | | MSRP | 286 | |........| Switch | 287 | | | | 288 +---+--------+-+ +-------+-----+ 289 | \ | 290 SIP Dialogs | | | MSRP Sessions 291 | \ | 292 +--+---+ +-+----+ +-----+------+ 293 | SIP | | SIP | | MSRP | 294 | MSRP | | MSRP | | Relay | 295 |Client| |Client| +-+-------+--+ 296 +---+--+ +--+---+ | | 297 | +-----------+ | 298 +------------------------------+ 299 MSRP sessions 301 Figure 1: Multi-party chat overview shown with MSRP Relays and a 302 conference Focus UA 304 The MSRP switch is similar to a conference mixer in that it handles 305 media sessions with each of the participants and bridges these 306 streams together. However, unlike a conference mixer, the MSRP 307 switch merely forwards messages between participants but doesn't 308 actually mix the streams in any way. The system is illustrated in 309 Figure 2. 311 +------+ 312 | MSRP | 313 |Client| 314 +------+ +--.---+ +------+ 315 | MSRP | | | MSRP | 316 |Client| | _|Client| 317 +------._ | ,' +------+ 318 `._ | ,' 319 `.. +----------+ ,' 320 `| |' 321 | MSRP | 322 | Switch | 323 ,| |_ 324 _,-'' +----------+ ``-._ 325 +------.-' | `--+------+ 326 | MSRP | | | MSRP | 327 |Client| | |Client| 328 +------+ | +------+ 329 +---'--+ 330 | MSRP | 331 |Client| 332 +------+ 334 Figure 2: Multi-party chat in a Centralized Conference 336 Typically conference participants also subscribe to a conference 337 event package to gather information about the conference roster in 338 the form of conference state notifications. For example, 339 participants can learn about other participants' identities, 340 including their nicknames. 342 All messages in the chat room use the 'Message/CPIM' wrapper content 343 type [RFC3862], so that it is possible to distinguish between private 344 and regular messages. When a participant wants to send an instant 345 message to the conference, it constructs an MSRP SEND request and 346 submits it to the MSRP switch including a regular payload (e.g. a 347 Message/CPIM message that contains a text, HTML, an image, etc.). 348 The Message/CPIM To header is set to the chat room URI. The switch 349 then fans out the SEND request to all of the other participants using 350 their existing MSRP sessions. 352 A participant can also send a private instant message addressed to a 353 participant whose identity has been learned, e.g. via a conference 354 event package. In this case the sender creates an MSRP SEND request 355 with a Message/CPIM body whose To header contains not the chat room 356 URI but the recipient's URI. The MSRP switch then forwards the SEND 357 request to that recipient. This specification supports the sending 358 of private messages to one and only one recipient. However, if the 359 recipient is logged from different endpoints, the MSRP switch will 360 distribute the private message to each endpoint the recipient is 361 logged. 363 We extend the current MSRP negotiation that takes place in SDP 364 [RFC4566] to allow participants to learn whether the chat room 365 supports and is willing to accept (e.g. due to local policy 366 restrictions) certain MSRP functions defined in this memo, such as 367 nicknames or private messaging. 369 Naturally, when a participant wishes to leave a chat room, it sends a 370 SIP BYE request to the Focus UA and terminates the SIP dialog with 371 the focus and MSRP sessions with the MSRP switch. 373 This document assumes that each chat room is allocated its own SIP 374 URI. A user joining a chat room sends an INVITE request to that SIP 375 URI, and as a result, a new MSRP session is established between the 376 user and the MSRP switch. It is assumed that an MSRP session is 377 mapped to a chat room. If a user wants to join a second chat room, 378 he creates a different INVITE request, through a different SIP 379 dialog, which leads to the creation of a second MSRP session between 380 the user and the MSRP switch. Notice that these two MSRP sessions 381 can still be multiplexed over the same TCP connection as per regular 382 MSRP procedures. However, each chat room is associated to a unique 383 MSRP session and a unique SIP dialog. 385 5. Creating, Joining, and Deleting a Chat Room 387 5.1. Creating a Chat Room 389 Since we consider a chat room a particular type of conference having 390 MSRP media, the methods defined by the SIP Conference Framework 391 [RFC4353] for creating conferences are directly applicable to a chat 392 room. 394 Once a chat room is created, it is identified by a SIP URI, like any 395 other conference. 397 5.2. Joining a Chat Room 399 Participants usually join the conference by sending an INVITE request 400 to the conference URI. As long as the conference policy allows, the 401 INVITE request is accepted by the focus and the user is brought into 402 the conference. 404 The MSRP switch needs to be aware of the URIs of the participant 405 (SIP, Tel, or IM URIs) in order to validate messages sent from this 406 participant prior to their forwarding. This information is known to 407 the focus of the conference. Therefore an interface between the 408 focus and the MSRP switch is assumed. However, the interface between 409 the focus and the MSRP switch is outside the scope of this document. 411 Conference aware participants will detect that the peer is a focus 412 due to the presence of the "isfocus" feature tag [RFC3840] in the 413 Contact header field of the 200-class response to the INVITE request. 414 Conference unaware participants will not notice it is a focus, and 415 can not apply the additional mechanisms defined in this document. 416 Participants are also aware that the mixer is an MSRP switch due to 417 the presence of a 'message' media type and either TCP/MSRP or TCP/ 418 TLS/MSRP as the protocol field in the media line of SDP [RFC4566]. 420 The conference focus of a chat room MUST include support for a 421 Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by 422 setting the 'accept-types' MSRP media line attribute in the SDP offer 423 or answer to include 'Message/CPIM'. 425 Note that the 'Message/CPIM' wrapper is used to carry the sender 426 information that, otherwise, it will not be available to the 427 recipient. Additionally, 'Message/CPIM' wrapper carries the 428 recipient information (e.g. To and Cc: headers). 430 If a participant wants to remain anonymous to the rest of the 431 participants in the conference, the participant's UA must provide an 432 anonymous URI to the conference focus. The URI will be used in the 433 From and To headers in the 'Message/CPIM' wrapper, and can be learned 434 by the other participants of the conference. Notice that in order 435 for the anonymity mechanism to work, the anonymous URI must not 436 reveal the participant's SIP AOR. The mechanism for acquiring an 437 anonymous URI is outside the scope of this specification. 439 The conference focus of a chat room MUST learn the chat room 440 capabilities of each participant that joins the chat room. The 441 conference focus MUST inform the MSRP switch of such support in order 442 to prevent the MSRP switch from distributing private messages to 443 participants who do not support private messaging. The recipient 444 would not be able to render the message as private, and any potential 445 reply would be sent to the whole chat room. 447 5.3. Deleting a Chat Room 449 As with creating a conference, the methods defined by the SIP 450 Conference Framework [RFC4353] for deleting a conference are directly 451 applicable to a chat room. The MSRP switch will terminate the MSRP 452 sessions with all the participants. 454 Deleting a chat room is an action that heavily depends on the policy 455 of the chat room. The policy can determine that the chat room is 456 deleted when the creator leaves the conference, or with any out of 457 band mechanism. 459 6. Sending and Receiving Instant Messages 461 6.1. Regular Messages 463 This section describes the conventions used to send and receive 464 instant messages that are addressed to all the participants in the 465 chat room. These are sent over a regular MSRP SEND request that 466 contains a Message/CPIM wrapper [RFC3862] that in turn contains the 467 desired payload (e.g. text, image, video-clip, etc.). 469 When a chat room participant wishes to send an instant message to all 470 the other participants in the chat room, it constructs an MSRP SEND 471 request according to the procedures specified in RFC 4975 [RFC4975]. 472 The sender MAY choose the desired MSRP report model (e.g., populate 473 the Success-Report and Failure-Report MSRP header fields). 475 The SEND request MUST contain a top-level wrapper of type 'Message/ 476 CPIM' according to RFC 3862 [RFC3862]. The actual instant message 477 payload MUST be included as payload of the 'Message/CPIM' wrapper and 478 MAY be of any type negotiated in the SDP 'accept-types' attribute 479 according to the MSRP rules. 481 On sending a regular message the sender MUST populate the To header 482 of the Message/CPIM wrapper with the URI of the chat room. The 483 sender SHOULD populate the From header of the Message/CPIM wrapper 484 with a proper identity by which the user is recognized in the 485 conference. Identities that can be used (among others) are: 487 o A SIP URI [RFC3261] representing the participant's address-of- 488 record 490 o A tel URI [RFC3966] representing the participant's telephone 491 number 493 o An IM URI [RFC3860] representing the participant's instant 494 messaging address 496 o An Anonymous URI representing the participant's anonymous address 498 An MSRP switch that receives a SEND request from a participant SHOULD 499 first verify that the From header field of the Message/CPIM wrapper 500 is correctly populated with a valid URI of a participant. This 501 imposes a requirement for the focus of the conference to inform the 502 MSRP switch the URIs which the participant is known, in order for the 503 MSRP switch to validate messages. Section 6.3 provides further 504 information with the actions to be taken in case this validation 505 fails. 507 If the MSRP switch receives a message containing several To header 508 fields in the Message/CPIM wrapper the MSRP switch MUST reject the 509 MSRP SEND request with a 403 response, as per procedures in RFC 4975 510 [RFC4975]. 512 Then the MSRP switch should inspect the To header field of the 513 Message/CPIM wrapper. If the To header field of the Message/CPIM 514 wrapper contains the chat room URI and there are no other To header 515 fields, the MSRP switch can generate a copy of the SEND request to 516 each of the participants in the conference except the sender. The 517 MSRP switch MUST NOT modify the content received in the SEND request. 518 However, the MSRP switch MAY re-chunk any of the outbound MSRP SEND 519 requests. 521 Note that the MSRP switch does not need to wait for the reception of 522 the complete MSRP chunk or MSRP message before it starts the 523 distribution to the rest of the participants. Instead, once the MSRP 524 switch has received the headers of the Message/CPIM body it SHOULD 525 start the distribution process. Having the Message/CPIM header only 526 in the first chunk, the MSRP switch MUST track the Message-Id until 527 the last chunk of the message has been distributed. 529 An MSRP endpoint that receives a SEND request from the MSRP switch 530 containing a Message/CPIM wrapper SHOULD first inspect the To header 531 field of the Message/CPIM body. If the To header field is set to the 532 chat room URI, it should render it as a regular message that has been 533 distributed to all the participants in the conference. Then the MSRP 534 endpoint SHOULD inspect the From header field of the Message/CPIM 535 body to identify the sender. The From header field will include a 536 URI that identifies the sender. The endpoint might have also 537 received further identity information through a subscription to a 538 conference event package. 540 6.2. Private Messages 542 This section describes the conventions used to send and receive 543 private instant messages, i.e., instant messages that are addressed 544 to one participant of the chat room rather to all of them. A chat 545 room can signal support for private messages using the chatroom- 546 attribute (see Section 8 for details). 548 When a chat room participant wishes to send a private instant message 549 to a participant the chat room, it follows the same procedures for 550 creating a SEND request as for regular messages (Section 6.1). The 551 only difference is that the MSRP endpoint MUST populate a single To 552 header of the Message/CPIM with the identity of the intended 553 recipient. The identity can be SIP, TEL, and IM URIs typically 554 learned from the information received in notifications of a 555 conference event package. 557 As for regular messages, an MSRP switch that receives a SEND request 558 from a participant SHOULD first verify that the From header field of 559 the Message/CPIM wrapper is correctly populated with a valid URI 560 (i.e., the URI is a participant of this chat room). Section 6.3 561 provides further information with the actions to be taken in case 562 this validation fails. 564 If the MSRP switch receives a message containing several To header 565 fields in the Message/CPIM wrapper the MSRP switch MUST reject the 566 MSRP SEND request with a 403 response, as per procedures in RFC 4975 567 [RFC4975]. 569 Then the MSRP switch MUST verify that the To header of the Message/ 570 CPIM wrapper is a participant of the chat room. If this To header 571 field does not contain the URI of a participant of the chat room or 572 if the To header field cannot be resolved (e.g., caused by a mistyped 573 URI), the MSRP switch MUST reject the request with a 404 response. 574 This new 404 status code indicates a failure to resolve the recipient 575 URI in the To header field of the Message/CPIM wrapper. 577 Notice the importance of the From and To headers in the Message/ 578 CPIM wrapper. If an intermediary modifies these values, the MSRP 579 switch might not be able to identify the source or intended 580 destination of the message, resulting in a rejection of the 581 message. 583 Finally, the MSRP switch MUST verify that the recipient supports 584 private messages. If the recipient does not support private 585 messages, the MSRP switch MUST reject the request with a 428 586 response. This new response 428 indicate that the recipient does not 587 support private messages. Any potential REPORT request that the MSRP 588 switch sends to the sender MUST include a Message/CPIM wrapper 589 containing the original From header field included in the SEND 590 request and the To header field of the original Message/CPIM wrapper. 591 The MSRP switch MUST NOT forward private messages to a recipient that 592 does not support private messaging. 594 If successful, the MSRP switch should search its mapping table to 595 find the MSRP sessions established towards the recipient. If a match 596 is found the MSRP switch MUST create a SEND request and MUST copy the 597 contents of the sender's message to it. 599 An MSRP endpoint that receives a SEND request from the MSRP switch 600 does the same validations as for regular messages (Section 6.1). If 601 the To header field is different from the chat room URI, the MSRP 602 endpoints knows that this is a private message. The endpoint should 603 render who it is from based on the value of the From header of the 604 Message/CPIM wrapper. The endpoint can also use the sender's 605 nickname, possibly learned via a conference event package, to render 606 such nickname rather than the sender's actual URI. 608 It is possible that a participant, identified by a SIP Address of 609 Record or other valid URI, joins a conference of instant messages 610 from two or more different SIP UAs. It is RECOMMENDED that the the 611 MSRP switch can map a URI to two or more MSRP sessions. If the 612 policy of the server allows for this, the MSRP switch MUST copy all 613 messages intended to the recipient through each MSRP session mapped 614 to the recipient's URI. 616 6.3. MSRP reports and responses 618 This section discusses the common procedures for regular and private 619 messages with respect to MSRP reports and responses. Any particular 620 procedure affecting only regular messages or only private messages is 621 discussed in the previous Section 6.1 or Section 6.2, respectively. 623 MSRP switches MUST follow the success report and failure report 624 handling described in section 7 of RFC 4975 [RFC4975], complemented 625 with the procedures described in this section. The MSRP switch MUST 626 act as an MSRP endpoint receiver of the request according to section 627 5.3 of RFC 4975 [RFC4975]. 629 If the MSRP switch receives an MSRP SEND request that does not 630 contain a Message/CPIM wrapper, the MSRP switch MUST reject the 631 request with a 415 response (specified in RFC 4975 [RFC4975]). 633 If the MSRP switch receives an MSRP SEND request where the URI 634 included in the From header field of the Message/CPIM wrapper is not 635 valid, (e.g, because it does not "belong" to the sender of the 636 message or is not a valid participant of the chat room), the MSRP 637 switch MUST reject the request with a 403 response. In non-error 638 cases, the MSRP switch MUST construct responses according to section 639 7.2 of RFC 4975 [RFC4975]. 641 When the MSRP swtich forwards a SEND request, it MAY use any report 642 model in the copies intended for the recipients. The receiver 643 reports from the recipients MUST NOT be forwarded to the originator 644 of the original SEND request. This could lead to having the sender 645 receiving multiple reports for a single MSRP request. 647 7. Nicknames 649 A common characteristic of existing chat room services is that 650 participants have the ability to present themselves with a nickname 651 to the rest of the participants of the conference. It is used for 652 easy reference of participants in the chat room, and can also provide 653 anonymous participants with a meaningful descriptive name. 655 A nickname is a useful construct in many use cases, of which MSRP 656 chat is but one example. It is associated with a URI of which the 657 participant is known to the focus. It is a user selectable 658 appearance of which the participant wants to be known to the other 659 participants. It is not a 'display-name', but it is used somewhat 660 like a display name. A main difference is that a nickname is unique 661 inside a chat room to allow an unambiguous reference to a participant 662 in the chat. Nicknames may be long lived, or may be temporary. 663 Users also need to reserve a nickname prior to its utilization. 665 This memo specifies the nickname as a string. The nickname string 666 MUST be unambiguous within the scope of the chat room (conference 667 instance). This scope is similar to having a nickname unique inside 668 a chat room from Extensible Messaging and Presence Protocol 669 [RFC6120]. The chat room may have policies associated with 670 nicknames. It may not accept nickname strings at all, or a it may 671 provide a wider unambiguous scope like a domain or server, similar to 672 Internet Relay Chat (IRC) [RFC2810]. 674 7.1. Using Nicknames within a Conference 676 This memo provides a mechanism to reserve a nickname for a 677 participant for as long as the participant is logged into the chat 678 room. The mechanism is based on a NICKNAME MSRP method (see below) 679 and a new "Use-Nickname" header. Note that other mechanisms may 680 exist (for example, a web page reservation system), although they are 681 outside the scope of this document. 683 A conference participant who has established an MSRP session with the 684 MSRP switch, where the MSRP switch has indicated the support and 685 availability of nicknames with the 'nicknames' token in the 686 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP 687 switch. The NICKNAME request MUST include a new Use-Nickname header 688 that contains the nickname string that the participant wants to 689 reserve. MSRP NICKNAME requests MUST NOT include Success-Report or 690 Failure-Report header fields. 692 The MSRP switch that receives a NICKNAME request containing a 693 nickname in the Use-Nickname header field SHOULD first verify whether 694 the policy of the chat room allows the nickname functionality. If 695 not allowed, the MSRP switch must reject the request with a 501 696 response, as per RFC 4975 [RFC4975]. 698 If the policy of the chat room allows the usage of nicknames, the 699 MSRP switch SHOULD validate that the SIP AOR is entitled to reserve 700 the nickname. The participant's authenticated identity can be 701 derived after a successful HTTP Digest Authentication (applied to 702 SIP), included in a trusted SIP P-Asserted-Identity header field, 703 included in a valid SIP Identity header field, or derived from any 704 other present or future SIP authentication mechanism. Once the MSRP 705 switch has validated that the participant is entitled to reserve the 706 nickname, the MSRP switch MUST answer the NICKNAME request with a 200 707 response as per regular MSRP procedures. 709 The reservation of a nickname can fail, e.g. if the NICKNAME request 710 contains a malformed or non-existent Use-Nickname header field, or if 711 the same nickname has already been reserved by another participant in 712 the conference. The validation can also fail where the sender of the 713 message is not entitled to reserve the nickname. In any of these 714 cases the MSRP switch MUST answer the NICKNAME request with a 423 715 response. The semantics of the 423 response are: "Nickname usage 716 failed; the nickname is not allocated to this user". 718 As indicated earlier, this specification defines a new MSRP header 719 field: "Use-Nickname". The Use-Nickname header field carries a 720 nickname string, and SHOULD be included in the NICKNAME requests. 722 The syntax of the NICKNAME method and the "Use-Nickname" header field 723 is built upon the MSRP formal syntax [RFC4975] 725 ext-method =/ NICKNAMEm 726 NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps 727 ext-header =/ Use-Nickname 728 ; ext-header is specified in RFC 4975 729 Use-Nickname = "Use-Nickname" ":" nickname 730 nickname = quoted-string 732 7.2. Modifying a Nickname 734 Typically a participant will reserve a nickname as soon as the 735 participant joins the chat room. But it is also possible for a 736 participant to modify his/her own nickname and replace it with a new 737 one at any time during the duration of the MSRP session. 738 Modification of the nickname is not different from the initial 739 reservation and usage of a nickname, thus the NICKNAME method is used 740 as described in Section 7.1. 742 If a NICKNAME request that attempts to modify the current nickname of 743 the user for some reason fails, the current nickname stays in effect. 744 A new nickname comes into effect and the old one is released only 745 after a NICKNAME request is accepted with a 200 response. 747 7.3. Removing a Nickname 749 If the participant no longer wants to be known by a nickname in the 750 conference, the participant can follow the method described in 751 Section 7.2. The nickname element of the Use-Nickname header MUST be 752 set to an empty quoted string. 754 7.4. Nicknames in Conference Event Packages 756 Typically the conference focus acts as a notifier of the conference 757 event package. To notify subscribers of the nickname reserved for a 758 given participant, it is RECOMMENDED that conference focus and 759 endpoints support Conference Event Package Data Format Extension for 760 Centralized Conferencing [I-D.ietf-xcon-event-package]. The 761 Conference Information Data Model for Centralized Conferencing 762 [I-D.ietf-xcon-common-data-model] extends the user element from RFC 763 4575 [RFC4575] with a nickname attribute. 765 8. The SDP 'chatroom' attribute 767 There are a handful of use cases where a participant would like to 768 learn the chat room capabilities supported by the MSRP switch and the 769 chat room. For example, a participant would like to learn if the 770 MSRP switch supports private messaging, otherwise, the participant 771 may send what he believes is a private instant message addressed to a 772 participant, but since the MSRP switch does not support the functions 773 specified in this memo, the message gets eventually distributed to 774 all the participants of the chat room. 776 The reverse case also exists. A participant, say Alice, whose user 777 agent does not support the extensions defined by this document joins 778 the chat room. The MSRP switch learns that Alice application does 779 not support private messaging nor nicknames. If another participant, 780 say Bob, sends a private message to Alice, the MSRP switch does not 781 distribute it to Alice, because Alice is not able to differentiate it 782 from a regular message sent to the whole roster. Further more, if 783 Alice replied to this message, she would do it to the whole roster. 784 Because of this, the MSRP switch keeps also track of users who do not 785 support the extensions defined in this document. 787 In another scenario, the policy of a chat room may indicate that 788 certain functions are not allowed. For example, the policy may 789 indicate that nicknames or private messages are not allowed. 791 In order to provide the user with a good chat room experience, we 792 define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a 793 media-level attribute that MAY be included in conjunction with and 794 MSRP media stream (i.e., when an m= line in SDP indicates "TCP/MSRP" 795 or "TCP/TLS/MSRP"). The 'chatroom' attribute indicates the 796 intersection of support and chat room local policy allowance for a 797 number of functions specified in this document. Specifically, we 798 provide the means for indicating support to use nicknames and private 799 messaging. 801 The 'chatroom' SDP attribute has the following syntax: 803 chatroom = chatroom-label ":" chat-token *(SP chat-token) 804 chatroom-label = "chatroom" 805 chat-token = (nicknames-token | private-msg-token | token) 806 nicknames-token = "nicknames" 807 private-msg-token = "private-messages" 809 A conference focus that includes the 'nicknames' token in the session 810 description is signaling that the MSRP switch supports and the chat 811 room allows to use of the procedures specified in Section 7. A 812 conference focus that includes the 'private-messages' in the SDP 813 description is signaling that the MSRP switch supports and the chat 814 room allows to use of the procedures specified in Section 6.2. 816 Example of the 'chatroom' attribute for an MSRP media stream that 817 indicates the acceptance of nicknames and private messages: 819 a=chatroom:nickname private-messages 821 9. Examples 823 9.1. Joining a chat room 825 Figure 3 presents a flow diagram where Alice joins a chat room by 826 sending an INVITE request. This INVITE request contains a session 827 description that includes the chatroom extensions defined in this 828 document. 830 Alice Conference focus 831 | | 832 |F1: (SIP) INVITE | 833 |----------------------->| 834 |F2: (SIP) 200 OK | 835 |<-----------------------| 836 |F3: (SIP) ACK | 837 |----------------------->| 838 | | 840 Figure 3: Flow diagram of a user joining a chat room 842 F1: Alice constructs an SDP description that includes an MSRP media 843 stream. She also indicates her support for the chatroom extensions 844 defined in this document. She sends the INVITE request to the chat 845 room server. 847 INVITE sip:chatroom22@chat.example.com SIP/2.0 848 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 849 Max-Forwards: 70 850 From: Alice ;tag=9fxced76sl 851 To: Chatroom 22 852 Call-ID: 3848276298220188511@atlanta.example.com 853 CSeq: 1 INVITE 854 Contact: 855 Content-Type: application/sdp 856 Content-Length: [length] 858 v=0 859 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 860 s=- 861 c=IN IP4 client.atlanta.example.com 862 m=message 7654 TCP/MSRP * 863 a=accept-types:message/cpim text/plain text/html 864 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 865 a=chatroom:nickname private-messages 867 F2: The chat room server accepts the session establishment. It 868 includes the 'isfocus' and other relevant feature tags in the Contact 869 header field of the response. The chat room server also builds an 870 SDP answer that also that forces the reception of messages wrapped in 871 Message/CPIM envelopes. It also includes the the chatroom attribute 872 with the allowed extensions. 874 SIP/2.0 200 OK 875 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 876 ;received=192.0.2.101 877 From: Alice ;tag=9fxced76sl 878 To: Chatroom 22 ;tag=8321234356 879 Call-ID: 3848276298220188511@atlanta.example.com 880 CSeq: 1 INVITE 881 Contact: \ 882 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \ 883 ;automata;isfocus;message;event="conference" 884 Content-Type: application/sdp 885 Content-Length: [length] 887 v=0 888 o=chat 2890844527 2890844527 IN IP4 chat.example.com 889 s=- 890 c=IN IP4 chat.example.com 891 m=message 12763 TCP/MSRP * 892 a=accept-types:message/cpim 893 a=accept-wrapped-types:text/plain text/html * 894 a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 895 a=chatroom:nickname private-messages 897 F3: The session established is acknowledged (details not shown). 899 9.2. Setting up a nickname 901 Figure 4 shows an example of Alice setting up a nickname using the 902 conference as provider. Her first proposal is not accepted because 903 the proposed nickname is already in use. Her second proposal is 904 accepted. 906 Alice MSRP switch 907 | | 908 |F1: (MSRP) NICKNAME | 909 |----------------------->| 910 |F2: (MSRP) 423 | 911 |<-----------------------| 912 |F3: (MSRP) NICKNAME | 913 |----------------------->| 914 |F4: (MSRP) 200 | 915 |<-----------------------| 916 | | 918 Figure 4: Flow diagram of a user setting up her nickname 920 F1: Alice sends an MSRP NICKNAME request that contains her proposed 921 nicknames in the Use-Nickname header field. 923 MSRP d93kswow NICKNAME 924 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 925 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 926 Use-Nickname: "Alice the great" 927 -------d93kswow$ 929 F2: The MSRP switch analyzes the existing allocation of nicknames and 930 detects that the nickname "Alice the great" is already provided to 931 another participant by the conference. The MSRP switch answers with 932 a 423 response. 934 MSRP d93kswow 423 Nickname usage failed 935 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 936 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 937 -------d93kswow$ 939 F3: Alice receives the response. She proposes a new nickname in a 940 second NICKNAME request. 942 MSRP 09swk2d NICKNAME 943 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 944 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 945 Use-Nickname: "Alice in Wonderland" 946 -------09swk2d$ 948 F4: The MSRP switch accepts the nickname proposal and answers with a 949 200 response. 951 MSRP 09swk2d 200 OK 952 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 953 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 954 -------09swk2d$ 956 9.3. Sending a regular message to the chat room 958 Figure 5 depicts a flow diagram where Alice is sending a regular 959 message addressed to the chat room. The MSRP switch distributes the 960 message to the rest of the participants. 962 Alice MSRP switch Bob Charlie 963 | | | | 964 | F1: (MSRP) SEND | | | 965 |--------------------->| F3: (MSRP) SEND | | 966 | F2: (MSRP) 200 |----------------------->| | 967 |<---------------------| F4: (MSRP) SEND | | 968 | |------------------------------->| 969 | | F5: (MSRP) 200 OK | | 970 | |<-----------------------| | 971 | | F6: (MSRP) 200 OK | | 972 | |<------------------------------ | 973 | | | | 974 | | | | 976 Figure 5: Sending a regular message to the chat room 978 F1: Alice builds a text message and wraps it in a CPIM message. She 979 addresses the CPIM message to the chat room. She encloses the result 980 in an MSRP SEND request and sends it to the MSRP switch via the 981 existing TCP connection. 983 MSRP 3490visdm SEND 984 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 985 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 986 Message-ID: 99s9s2 987 Byte-Range: 1-*/* 988 Content-Type: message/cpim 990 To: 991 From: 992 DateTime: 2009-03-02T15:02:31-03:00 993 Content-Type: text/plain 995 Hello guys, how are you today? 996 -------3490visdm$ 998 F2: The MSRP switch acknowledges the reception of the SEND request 999 with a 200 (OK) response. 1001 MSRP 3490visdm 200 OK 1002 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1003 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1004 Message-ID: 99s9s2 1005 -------3490visdm$ 1007 F3: The MSRP switch creates a new MSRP SEND request that contains the 1008 received Message/CPIM body and sends it to Bob. 1010 MSRP 490ej23 SEND 1011 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1012 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1013 Message-ID: 304sse2 1014 Byte-Range: 1-*/* 1015 Content-Type: message/cpim 1017 To: 1018 From: 1019 DateTime: 2009-03-02T15:02:31-03:00 1020 Content-Type: text/plain 1022 Hello guys, how are you today? 1023 -------490ej23$ 1025 The rest of the message flows are analogous to the previous. They 1026 are not shown here. 1028 9.4. Sending a private message to a participant 1030 Figure 6 depicts a flow diagram where Alice is sending a private 1031 message addressed to Bob's SIP AOR. The MSRP switch distributes the 1032 message only to Bob. 1034 Alice MSRP switch Bob 1035 | | | 1036 | F1: (MSRP) SEND | | 1037 |--------------------->| F3: (MSRP) SEND | 1038 | F2: (MSRP) 200 |----------------------->| 1039 |<---------------------| F4: (MSRP) 200 | 1040 | |<-----------------------| 1041 | | | 1043 Figure 6: Sending a private message to Bob 1045 F1: Alice builds a text message and wraps it in a CPIM message. She 1046 addresses the CPIM message to the Bob's URI, which she learned from a 1047 notification in the conference event package. She encloses the 1048 result in an MSRP SEND request and sends it to the MSRP switch via 1049 the existing TCP connection. 1051 MSRP 6959ssdf SEND 1052 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1053 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1054 Message-ID: okj3kw 1055 Byte-Range: 1-*/* 1056 Content-Type: message/cpim 1058 To: 1059 From: 1060 DateTime: 2009-03-02T15:02:31-03:00 1061 Content-Type: text/plain 1063 Hello Bob. 1064 -------6959ssdf$ 1066 F2: The MSRP switch acknowledges the reception of the SEND request 1067 with a 200 (OK) response. 1069 MSRP 6959ssdfm 200 OK 1070 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1071 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1072 Message-ID: okj3kw 1073 -------6959ssdfm$ 1075 F3: The MSRP switch creates a new MSRP SEND request that contains the 1076 received Message/CPIM body and sends it only to Bob. Bob can 1077 distinguish the sender in the From header of the CPIM message. He 1078 also identifies this as a private message due to the To CPIM header. 1080 MSRP 9v9s2 SEND 1081 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1082 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1083 Message-ID: d9fghe982 1084 Byte-Range: 1-*/* 1085 Content-Type: message/cpim 1087 To: 1088 From: 1089 DateTime: 2009-03-02T15:02:31-03:00 1090 Content-Type: text/plain 1092 Hello Bob. 1093 -------9v9s2$ 1095 F4: Bob acknowledges the reception of the SEND request with a 200 1096 (OK) response. 1098 MSRP 9v9s2 200 OK 1099 To-Path: msrp://chat.example.com:5678/jofofo3;tcp 1100 From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1101 Message-ID: d9fghe982 1102 -------9v9s2$ 1104 9.5. Chuncked private message 1106 The MSRP message below depicts an example of the private message in 1107 Section 9.4 split in two chuncks. The MSRP switch must wait for the 1108 complete set of CPIM headers before distributing the messages. 1110 MSRP 7443ruls SEND 1111 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1112 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1113 Message-ID: aft4to 1114 Byte-Range: 1-*/174 1115 Content-Type: message/cpim 1117 To: 1118 From: 1119 -------7443ruls$ 1121 MSRP 7443ruls SEND 1122 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1123 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1124 Message-ID: aft4to 1125 Byte-Range: 68-174/174 1126 Content-Type: message/cpim 1128 DateTime: 2009-03-02T15:02:31-03:00 1129 Content-Type: text/plain 1131 Hello Bob 1132 -------7443ruls$ 1134 9.6. Nickname in a conference information document 1136 Figure 7 depicts two user elements in a conference information 1137 document both having the nickname element with a nickname string. 1139 1140 1144 1147 1148 MSRP nickname example 1149 1150 1153 1154 2 1155 1156 1159 1160 1161 Dopey Donkey 1162 1163 1166 1167 Alice the great 1168 1169 1170 1172 Figure 7: Nickname in a conference information document 1174 10. IANA Considerations 1176 10.1. New MSRP Method 1178 This specification defines a new MSRP method to be added to the 1179 Methods sub-registry of the Message Session Relay Protocol (MSRP) 1180 Parameters registry: 1182 NICKNAME 1184 See section Section 7 for details. 1186 10.2. New MSRP Header 1188 This specification defines a new MSRP header to be added to the 1189 Header Field sub-registry of the Message Session Relay Protocol 1190 (MSRP) Parameters registry: 1192 Use-Nickname 1194 See Section 7 for details. 1196 10.3. New MSRP Status Codes 1198 This specification defines three new MSRP status codes to be added to 1199 the Status-Code sub-registry of the Message Session Relay Protocol 1200 (MSRP) parameters registry. 1202 The 404 status code indicates the failure to resolve the recipient 1203 URI in the To header field of the Message/CPIM wrapper in the SEND 1204 request, e.g, due to an unknown recipient. See Section 6.2 for 1205 details. 1207 The 423 response indicates a failure in allocated the requested 1208 NICKNAME. This can be caused by a malformed NICKNAME request (e.g., 1209 no Use-Nickname header field), an already allocated nickname, or a 1210 policy that prevents the sender to use nicknames. See Section 7 for 1211 details. 1213 The 428 status code indicates that the recipient of a SEND request 1214 does not support private messages. See section Section 6.2 for 1215 details. 1217 Table 1 summarizes the IANA registration data with respect to new 1218 MSRP status codes: 1220 +-------+---------------------------------------+-----------+ 1221 | Value | Description | Reference | 1222 +-------+---------------------------------------+-----------+ 1223 | 404 | Failure to resolve recipient's URI | RFC XXXX | 1224 | 423 | Unable to allocate requested nickname | RFC XXXX | 1225 | 428 | Private messages not supported | RFC XXXX | 1226 +-------+---------------------------------------+-----------+ 1228 Table 1: New status codes 1230 10.4. New SDP Attribute 1232 This specification defines a new media-level attribute in the Session 1233 Description Protocol (SDP) Parameters registry. The registration 1234 data is as follows: 1236 Contact: Miguel Garcia 1238 Phone: +34 91 339 1000 1240 Attribute name: chatroom 1242 Long-form attribute name: Chat Room 1244 Type of attribute: media level only 1246 This attribute is not subject to the charset attribute 1248 Description: This attribute identifiers support and local policy 1249 allowance for a number of chatroomt related functions 1251 Specification: RFC XXXX 1253 See section Section 8 for details. 1255 11. Security Considerations 1257 This document proposes extensions to the Message Session Relay 1258 Protocol [RFC4975]. Therefore, the security considerations of such 1259 document apply to this document as well. 1261 If the participant's SIP user agent doesn't understand the the 1262 "isfocus" feature tag [RFC3840], it will not know that it is 1263 connected to a conference instance. The participant might not be 1264 notified that the participant's MSRP client will try to send messages 1265 to the MSRP switch having potentially multiple recipients. If the 1266 participant's MSRP client doesn't support the extensions of this 1267 specification, it is unlikley that it will try to send a message 1268 using 'Message/CPIM' wrapper content type [RFC3862], and the MSRP 1269 switch will reject the request with a 415 response [RFC4975]. Still 1270 if particpants's MSRP client does create a message with a valid 1271 'Message/CPIM' wrapper content type [RFC3862] having the To header 1272 set to the URI of the chat room and the From header set to the URI of 1273 which the participant is known to the conference, the paricipant 1274 might be unaware that the message can be forwarded to multiple 1275 recipients. Equally if the To header is set to a valid URI of a 1276 recipient known to the conference, the message can be forwarded as a 1277 private message without the participant knowing. 1279 If a participant wants to avoid eavesdropping, the participant's MSRP 1280 client can send the messages over a TLS [RFC5246] transport 1281 connection, as allowed by MSRP. It's up to the policy of the MSRP 1282 switch if the messages are forwarded to the other participant's in 1283 the chat room using TLS [RFC5246] transport. 1285 Nicknames will be used to show the appearances of the participants of 1286 the conference. A successful take over of a nickname from a 1287 participant might lead to private messages to be sent to the wrong 1288 destination. The recipient's URI will be different from the URI 1289 associated to the original owner of the nickname, but the sender 1290 might not notice this. To avoid take overs the MSRP switch MUST make 1291 sure that a nickname is unique inside a chat room. Also the security 1292 consideration for any authenticated identity mechanisms used to 1293 validate the SIP AOR will apply to this document as well. If a 1294 nickname can be reserved if it previously has been used by another 1295 participant in the chat room, is up to the policy of the chat room. 1297 12. Contributors 1299 This work would have never been possible without the fruitful 1300 discussions in the SIMPLE WG mailing list, specially with Brian Rosen 1301 (Neustar) and Paul Kyzivat (Cisco), who provided extensive review and 1302 improvements throughout the document. 1304 13. Acknowledgments 1306 The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, 1307 Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrian 1308 Georgescu, and Nancy Greene for providing comments. 1310 14. References 1312 14.1. Normative References 1314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1315 Requirement Levels", BCP 14, RFC 2119, March 1997. 1317 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1318 A., Peterson, J., Sparks, R., Handley, M., and E. 1319 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1320 June 2002. 1322 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1323 with Session Description Protocol (SDP)", RFC 3264, 1324 June 2002. 1326 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1327 "Indicating User Agent Capabilities in the Session 1328 Initiation Protocol (SIP)", RFC 3840, August 2004. 1330 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1331 (CPIM)", RFC 3860, August 2004. 1333 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1334 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1336 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1337 Session Initiation Protocol (SIP)", RFC 4353, 1338 February 2006. 1340 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1341 Description Protocol", RFC 4566, July 2006. 1343 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1344 Initiation Protocol (SIP) Event Package for Conference 1345 State", RFC 4575, August 2006. 1347 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1348 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1350 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1351 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1352 September 2007. 1354 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 1355 Centralized Conferencing", RFC 5239, June 2008. 1357 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1358 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1360 [I-D.ietf-xcon-common-data-model] 1361 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 1362 "Conference Information Data Model for Centralized 1363 Conferencing (XCON)", draft-ietf-xcon-common-data-model-32 1364 (work in progress), September 2011. 1366 [I-D.ietf-xcon-event-package] 1367 Camarillo, G., Srinivasan, S., Even, R., and J. 1368 Urpalainen, "Conference Event Package Data Format 1369 Extension for Centralized Conferencing (XCON)", 1370 draft-ietf-xcon-event-package-01 (work in progress), 1371 September 2008. 1373 14.2. Informative References 1375 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1376 April 2000. 1378 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1379 Protocol (XMPP): Core", RFC 6120, March 2011. 1381 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1382 RFC 3966, December 2004. 1384 Authors' Addresses 1386 Aki Niemi 1387 Nokia 1388 P.O. Box 407 1389 NOKIA GROUP, FIN 00045 1390 Finland 1392 Phone: +358 50 389 1644 1393 Email: aki.niemi@nokia.com 1395 Miguel A. Garcia-Martin 1396 Ericsson 1397 Calle Via de los Poblados 13 1398 Madrid, ES 28033 1399 Spain 1401 Email: miguel.a.garcia@ericsson.com 1403 Geir A. Sandbakken (editor) 1404 Cisco Systems 1405 Philip Pedersens vei 20 1406 N-1366 Lysaker 1407 Norway 1409 Phone: +47 67 125 125 1410 Email: geirsand@cisco.com 1411 URI: http://www.cisco.com