idnits 2.17.1 draft-ietf-simple-chat-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == Line 596 has weird spacing: '...ssaging and P...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 5, 2009) is 5316 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) ** 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 3920 (Obsoleted by RFC 6120) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft Nokia 4 Intended status: Standards Track M. Garcia-Martin 5 Expires: April 8, 2010 Ericsson 6 G. Sandbakken, Ed. 7 TANDBERG 8 October 5, 2009 10 Multi-party Chat Using the Message Session Relay Protocol (MSRP) 11 draft-ietf-simple-chat-05 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 8, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 The Message Session Relay Protocol (MSRP) defines a mechanism for 60 sending instant messages within a peer-to-peer session, negotiated 61 using the Session Initiation Protocol (SIP) and the Session 62 Description Protocol (SDP). This document defines the necessary 63 tools for establishing multi-party chat sessions, or chat rooms, 64 using MSRP. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Motivations and Requirements . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . 11 77 6.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 11 78 6.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 12 79 6.3. MSRP reports and responses . . . . . . . . . . . . . . . . 13 80 7. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 7.1. Using Nicknames within a Conference . . . . . . . . . . . 15 82 7.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 16 83 7.3. Removing a Nickname . . . . . . . . . . . . . . . . . . . 16 84 7.4. Nicknames in the Conference Event Package . . . . . . . . 16 85 7.5. Nicknames not supported nor allowed . . . . . . . . . . . 17 86 8. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . . . 17 87 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 18 89 9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 20 90 9.3. Sending a regular message to the chat room . . . . . . . . 22 91 9.4. Sending a private message to a participant . . . . . . . . 23 92 9.5. Chuncked private message . . . . . . . . . . . . . . . . . 25 93 9.6. Sending a private message using anonymous URI . . . . . . 26 94 9.7. Nickname in a conference information document . . . . . . 27 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 96 10.1. New MSRP Method . . . . . . . . . . . . . . . . . . . . . 28 97 10.2. New MSRP Header . . . . . . . . . . . . . . . . . . . . . 29 98 10.3. New MSRP Status Codes . . . . . . . . . . . . . . . . . . 29 99 10.4. New SDP Attribute . . . . . . . . . . . . . . . . . . . . 29 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 101 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 104 14.1. Normative References . . . . . . . . . . . . . . . . . . . 30 105 14.2. Informative References . . . . . . . . . . . . . . . . . . 31 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 108 1. Introduction 110 The Message Session Relay Protocol (MSRP) [RFC4975] defines a 111 mechanism for sending a series of instant messages within a session. 112 The Session Initiation Protocol (SIP) [RFC3261] in combination with 113 the Session Description Protocol (SDP) [RFC3264] allows for two peers 114 to establish and manage such sessions. 116 In another application of SIP, a user agent can join in a multi-party 117 conversation called a conference that is hosted by a specialized user 118 agent called a focus [RFC4353]. Such a conference can naturally 119 involve MSRP sessions. It is the responsibility of an entity 120 handling the media to relay instant messages received from one 121 participant to the rest of the participants in the conference. 123 Several such systems already exist in the Internet. Participants in 124 a chat room can be identified with a pseudonym or nickname, and 125 decide whether their real identity is disclosed to other 126 participants. Participants can also use a rich set of features such 127 as the ability to send private instant messages to other 128 participants. 130 Similar conferences supporting chat rooms are already available 131 today. For example, Internet Relay Chat (IRC) [RFC2810], Extensible 132 Messaging and Presence Protocol [RFC3920] based chat rooms, and many 133 other proprietary systems provide chat room functionality. 134 Specifying equivalent functionality for MSRP-based systems provides 135 competitive features and enables interworking between the systems. 137 This document defines requirements, conventions, and extensions for 138 providing private messages and nickname management in centralized 139 conferences with MSRP. Participants in a chat room can be identified 140 by a pseudonym, and decide if their real identity is disclosed to 141 other participants. This memo uses the SIP Conferencing Framework 142 [RFC4353] as a design basis. It also aims to be compatible with the 143 A Framework for Centralized Conferencing [RFC5239]. It is expected 144 that future mechanisms will be developed for providing similar 145 functionality in generic conferences, i.e., where the media is not 146 only restricted to MSRP. The mechanisms described in this document 147 provide a future compatible short-term solution for MSRP centralized 148 conferences. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119, BCP 14 156 [RFC2119], and indicate requirement levels for compliant 157 implementations. 159 This memo deals with tightly coupled SIP conferences defined in SIP 160 Conferencing Framework [RFC4353] adopting the terminology. In 161 addition to that terminology, we introduce some new terms: 163 Nickname: a pseudonym or descriptive name associated to a 164 participant. See Section 7 for details 166 Multi-party chat: an instance of a tightly coupled conference, in 167 which the media exchanged between the participants consist of MSRP 168 based instant messages. Also known as a chat room. 170 Chat Room: a synonym for a multi-party chat 172 Chat Room URI: a URI that identifies a particular chat room, and is 173 a synonym of a Conference URI defined in [RFC4353] 175 Sender: the conference participant that originally created an 176 instant message and sent it to the chat room for delivery. 178 Recipient: the destination conference participant(s). This 179 defaults to the full conference participant list, minus the IM 180 Sender. 182 MSRP switch: a media level entity that is a MSRP endpoint. It is a 183 special MSRP endpoint that receives MSRP messages, and delivers 184 them to the other conference participants. The MSRP switch has a 185 similar role to a conference mixer with the exception that the 186 MSRP switch does not actually "mix" together different input media 187 streams; it merely relays the messages between participants. 189 Private Instant Message: an instant message sent in a chat room 190 intended for a single participant. A private IM is usually 191 rendered distinctly from the rest of the IMs, indicating that the 192 message was a private communication. 194 Anonymous URI: a temporary Globally Routable User Agent URI (GRUU) 195 [I-D.ietf-sip-gruu] that can be registered with the conference 196 focus to conceal a participant's SIP AOR from the other 197 participants in the conference. 199 3. Motivations and Requirements 201 Although conference frameworks describing many types of conferencing 202 applications already exist, such as the Framework for Centralized 203 Conferencing [RFC5239] and the SIP Conferencing Framework [RFC4353], 204 the exact details of session-based instant messaging conferences are 205 not well-defined at the moment. 207 To allow interoperable chat implementations, for both conference- 208 aware, and conference-unaware user agents, certain conventions for 209 MSRP conferences need to be defined. It also seems beneficial to 210 provide a set of features that enhance the baseline multi-party MSRP 211 in order to be able to create systems that have functionality on par 212 with existing chat systems, as well as enable building interworking 213 gateways to these existing chat systems. 215 We define the following requirements: 217 REQ-1: A basic requirement is the existence of a multi-party 218 conference, where participants can join and leave the 219 conference and get instant messages exchanged to the rest of 220 the participants. 222 REQ-2: A conference participant must be able to determine the 223 identities of the sender and recipient of the received IMs. 225 REQ-3: A conference participant must be able to determine the 226 recipient of the received message. For instance, the 227 recipient of the message might be the entire conference or a 228 single participant of the conference (i.e., a private 229 message). 231 REQ-4: It must be possible to send a message to a single participant 232 within the conference (i.e., a private instant message). 234 REQ-5: A conference participant may have a nickname or pseudonym 235 associated with their real identity. 237 REQ-6: It must be possible for a participant to change their 238 nickname during the progress of the conference. 240 REQ-7: It must be possible that a participant is only known by an 241 anonymous identity and not their real identity to the rest of 242 the conference. 244 REQ-8: It must be possible for the MSRP switch originate IMs to the 245 conference by owner or administrator (e.g. message of the 246 day, welcome messages, server is shutting down, etc.) 248 REQ-9: It must be possible for the conference participants to learn 249 the chat room capabilities described in this document. 251 4. Overview of Operation 253 In order to set up a conference, one must first be created. Users 254 wishing to host a conference themselves can of course do just that; 255 their User Agent (UA) simply morphs from an ordinary UA into a 256 special purpose one called a Focus UA. Another, commonly used setup 257 is one where a dedicated node in the network functions as a Focus UA. 259 Each chat room has an identity of its own: a SIP URI that 260 participants use to join the conference, e.g. by sending an INVITE 261 request. The conference focus processes the invitations, and as 262 such, maintains SIP dialogs with each participant. In an multi-party 263 chat, or chat room, MSRP is one of the established media streams. 264 Each conference participant establishes an MSRP session with the MSRP 265 switch, which is a special purpose MSRP application. The MSRP 266 sessions can be relayed by one or more MSRP relays found in 267 [RFC4976]. This is illustrated in Figure 1 268 MSRP Sessions 269 +---------------------------+ 270 | +-----------+ | 271 +---+--+ +---+--+ | | 272 | SIP | | SIP | | | 273 | MSRP | | MSRP | +--+---+----+ 274 |Client| |Client| | MSRP | 275 +---+--+ ++-----+ | Relay | 276 | | +-----+-----+ 277 SIP Dialogs | / | 278 | | | MSRP Sessions 279 +----+------+--+ | 280 | Conference | +-------+-----+ 281 | Focus UA | | MSRP | 282 | |........| Switch | 283 | | | | 284 +---+--------+-+ +-------+-----+ 285 | \ | 286 SIP Dialogs | | | MSRP Sessions 287 | \ | 288 +--+---+ +-+----+ +-----+------+ 289 | SIP | | SIP | | MSRP | 290 | MSRP | | MSRP | | Relay | 291 |Client| |Client| +-+-------+--+ 292 +---+--+ +--+---+ | | 293 | +-----------+ | 294 +------------------------------+ 295 MSRP sessions 297 Figure 1: Multi-party chat overview shown with MSRP Relays and a 298 conference Focus UA 300 The MSRP switch is similar to a conference mixer in that it handles 301 media sessions with each of the participants and bridges these 302 streams together. However, unlike a conference mixer, the MSRP 303 switch merely forwards messages between participants but doesn't 304 actually mix the streams in any way. The system is illustrated in 305 Figure 2. 307 +------+ 308 | MSRP | 309 |Client| 310 +------+ +--.---+ +------+ 311 | MSRP | | | MSRP | 312 |Client| | _|Client| 313 +------._ | ,' +------+ 314 `._ | ,' 315 `.. +----------+ ,' 316 `| |' 317 | MSRP | 318 | Switch | 319 ,| |_ 320 _,-'' +----------+ ``-._ 321 +------.-' | `--+------+ 322 | MSRP | | | MSRP | 323 |Client| | |Client| 324 +------+ | +------+ 325 +---'--+ 326 | MSRP | 327 |Client| 328 +------+ 330 Figure 2: Multi-party chat in a Centralized Conference 332 Typically conference participants also subscribe to the conference 333 event package [RFC4575] to gather information about the conference 334 roster in the form of conference state notifications. For example, 335 participants can learn about other participants' identities. 337 All messages in the chat room use the 'Message/CPIM' wrapper content 338 type [RFC3862], so that it is possible to distinguish between private 339 and regular messages. When a participant wants to send an instant 340 message to the conference, it constructs an MSRP SEND request and 341 submits it to the MSRP switch including a regular payload (e.g. a 342 Message/CPIM message that contains a text, html, an image, etc.). 343 The Message/CPIM To header is set to the chat room URI. The switch 344 then fans out the SEND request to all of the other participants using 345 their existing MSRP sessions. 347 A participant can also send a private instant message addressed to a 348 participants whose identity has been learned, e.g. via a notification 349 from the conference event package [RFC4575]. In this case the sender 350 creates an MSRP SEND request with a Message/CPIM body whose To header 351 contains not the chat room URI but the recipient's URI. The MSRP 352 switch then forwards the SEND request to the recipient. 354 We extend the current MSRP negotiation that takes place in SDP 356 [RFC4566] to allow participants to learn whether the chat room 357 supports and is willing to accept (e.g. due to local policy 358 restrictions) certain MSRP functions defined in this memo, such as 359 nicknames or private messaging. 361 Naturally, when a participant wishes to leave a chat room, it sends a 362 SIP BYE request to the Focus UA and terminates the SIP dialog with 363 the focus and MSRP sessions with the MSRP switch. 365 5. Creating, Joining, and Deleting a Chat Room 367 5.1. Creating a Chat Room 369 Since we consider a chat room a particular type of conference having 370 MSRP media, the methods defined by the SIP Conference Framework 371 [RFC4353] for creating conferences are directly applicable to a chat 372 room. 374 Once a chat room is created, it is identified by a SIP URI, like any 375 other conference. 377 5.2. Joining a Chat Room 379 Participants usually join the conference by sending an INVITE request 380 to the conference URI. As long as the conference policy allows, the 381 INVITE request is accepted by the focus and the user is brought into 382 the conference. Conference aware participants will detect that the 383 peer is a focus due to the presence of the "isfocus" feature tag 384 [RFC3840] in the Contact header field of the 200-class response to 385 the INVITE request. Conference unaware participants will not notice 386 it is a foucs, and can not apply the additional mechanisms defined in 387 this document. Participants are also aware that the mixer is an MSRP 388 switch due to the presence of an 'message' media type and either TCP/ 389 MSRP or TCP/TLS/MSRP as the protocol field in the SDP [RFC4566] 390 media-line. 392 The conference focus of a chat room MUST include support for a 393 Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by 394 setting the 'accept-types' MSRP media line attribute in the SDP offer 395 or answer to include 'Message/CPIM'. 397 Note that the 'Message/CPIM' wrapper is used to carry the sender 398 information that, otherwise, it will not be available to the 399 recipient. Additionally, 'Message/CPIM' wrapper carries the 400 recipient information (e.g. To and Cc: headers). 402 If a participant wants to remain anonymous to the rest of the 403 participants in the conference, the participant's UA can register or 404 acquire by other means a temporary GRUU with the conference focus. 405 The procedure SHOULD follow the recommendation of draft-ietf-sip-gruu 406 [I-D.ietf-sip-gruu]. The temporary GRUU can be used in the From and 407 To header in the 'Message/CPIM' wrapper concealing the participant's 408 SIP AOR from the other participants in the conference. 410 The conference focus of a chat room MUST learn the chat room 411 capabilities of each participant that joins the chat room, and MUST 412 inform the MSRP switch of such support. This is to prevent that the 413 MSRP switch distributes private messages to participants who do not 414 support private messaging. The recipient could be able to render the 415 private message, but not supporting private messages the participant 416 can not respond. 418 5.3. Deleting a Chat Room 420 As with creating a conference, the methods defined by the SIP 421 Conference Framework [RFC4353] for deleting a conference are directly 422 applicable to a chat room. The MSRP switch will terminate the MSRP 423 sessions with all the participants. 425 Deleting a chat room is an action that heavily depends on the policy 426 of the chat room. The policy can determine that the chat room is 427 deleted when the creator leaves the conference, or with any out of 428 band mechanism. 430 6. Sending and Receiving Instant Messages 432 6.1. Regular Messages 434 This section describes the conventions used to send and receive 435 instant messages that are addressed to all the participants in the 436 chat room. These are sent over a regular MSRP SEND request that 437 contains a Message/CPIM wrapper [RFC3862] that in turn contains the 438 desired payload (e.g. text, image, video-clip, etc.). 440 When a chat room participant wishes to send an instant message to all 441 the other participants in the chat room, he constructs an MSRP SEND 442 request that MUST contain a top-level wrapper of type 'Message/CPIM' 443 [RFC3862]. The actual instant message payload inside 'Message/CPIM' 444 MAY be of any type negotiated in the SDP 'accepted-types' attribute 445 according to the MSRP rules. 447 The sender SHOULD populate the From header of the Message/CPIM 448 wrapper with a proper identity by which the user is recognized in the 449 conference. Identities that can be used (among others) are: 451 o A SIP URI [RFC3261] representing the participant's address-of- 452 record 454 o A tel URI [RFC3966] representing the participant's telephone 455 number 457 o An IM URI [RFC3860] representing the participant's instant 458 messaging address 460 o An temporary GRUU [I-D.ietf-sip-gruu] representing the anonymous 461 URI associated with the sender. 463 The MSRP switch that receives a SEND request from a participant 464 SHOULD first verify that the From header field of the Message/CPIM 465 wrapper is correctly populated with a valid URI. 467 Then the MSRP switch should inspect the To header field of the 468 Message/CPIM wrapper. If the To header field of the Message/CPIM 469 wrapper contains the chat room URI, the MSRP switch can generate a 470 copy of the SEND request to each of the participants in the 471 conference except the sender. The MSRP switch MUST NOT modify any of 472 the bodies included in the received SEND request. Note that the MSRP 473 switch does not need to wait for the reception of the complete MSRP 474 chunk or MSRP message before it starts the distribution to the rest 475 of the participants. Instead, once the MSRP switch has received the 476 headers of the Message/CPIM body it SHOULD start the distribution 477 process. Having the Message/CPIM header only in the first chunk, the 478 MSRP switch MUST track the Message-Id until the last chunk of the 479 message has been distributed. 481 An MSRP endpoint that receives a SEND request from the MSRP switch 482 containing a Message/CPIM wrapper SHOULD first inspect the To header 483 field of the Message/CPIM body. If the To header field is set to the 484 chat room URI, it should render it is a regular message that has been 485 distributed to all the participants in the conference. Then the MSRP 486 endpoint SHOULD inspect the From header field of the Message/CPIM 487 body to identify the sender. The From header field will include a 488 URI that identifies the sender. The endpoint might have also 489 received further identity information through a subscription to the 490 SIP conference event package [RFC4575]. 492 6.2. Private Messages 494 This section describes the conventions used to send and receive 495 private instant messages, i.e., instant messages that are addressed 496 to one participant of the chat room rather to all of them. A chat 497 room can signal support for private messages using the chatroom- 498 attribute (see Section 8 for details). 500 When a chat room participant wishes to send a private instant message 501 to a participant the chat room, it follows the same procedures for 502 creating a SEND request as for regular messages (Section 6.1). The 503 only difference is that the MSRP endpoint MUST populate the To header 504 of the Message/CPIM with the identity of the intended recipient. The 505 identity can be SIP, TEL, and IM URIs typically learned from the 506 information received in notifications of the conference event package 507 [RFC4575]. 509 As for regular messages, the MSRP switch that receives a SEND request 510 from a participant SHOULD first verify that the From header field of 511 the Message/CPIM wrapper is correctly populated with a valid URI, and 512 that the recipient is supporting private messages. See section 513 Section 6.3 for report and response handling. If successful, the 514 MSRP switch should search it's mapping table to find the MSRP session 515 established towards the recipient. If a match is found the MSRP 516 switch MUST create a SEND request and MUST copy the contents of the 517 sender's message to it. 519 An MSRP endpoint that receives a SEND request from the MSRP switch 520 does the same validations as for regular messages (Section 6.1). If 521 the To header field is different from the chat room URI, the MSRP 522 endpoints know that it is a private message. It should render who it 523 is from based on the From header of the Message/CPIM wrapper 525 It is possible that a participant, identified by a SIP Address of 526 Record, joins a conference of instant messages from two or more 527 different SIP UAs. It is RECOMMENDED that the the MSRP switch can 528 map a participant or anonymous URI for two or more MSRP sessions. If 529 the policy of the server allows for this, the MSRP switch MUST copy 530 all messages intended for the recipient through each MSRP session. 532 6.3. MSRP reports and responses 534 The MSRP SHALL follow the success report and failure report handling 535 described in section 7 of [RFC4975]. For regular messages the MSRP 536 switch MUST act as a MSRP endpoint receiver of the request according 537 to section 5.3 of [RFC4975]. 539 For regular messages the MSRP switch MAY use any report model in the 540 copies of the regular SEND request intended for the recipients, but 541 any received reports MUST NOT be forwarded to the originator of the 542 original SEND request. This could lead to having the sender 543 receiving multiple reports for a single MSRP request. The MSRP 544 switch for regular messages SHALL construct responses according to 545 section 7.2 of [RFC4975]. If the URI included in the From header 546 field of the Message/CPIM wrapper is not valid (e.g, because it does 547 not "belong" to the user), the response code is 403. Otherwise the 548 response code is 200. 550 Private messages (section Section 6.2) handle MSRP reports 551 differently from regular chat room messages. The MSRP switch acts 552 transparently having an end-to-end relationship between the sender 553 and the recipient. The MSRP switch MUST for private messages keep 554 any Sucess-Report and Failure-Report headers in the relayed request. 555 Any reports or responses from the recipient MUST be forwarded to the 556 sender. 558 For private messages the MSRP switch MUST follow section 7.2 of 559 [RFC4975] in the following error scenarios. The MSRP switch MUST 560 inspect the To header field of the Message/CPIM wrapper. If the To 561 header field of the Message/CPIM wrapper in the request does not 562 contain the chat room URI, it must check if it contains a 563 participants URI associated with a participant. If the URI in the To 564 header can not be resolved (e.g. cased by a mistyped URI or that the 565 recipient has abandoned he chat room), the response error code is 566 427. The new 427 status code indicates a failure to resolve the 567 recipient URI in the To header field. If the recipient doesn't 568 support private messages, the response code is 428. The new response 569 428 indicate that the recipient does not support private messages. A 570 REPORT request MUST include a Message/CPIM wrapper, with the original 571 From header field included in the SEND request, and the To header 572 field of the original message. The message MUST NOT be forwarded to 573 the recipient if above conditions applies. 575 7. Nicknames 577 A common characteristic of existing chat room services is that 578 participants have the ability to present themselves with a nickname 579 to the rest of the participants of the conference. It is used for 580 easy reference of participants in the chat room, and can also provide 581 anonymous participants with a meaningful descriptive name. 583 A nickname is a useful construct in many use cases, of which MSRP 584 chat is but one example. It is associated with a URI of which the 585 participant is known to the focus. It is a user selectable 586 appearance of which the participant wants to be known to the other 587 participants. It is not a 'display-name', but it is used somewhat 588 like a display name. A main difference is that a nickname is unique 589 inside a chat room to allow an unambiguous reference to a participant 590 in the chat. Nicknames may be long lived, or may be temporary. 591 Users also need to reserve a nickname prior to its utilization. 593 This memo specifies the nickname as a string. The nickname string 594 MUST be unambiguous within the scope of the chat room (conference 595 instance). This scope is similar to having a nickname unique inside 596 a chat room from Extensible Messaging and Presence Protocol 597 [RFC3920]. The chat room may have policies associated with 598 nicknames. It may not accept nickname strings at all, or a it may 599 provide a wider unambiguous scope like a domain or server, similar to 600 Internet Relay Chat (IRC) [RFC2810]. 602 7.1. Using Nicknames within a Conference 604 This memo provides a mechanism to reserve a nickname for a 605 participant for as long as the participant is logged into the chat 606 room. The mechanism is based on a NICKNAME MSRP method (see below) 607 and a new "Use-Nickname" header. Note that other mechanisms may 608 exist (for example, a web page reservation system), although they are 609 outside the scope of this document. 611 A conference participant who has established an MSRP session with the 612 MSRP switch, where the MSRP switch has indicated the support and 613 availability of nicknames with the 'nicknames' token in the 614 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP 615 switch. The NICKNAME request MUST include a new Use-Nickname header 616 that contains the nickname string that the participant wants to 617 reserve. 619 The MSRP switch that receives a NICKNAME request containing a 620 nickname in the Use-Nickname header field SHOULD first verify whether 621 the policy of the chat room allows the nickname functionality. If is 622 not allowed, the MSRP the response code is 501 section 7.2 of 623 [RFC4975] for constructing a response. 625 If the policy of the chat room allows the usage of nicknames, the 626 MSRP switch SHOULD validate that the SIP AOR is entitled to reserve 627 the nickname. The participant's authenticated identity can be 628 derived after a successful HTTP Digest Authentication, included in a 629 trusted SIP P-Asserted-Identity header field, included in a valid SIP 630 Identity header field, or derived from any other present or future 631 SIP authentication mechanism. Once the MSRP switch has validated 632 that the participant is entitled to reserve the nickname, the 633 response code is 200. 635 The reservation of a nickname can fail, e.g. if the NICKNAME request 636 contains a malformed or non-existent Use-Nickname header field, or if 637 the same nickname has already been reserved by another participant in 638 the conference. The validation can also fail where the SIP AOR is 639 not entitled to reserve the nickname. In any of these cases the MSRP 640 response code is 423.The semantics of the 423 response are: "Nickname 641 usage failed; the nickname is not allocated to this user". 643 As indicated earlier, this specification defines a new MSRP header 644 field: "Use-Nickname". The Use-Nickname header field carries a 645 nickname string, and SHOULD be included in the NICKNAME requests. 647 The syntax of the NICKNAME method and the "Use-Nickname" header field 648 is built upon the MSRP formal syntax [RFC4975] 650 ext-method =/ NICKNAMEm 651 NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps 652 ext-header =/ Use-Nickname 653 ; ext-header is specified in RFC 4975 654 Use-Nickname = "Use-Nickname" ":" nickname 655 nickname = quoted-string 657 7.2. Modifying a Nickname 659 Typically participants will reserve a nickname as soon as they join 660 the chat room. But it is also possible for participants to modify 661 their own nicknames and replace them it a new one at any time during 662 the duration of the MSRP session. Modification of the nickname is 663 not different from the initial reservation and usage of a nickname, 664 thus the NICKNAME method is used as described in Section 7.1. 666 If a NICKNAME request that attempts to modify the current nickname of 667 the user for some reason fails, the current nickname stays in effect. 668 A new nickname comes into effect and the old one is released only 669 after a NICKNAME request is accepted with a 200 response. 671 7.3. Removing a Nickname 673 If the participant no longer wants to be known by a nickname in the 674 conference, the participant can follow the method described in 675 Section 7.2. The nickname element of the Use-Nickname header MUST be 676 set to an empty quoted string. 678 7.4. Nicknames in the Conference Event Package 680 Typically the conference focus acts as a notifier of the SIP 681 conference event package [RFC4575]. The conference focus MAY notify 682 subscribers of the nickname reserved by a given participant. We 683 define an extension to the conference event package to include 684 nicknames. The extension adds a child element to the 685 element containing the nickname string. 687 The following element is to be added to the sequence of the USER-TYPE 688 in the XML schema in conference event package [RFC4575] 690 692 7.5. Nicknames not supported nor allowed 694 The participants of the conference are identified by the SIP, TEL and 695 IM URI's typically learned from the information received in 696 notifications of the conference event package [RFC4575]. If 697 nicknames are not supported nor allowed, the participant list of the 698 conference will be less presentable. 700 8. The SDP 'chatroom' attribute 702 There are a handful of use cases where a participant would like to 703 learn the chat room capabilities supported by the MSRP switch and the 704 chat room. For example, a participant would like to learn if the 705 MSRP switch supports private messaging, otherwise, the participant 706 may send what he believes is a private instant message addressed to a 707 participant, but since the MSRP switch does not support the functions 708 specified in this memo, the message gets eventually distributed to 709 all the participants of the chat room. 711 The reverse case also exists. A participant, say Alice, whose user 712 agent does not support the extensions defined by this document joins 713 the chat room. The MSRP switch learns that Alice application does 714 not support private messaging nor nicknames. If another participant, 715 say Bob, sends a private message to Alice, the MSRP switch does not 716 distribute it to Alice, because Alice is not able to differentiate it 717 from a regular message sent to the whole roster. Further more, if 718 Alice replied to this message, she would do it to the whole roster. 719 Because of this, the MSRP switch keeps also track of users who do not 720 support the extensions defined in this document. 722 In another scenario, the policy of a chat room may indicate that 723 certain functions are not allowed. For example, the policy may 724 indicate that nicknames or private messages are not allowed. 726 In order to provide the user with a good chat room experience, we 727 define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a 728 media-level attribute that MAY be included in conjunction with and 729 MSRP media stream (i.e., when an m= line in SDP indicates "TCP/MSRP" 730 or "TCP/TLS/MSRP"). The 'chatroom' attribute indicates the 731 intersection of support and chat room local policy allowance for a 732 number of functions specified in this document. Specifically, we 733 provide the means for indicating support to use nicknames and private 734 messaging. 736 The 'chatroom' SDP attribute has the following syntax: 738 chatroom = chatroom-label ":" chat-token *(SP chat-token) 739 chatroom-label = "chatroom" 740 chat-token = (nicknames-token | private-msg-token | token) 741 nicknames-token = "nicknames" 742 private-msg-token = "private-messages" 744 A conference focus that includes the 'nicknames' token in the session 745 description is signaling that the MSRP switch supports and the chat 746 room allows to use of the procedures specified in Section 7. A 747 conference focus that includes the 'private-messages' in the SDP 748 description is signaling that the MSRP switch supports and the chat 749 room allows to use of the procedures specified in Section 6.2. 751 Example of the 'chatroom' attribute for an MSRP media stream that 752 indicates the acceptance of nicknames and private messages: 754 a=chatroom:nickname private-messages 756 9. Examples 758 9.1. Joining a chat room 760 Figure 3 presents a flow diagram where Alice joins a chat room by 761 sending an INVITE request. This INVITE request contains a session 762 description that includes the chatroom extensions defined in this 763 document. 765 Alice Conference focus 766 | | 767 |(1) (SIP) INVITE | 768 |----------------------->| 769 |(2) (SIP) 200 OK | 770 |<-----------------------| 771 |(3) (SIP) ACK | 772 |----------------------->| 773 | | 775 Figure 3: Flow diagram of a user joining a chat room 777 F1: Alice constructs an SDP description that includes an MSRP media 778 stream. She also indicates her support for the chatroom extensions 779 defined in this document. She sends the INVITE request to the chat 780 room server. 782 INVITE sip:chatroom22@chat.example.com SIP/2.0 783 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 784 Max-Forwards: 70 785 From: Alice ;tag=9fxced76sl 786 To: Chatroom 22 787 Call-ID: 3848276298220188511@atlanta.example.com 788 CSeq: 1 INVITE 789 Contact: 790 Content-Type: application/sdp 791 Content-Length: [length] 793 v=0 794 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 795 s=- 796 c=IN IP4 atlanta.example.com 797 m=message 7654 TCP/MSRP * 798 a=accept-types:message/cpim text/plain text/html 799 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 800 a=chatroom:nickname private-messages 802 Figure 4: INVITE request containing an SDP offer with chat room 803 extensions 805 F2: The chat room server accepts the session establishment. It 806 includes the 'isfocus' and other relevant feature tags in the Contact 807 header field of the response. The chat room server also builds an 808 SDP answer that also that forces the reception of messages wrapped in 809 message/cpim envelops. It also includes the the chatroom attribute 810 with the allowed extensions. 812 SIP/2.0 200 OK 813 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 814 ;received=192.0.2.101 815 From: Alice ;tag=9fxced76sl 816 To: Chatroom 22 ;tag=8321234356 817 Call-ID: 3848276298220188511@atlanta.example.com 818 CSeq: 1 INVITE 819 Contact: \ 820 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \ 821 ;automata;isfocus;message;event="conference" 822 Content-Type: application/sdp 823 Content-Length: [length] 825 v=0 826 o=chat 2890844527 2890844527 IN IP4 chat.example.com 827 s=- 828 c=IN IP4 chat.example.com 829 m=message 12763 TCP/MSRP * 830 a=accept-types:message/cpim 831 a=accept-wrapped-types:text/plain text/html * 832 a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 833 a=chatroom:nickname private-messages 835 Figure 5: 200 (OK) response including chat room extensions 837 F3: The session established is acknowledged (details not shown). 839 9.2. Setting up a nickname 841 Figure 6 shows an example of Alice setting up a nickname using the 842 conference as provider. Her first proposal is not accepted because 843 the proposed nickname is already in use. Her second proposal is 844 accepted. 846 Alice MSRP switch 847 | | 848 |(1) (MSRP) NICKNAME | 849 |----------------------->| 850 |(2) (MSRP) 423 | 851 |<-----------------------| 852 |(3) (MSRP) NICKNAME | 853 |----------------------->| 854 |(4) (MSRP) 200 | 855 |<-----------------------| 856 | | 858 Figure 6: Flow diagram of a user setting up her nickname 860 F1: Alice sends an MSRP NICKNAME request that contains her proposed 861 nicknames in the Set-Nickname header field. 863 MSRP d93kswow NICKNAME 864 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 865 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 866 Use-Nickname: "Alice the great" 867 -------d93kswow$ 869 Figure 7: MSRP NICKNAME request with an initial nickname proposal 871 F2: The MSRP switch analyzes the existing allocation of nicknames and 872 detects that the nickname "Alice is great" is already provided to 873 another participant by the conference. The MSRP switch answers with 874 a 423 response. 876 MSRP d93kswow 423 Nickname usage failed 877 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 878 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 879 -------d93kswow$ 881 Figure 8: MSRP 423 response 883 F3: Alice receives the response. She proposes a new nickname in a 884 second NICKNAME request. 886 MSRP 09swk2d NICKNAME 887 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 888 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 889 Use-Nickname: "Alice in wonderland" 890 -------09swk2d$ 892 Figure 9: MSRP NICKNAME request with a second nickname proposal 894 F4: The MSRP switch accepts the nickname proposal and answers with a 895 200 response. 897 MSRP 09swk2d 200 OK 898 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 899 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 900 -------09swk2d$ 902 Figure 10: MSRP NICKNAME request 904 9.3. Sending a regular message to the chat room 906 Figure 11 depicts a flow diagram where Alice is sending a regular 907 message addressed to the chat room. The MSRP switch distributes the 908 message to the rest of the participants. 910 Alice MSRP switch Bob Charlie 911 | | | | 912 | (1) (MSRP) SEND | | | 913 |--------------------->| (3) (MSRP) SEND | | 914 | (2) (MSRP) 200 |----------------------->| | 915 |<---------------------| (4) (MSRP) SEND | | 916 | |------------------------------->| 917 | | (5) (MSRP) 200 OK | | 918 | |<-----------------------| | 919 | | (6) (MSRP) 200 OK | | 920 | |<------------------------------ | 921 | | | | 922 | | | | 924 Figure 11: Sending a regular message to the chat room 926 F1: Alice builds a text message and wraps it in a CPIM message. She 927 addresses the CPIM message to the chat room. She encloses the result 928 in an MSRP SEND request and sends it to the MSRP switch via the 929 existing TCP connection. 931 MSRP 3490visdm SEND 932 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 933 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 934 Message-ID: 99s9s2 935 Byte-Range: 1-*/* 936 Content-Type: message/cpim 938 To: 939 From: 940 DateTime: 2009-03-02T15:02:31-03:00 941 Content-Type: text/plain 943 Hello guys, how are you today? 944 -------3490visdm$ 946 Figure 12: Instant message addressed to all participants in the chat 947 room 949 F2: The MSRP switch acknowledges the reception of the SEND request 950 with a 200 (OK) response. 952 MSRP 3490visdm 200 OK 953 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 954 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 955 Message-ID: 99s9s2 956 Byte-Range: 1-*/* 957 -------3490visdm$ 959 Figure 13: 200 (OK) response 961 F3: The MSRP switch creates a new MSRP SEND request that contains the 962 received message/cpim body and sends it to Bob. 964 MSRP 490ej23 SEND 965 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 966 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 967 Message-ID: 304sse2 968 Byte-Range: 1-*/* 969 Content-Type: message/cpim 971 To: 972 From: 973 DateTime: 2009-03-02T15:02:31-03:00 974 Content-Type: text/plain 976 Hello guys, how are you today? 977 -------490ej23$ 979 Figure 14: Instant message sent to all participants 981 The rest of the message flows are analogous to the previous. They 982 are not shown here. 984 9.4. Sending a private message to a participant 986 Figure 15 depicts a flow diagram where Alice is sending a private 987 message addressed to Bob's SIP AOR. The MSRP switch distributes the 988 message only to Bob. 990 Alice MSRP switch Bob 991 | | | 992 | (1) (MSRP) SEND | | 993 |--------------------->| (3) (MSRP) SEND | 994 | (2) (MSRP) 200 |----------------------->| 995 |<---------------------| | 996 | | | 997 | | | 999 Figure 15: Sending a private message to Bob 1001 F1: Alice builds a text message and wraps it in a CPIM message. She 1002 addresses the CPIM message to the Bob's nickname, which she learned 1003 from a notification in the conference event package. She encloses 1004 the result in an MSRP SEND request and sends it to the MSRP switch 1005 via the existing TCP connection. 1007 MSRP 6959ssdf SEND 1008 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1009 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1010 Message-ID: okj3kw 1011 Byte-Range: 1-*/* 1012 Content-Type: message/cpim 1014 To: 1015 From: 1016 DateTime: 2009-03-02T15:02:31-03:00 1017 Content-Type: text/plain 1019 Hello Bob. 1020 -------6959ssdf$ 1022 Figure 16: Private instant message addressed to one participant 1024 F2: The MSRP switch acknowledges the reception of the SEND request 1025 with a 200 (OK) response. 1027 MSRP 6959ssdfm 200 OK 1028 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1029 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1030 Message-ID: okj3kw 1031 Byte-Range: 1-*/* 1032 -------6959ssdfm$ 1034 Figure 17: 200 (OK) response 1036 F3: The MSRP switch creates a new MSRP SEND request that contains the 1037 received message/cpim body and sends it only to Bob. Bob can 1038 distinguish the sender in the From header of the CPIM message. He 1039 also identifies this as a private message due to the To CPIM header. 1041 MSRP 9v9s2 SEND 1042 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1043 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1044 Message-ID: d9fghe982 1045 Byte-Range: 1-*/* 1046 Content-Type: message/cpim 1048 To: 1049 From: 1050 DateTime: 2009-03-02T15:02:31-03:00 1051 Content-Type: text/plain 1053 Hello Bob. 1054 -------9v9s2$ 1056 Figure 18: Private instant message sent to Bob 1058 9.5. Chuncked private message 1060 Figure 19 depicts an example of the private message in Section 9.4 1061 split in two chuncks. The MSRP switch must wait for the complete set 1062 of CPIM headers before distributing the messages. 1064 MSRP 7443ruls SEND 1065 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1066 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1067 Message-ID: aft4to 1068 Byte-Range: 1-*/174 1069 Content-Type: message/cpim 1071 To: 1072 From: 1073 -------7443ruls$ 1075 MSRP 7443ruls SEND 1076 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1077 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1078 Message-ID: aft4to 1079 Byte-Range: 68-174/174 1080 Content-Type: message/cpim 1082 DateTime: 2009-03-02T15:02:31-03:00 1083 Content-Type: text/plain 1085 Hello Bob 1086 -------7443ruls$ 1088 Figure 19: Chuncked private message 1090 9.6. Sending a private message using anonymous URI 1092 Figure 20 depicts a flow diagram where Alice is utilizing the 1093 temporary GRUU when sending a private message to Bob 1095 Alice MSRP switch Bob 1096 | | | 1097 | (1) (MSRP) SEND | | 1098 |--------------------->| (3) (MSRP) SEND | 1099 | (2) (MSRP) 200 |----------------------->| 1100 |<---------------------| | 1101 | | | 1102 | | | 1103 | | | 1105 Figure 20: Sending an anonymous private message to Bob 1107 F1: Alice builds a text message adding her registered temp-gruu to 1108 the From header of the CPIM message 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-*/* 1115 Content-Type: message/cpim 1117 To: 1118 From: 1119 DateTime: 2009-03-02T15:02:31-03:00 1120 Content-Type: text/plain 1122 Hello Bob. 1123 -------7443ruls$ 1125 Figure 21: Anonymous private instant message 1127 F2: The MSRP switch inspects the From header field and verifies that 1128 the temp-gruuu in registered to Alice. If the temporary gruu is 1129 valid, the MSRP acknowledges the reception of SEND request with a 200 1130 (OK) response 1131 MSRP 7443ruls 200 OK 1132 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1133 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1134 Message-ID: aft4to 1135 Byte-Range: 1-*/* 1136 -------7443ruls$ 1138 Figure 22: 200 (OK) response 1140 Flow F3 is not shown 1142 9.7. Nickname in a conference information document 1144 Figure 23 depicts two user elements in a conference information 1145 document both having the nickname element with a nickname string. 1147 1148 1152 1155 1156 MSRP nickname example 1157 1158 1161 1162 2 1163 1164 1167 1168 1169 Bobster 1170 1171 1174 1175 Depressed Donkey 1176 1177 1178 1180 Figure 23: Nickname in a conference information document 1182 10. IANA Considerations 1184 10.1. New MSRP Method 1186 This specification defines a new MSRP method to be added to the 1187 Methods sub-registry under the MSRP Parameter registry: NICKNAME. 1188 See section Section 7 for details. 1190 10.2. New MSRP Header 1192 This specification defines a new MSRP header to be added to the 1193 header-field sub registry under the MSRP Parameter registry: 1194 Use-Nickname. See section 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 under MSRP parameters. 1201 The 427 status code indicates the failure to resolve the recipient 1202 URI in the To header field of the Message/CPIM wrapper in the SEND 1203 request. See section for details. 1205 The 428 status code indicates that the recipient of a SEND request 1206 does not support private messages. See section for details. 1208 The 423 response indicates that the requested nickname is not 1209 allocated to the user requesting it. See section Section 7 for 1210 details. 1212 10.4. New SDP Attribute 1214 This specification defines a new media level attribute in the Session 1215 Description Protocol (SDP) Parameters registry: chatroom. See 1216 section Section 8 for details. 1218 11. Security Considerations 1220 This document proposes extensions to the Message Session Relay 1221 Protocol [RFC4975]. Therefore, the security considerations of such 1222 document apply to this document as well. 1224 In general, messages sent to a multi-party session based messaging 1225 focus are not deem to expose any security threat. Nevertheless, if a 1226 participant wants to avoid eavesdropping from non authorized 1227 entities, it should send those messages a TLS [RFC5246] transport 1228 connection, as allowed by MSRP. 1230 Nicknames will be used to show the appearances of the participants of 1231 the conference. A successful take over of a nickname from a 1232 participant might lead to private messages to be sent to the wrong 1233 destination. The recipient's URI will be different from the URI 1234 associated to the original owner of the nickname, but the sender 1235 might not notice this. To avoid take overs the MSRP switch MUST make 1236 sure that a nickname is unique inside a chat room. Also the security 1237 consideration for any authenticated identity mechanisms used to 1238 validate the SIP AOR will apply to this document as well. If a 1239 nickname can be reserved if it previously has been used by another 1240 participant in the chat room, is up to the policy of the chat room. 1242 12. Contributors 1244 This work would have never been possible without the fruitful 1245 discussions in the SIMPLE WG mailing list, specially with Brian Rosen 1246 (Neustar) and Paul Kyzivat (Cisco), who provided extensive review and 1247 improvements throughout the document. 1249 13. Acknowledgments 1251 The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, 1252 Matt Lepinski, Mary Barnes and Ben Campbell for providing comments. 1254 14. References 1256 14.1. Normative References 1258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1259 Requirement Levels", BCP 14, RFC 2119, March 1997. 1261 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1262 A., Peterson, J., Sparks, R., Handley, M., and E. 1263 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1264 June 2002. 1266 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1267 "Indicating User Agent Capabilities in the Session 1268 Initiation Protocol (SIP)", RFC 3840, August 2004. 1270 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1271 (CPIM)", RFC 3860, August 2004. 1273 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1274 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1276 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1277 Description Protocol", RFC 4566, July 2006. 1279 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1280 Initiation Protocol (SIP) Event Package for Conference 1281 State", RFC 4575, August 2006. 1283 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1284 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1286 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1287 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1288 September 2007. 1290 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 1291 Centralized Conferencing", RFC 5239, June 2008. 1293 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1294 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1296 [I-D.ietf-sip-gruu] 1297 Rosenberg, J., "Obtaining and Using Globally Routable User 1298 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1299 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 1300 October 2007. 1302 14.2. Informative References 1304 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1305 April 2000. 1307 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1308 with Session Description Protocol (SDP)", RFC 3264, 1309 June 2002. 1311 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1312 Protocol (XMPP): Core", RFC 3920, October 2004. 1314 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1315 RFC 3966, December 2004. 1317 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1318 Session Initiation Protocol (SIP)", RFC 4353, 1319 February 2006. 1321 Authors' Addresses 1323 Aki Niemi 1324 Nokia 1325 P.O. Box 407 1326 NOKIA GROUP, FIN 00045 1327 Finland 1329 Phone: +358 50 389 1644 1330 Email: aki.niemi@nokia.com 1332 Miguel A. Garcia-Martin 1333 Ericsson 1334 Calle Via de los Poblados 13 1335 Madrid, ES 28033 1336 Spain 1338 Email: miguel.a.garcia@ericsson.com 1340 Geir A. Sandbakken (editor) 1341 TANDBERG 1342 Philip Pedersens vei 20 1343 N-1366 Lysaker 1344 Norway 1346 Phone: +47 67 125 125 1347 Email: geir.sandbakken@tandberg.com 1348 URI: http://www.tandberg.com