idnits 2.17.1 draft-ietf-simple-chat-06.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 == Line 602 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 (April 8, 2010) is 5130 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: 2 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: October 10, 2010 Ericsson 6 G. Sandbakken, Ed. 7 TANDBERG 8 April 8, 2010 10 Multi-party Chat Using the Message Session Relay Protocol (MSRP) 11 draft-ietf-simple-chat-06 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 October 10, 2010. 39 Copyright Notice 41 Copyright (c) 2010 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 . . . . . . . . . . . . 11 77 6.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 11 78 6.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 13 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. Nickname in a conference information document . . . . . . 26 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 95 10.1. New MSRP Method . . . . . . . . . . . . . . . . . . . . . 27 96 10.2. New MSRP Header . . . . . . . . . . . . . . . . . . . . . 27 97 10.3. New MSRP Status Codes . . . . . . . . . . . . . . . . . . 27 98 10.4. New SDP Attribute . . . . . . . . . . . . . . . . . . . . 27 99 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 100 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 101 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 14.1. Normative References . . . . . . . . . . . . . . . . . . . 28 104 14.2. Informative References . . . . . . . . . . . . . . . . . . 29 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 107 1. Introduction 109 The Message Session Relay Protocol (MSRP) [RFC4975] defines a 110 mechanism for sending a series of instant messages within a session. 111 The Session Initiation Protocol (SIP) [RFC3261] in combination with 112 the Session Description Protocol (SDP) [RFC3264] allows for two peers 113 to establish and manage such sessions. 115 In another application of SIP, a user agent can join in a multi-party 116 conversation called a conference that is hosted by a specialized user 117 agent called a focus [RFC4353]. Such a conference can naturally 118 involve MSRP sessions. It is the responsibility of an entity 119 handling the media to relay instant messages received from one 120 participant to the rest of the participants in the conference. 122 Several such systems already exist in the Internet. Participants in 123 a chat room can be identified with a pseudonym or nickname, and 124 decide whether their real identity is disclosed to other 125 participants. Participants can also use a rich set of features such 126 as the ability to send private instant messages to other 127 participants. 129 Similar conferences supporting chat rooms are already available 130 today. For example, Internet Relay Chat (IRC) [RFC2810], Extensible 131 Messaging and Presence Protocol [RFC3920] based chat rooms, and many 132 other proprietary systems provide chat room functionality. 133 Specifying equivalent functionality for MSRP-based systems provides 134 competitive features and enables interworking 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 155 [RFC2119], and indicate requirement levels for compliant 156 implementations. 158 This memo deals with tightly coupled SIP conferences defined in SIP 159 Conferencing Framework [RFC4353] adopting the terminology. In 160 addition to that terminology, we introduce some new 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 [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. It must be valid for 196 the length of the conference, and will be utilized by the MSRP 197 switch to forward messages to and from anonymous participants. 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 a 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. 384 The SIP URI from the dialog of which the participant is known to the 385 focus, MUST be notified to the MSRP switch. It will be used to 386 validate messages from participants, and to forward them accordingly. 388 Conference aware participants will detect that the peer is a focus 389 due to the presence of the "isfocus" feature tag [RFC3840] in the 390 Contact header field of the 200-class response to the INVITE request. 391 Conference unaware participants will not notice it is a foucs, and 392 can not apply the additional mechanisms defined in this document. 393 Participants are also aware that the mixer is an MSRP switch due to 394 the presence of an 'message' media type and either TCP/MSRP or TCP/ 395 TLS/MSRP as the protocol field in the SDP [RFC4566] media-line. 397 The conference focus of a chat room MUST include support for a 398 Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by 399 setting the 'accept-types' MSRP media line attribute in the SDP offer 400 or answer to include 'Message/CPIM'. 402 Note that the 'Message/CPIM' wrapper is used to carry the sender 403 information that, otherwise, it will not be available to the 404 recipient. Additionally, 'Message/CPIM' wrapper carries the 405 recipient information (e.g. To and Cc: headers). 407 If a participant wants to remain anonymous to the rest of the 408 participants in the conference, the participant's UA must provide an 409 anonymous URI to the conference focus. The URI will be used in the 410 From and To headers in the 'Message/CPIM' wrapper, and can be learned 411 by the other participants of the conference. The anonymous URI MUST 412 NOT reveal the participant's SIP AOR. 414 The conference focus of a chat room MUST learn the chat room 415 capabilities of each participant that joins the chat room, and MUST 416 inform the MSRP switch of such support. This is to prevent that the 417 MSRP switch distributes private messages to participants who do not 418 support private messaging. The recipient could be able to render the 419 private message, but not supporting private messages the participant 420 can not respond. 422 5.3. Deleting a Chat Room 424 As with creating a conference, the methods defined by the SIP 425 Conference Framework [RFC4353] for deleting a conference are directly 426 applicable to a chat room. The MSRP switch will terminate the MSRP 427 sessions with all the participants. 429 Deleting a chat room is an action that heavily depends on the policy 430 of the chat room. The policy can determine that the chat room is 431 deleted when the creator leaves the conference, or with any out of 432 band mechanism. 434 6. Sending and Receiving Instant Messages 436 6.1. Regular Messages 438 This section describes the conventions used to send and receive 439 instant messages that are addressed to all the participants in the 440 chat room. These are sent over a regular MSRP SEND request that 441 contains a Message/CPIM wrapper [RFC3862] that in turn contains the 442 desired payload (e.g. text, image, video-clip, etc.). 444 When a chat room participant wishes to send an instant message to all 445 the other participants in the chat room, he constructs an MSRP SEND 446 request that MUST contain a top-level wrapper of type 'Message/CPIM' 447 [RFC3862]. The actual instant message payload inside 'Message/CPIM' 448 MAY be of any type negotiated in the SDP 'accepted-types' attribute 449 according to the MSRP rules. 451 The sender SHOULD populate the From header of the Message/CPIM 452 wrapper with a proper identity by which the user is recognized in the 453 conference. Identities that can be used (among others) are: 455 o A SIP URI [RFC3261] representing the participant's address-of- 456 record 458 o A tel URI [RFC3966] representing the participant's telephone 459 number 461 o An IM URI [RFC3860] representing the participant's instant 462 messaging address 464 o An Anonymous URI [RFC3860] representing the paricipant's anonymous 465 adress 467 The MSRP switch that receives a SEND request from a participant 468 SHOULD first verify that the From header field of the Message/CPIM 469 wrapper is correctly populated with a valid URI. This focus MUST 470 notify the MSRP switch of the URI of which the participant is known 471 to validate it. 473 Then the MSRP switch should inspect the To header field of the 474 Message/CPIM wrapper. If the To header field of the Message/CPIM 475 wrapper contains the chat room URI, the MSRP switch can generate a 476 copy of the SEND request to each of the participants in the 477 conference except the sender. The MSRP switch MUST NOT modify any of 478 the bodies included in the received SEND request. Note that the MSRP 479 switch does not need to wait for the reception of the complete MSRP 480 chunk or MSRP message before it starts the distribution to the rest 481 of the participants. Instead, once the MSRP switch has received the 482 headers of the Message/CPIM body it SHOULD start the distribution 483 process. Having the Message/CPIM header only in the first chunk, the 484 MSRP switch MUST track the Message-Id until the last chunk of the 485 message has been distributed. 487 An MSRP endpoint that receives a SEND request from the MSRP switch 488 containing a Message/CPIM wrapper SHOULD first inspect the To header 489 field of the Message/CPIM body. If the To header field is set to the 490 chat room URI, it should render it as a regular message that has been 491 distributed to all the participants in the conference. Then the MSRP 492 endpoint SHOULD inspect the From header field of the Message/CPIM 493 body to identify the sender. The From header field will include a 494 URI that identifies the sender. The endpoint might have also 495 received further identity information through a subscription to the 496 SIP conference event package [RFC4575]. 498 6.2. Private Messages 500 This section describes the conventions used to send and receive 501 private instant messages, i.e., instant messages that are addressed 502 to one participant of the chat room rather to all of them. A chat 503 room can signal support for private messages using the chatroom- 504 attribute (see Section 8 for details). 506 When a chat room participant wishes to send a private instant message 507 to a participant the chat room, it follows the same procedures for 508 creating a SEND request as for regular messages (Section 6.1). The 509 only difference is that the MSRP endpoint MUST populate the To header 510 of the Message/CPIM with the identity of the intended recipient. The 511 identity can be SIP, TEL, and IM URIs typically learned from the 512 information received in notifications of the conference event package 513 [RFC4575]. 515 As for regular messages, the MSRP switch that receives a SEND request 516 from a participant SHOULD first verify that the From header field of 517 the Message/CPIM wrapper is correctly populated with a valid URI, and 518 that the recipient is supporting private messages. See section 519 Section 6.3 for report and response handling. If successful, the 520 MSRP switch should search it's mapping table to find the MSRP session 521 established towards the recipient. If a match is found the MSRP 522 switch MUST create a SEND request and MUST copy the contents of the 523 sender's message to it. 525 An MSRP endpoint that receives a SEND request from the MSRP switch 526 does the same validations as for regular messages (Section 6.1). If 527 the To header field is different from the chat room URI, the MSRP 528 endpoints know that it is a private message. It should render who it 529 is from based on the From header of the Message/CPIM wrapper 531 It is possible that a participant, identified by a SIP Address of 532 Record, joins a conference of instant messages from two or more 533 different SIP UAs. It is RECOMMENDED that the the MSRP switch can 534 map a participant or anonymous URI for two or more MSRP sessions. If 535 the policy of the server allows for this, the MSRP switch MUST copy 536 all messages intended for the recipient through each MSRP session. 538 6.3. MSRP reports and responses 540 The MSRP SHALL follow the success report and failure report handling 541 described in section 7 of [RFC4975]. For regular messages the MSRP 542 switch MUST act as a MSRP endpoint receiver of the request according 543 to section 5.3 of [RFC4975]. 545 For regular messages the MSRP switch MAY use any report model in the 546 copies of the regular SEND request intended for the recipients, but 547 any received reports MUST NOT be forwarded to the originator of the 548 original SEND request. This could lead to having the sender 549 receiving multiple reports for a single MSRP request. The MSRP 550 switch for regular messages SHALL construct responses according to 551 section 7.2 of [RFC4975]. If the URI included in the From header 552 field of the Message/CPIM wrapper is not valid (e.g, because it does 553 not "belong" to the user), the response code is 403. Otherwise the 554 response code is 200. 556 Private messages (section Section 6.2) handle MSRP reports 557 differently from regular chat room messages. The MSRP switch acts 558 transparently having an end-to-end relationship between the sender 559 and the recipient. The MSRP switch MUST for private messages keep 560 any Sucess-Report and Failure-Report headers in the relayed request. 561 Any reports or responses from the recipient MUST be forwarded to the 562 sender. 564 For private messages the MSRP switch MUST follow section 7.2 of 565 [RFC4975] in the following error scenarios. The MSRP switch MUST 566 inspect the To header field of the Message/CPIM wrapper. If the To 567 header field of the Message/CPIM wrapper in the request does not 568 contain the chat room URI, it must check if it contains a 569 participants URI associated with a participant. If the URI in the To 570 header can not be resolved (e.g. caused by a mistyped URI or that the 571 recipient has abandoned he chat room), the response error code is 572 404. The new 404 status code indicates a failure to resolve the 573 recipient URI in the To header field. If the recipient doesn't 574 support private messages, the response code is 428. The new response 575 428 indicate that the recipient does not support private messages. A 576 REPORT request MUST include a Message/CPIM wrapper, with the original 577 From header field included in the SEND request, and the To header 578 field of the original message. The message MUST NOT be forwarded to 579 the recipient if above conditions applies. 581 7. Nicknames 583 A common characteristic of existing chat room services is that 584 participants have the ability to present themselves with a nickname 585 to the rest of the participants of the conference. It is used for 586 easy reference of participants in the chat room, and can also provide 587 anonymous participants with a meaningful descriptive name. 589 A nickname is a useful construct in many use cases, of which MSRP 590 chat is but one example. It is associated with a URI of which the 591 participant is known to the focus. It is a user selectable 592 appearance of which the participant wants to be known to the other 593 participants. It is not a 'display-name', but it is used somewhat 594 like a display name. A main difference is that a nickname is unique 595 inside a chat room to allow an unambiguous reference to a participant 596 in the chat. Nicknames may be long lived, or may be temporary. 597 Users also need to reserve a nickname prior to its utilization. 599 This memo specifies the nickname as a string. The nickname string 600 MUST be unambiguous within the scope of the chat room (conference 601 instance). This scope is similar to having a nickname unique inside 602 a chat room from Extensible Messaging and Presence Protocol 603 [RFC3920]. The chat room may have policies associated with 604 nicknames. It may not accept nickname strings at all, or a it may 605 provide a wider unambiguous scope like a domain or server, similar to 606 Internet Relay Chat (IRC) [RFC2810]. 608 7.1. Using Nicknames within a Conference 610 This memo provides a mechanism to reserve a nickname for a 611 participant for as long as the participant is logged into the chat 612 room. The mechanism is based on a NICKNAME MSRP method (see below) 613 and a new "Use-Nickname" header. Note that other mechanisms may 614 exist (for example, a web page reservation system), although they are 615 outside the scope of this document. 617 A conference participant who has established an MSRP session with the 618 MSRP switch, where the MSRP switch has indicated the support and 619 availability of nicknames with the 'nicknames' token in the 620 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP 621 switch. The NICKNAME request MUST include a new Use-Nickname header 622 that contains the nickname string that the participant wants to 623 reserve. 625 The MSRP switch that receives a NICKNAME request containing a 626 nickname in the Use-Nickname header field SHOULD first verify whether 627 the policy of the chat room allows the nickname functionality. If is 628 not allowed, the MSRP the response code is 501 section 7.2 of 629 [RFC4975] for constructing a response. 631 If the policy of the chat room allows the usage of nicknames, the 632 MSRP switch SHOULD validate that the SIP AOR is entitled to reserve 633 the nickname. The participant's authenticated identity can be 634 derived after a successful HTTP Digest Authentication, included in a 635 trusted SIP P-Asserted-Identity header field, included in a valid SIP 636 Identity header field, or derived from any other present or future 637 SIP authentication mechanism. Once the MSRP switch has validated 638 that the participant is entitled to reserve the nickname, the 639 response code is 200. 641 The reservation of a nickname can fail, e.g. if the NICKNAME request 642 contains a malformed or non-existent Use-Nickname header field, or if 643 the same nickname has already been reserved by another participant in 644 the conference. The validation can also fail where the SIP AOR is 645 not entitled to reserve the nickname. In any of these cases the MSRP 646 response code is 423.The semantics of the 423 response are: "Nickname 647 usage failed; the nickname is not allocated to this user". 649 As indicated earlier, this specification defines a new MSRP header 650 field: "Use-Nickname". The Use-Nickname header field carries a 651 nickname string, and SHOULD be included in the NICKNAME requests. 653 The syntax of the NICKNAME method and the "Use-Nickname" header field 654 is built upon the MSRP formal syntax [RFC4975] 656 ext-method =/ NICKNAMEm 657 NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps 658 ext-header =/ Use-Nickname 659 ; ext-header is specified in RFC 4975 660 Use-Nickname = "Use-Nickname" ":" nickname 661 nickname = quoted-string 663 7.2. Modifying a Nickname 665 Typically participants will reserve a nickname as soon as they join 666 the chat room. But it is also possible for participants to modify 667 their own nicknames and replace them it a new one at any time during 668 the duration of the MSRP session. Modification of the nickname is 669 not different from the initial reservation and usage of a nickname, 670 thus the NICKNAME method is used as described in Section 7.1. 672 If a NICKNAME request that attempts to modify the current nickname of 673 the user for some reason fails, the current nickname stays in effect. 674 A new nickname comes into effect and the old one is released only 675 after a NICKNAME request is accepted with a 200 response. 677 7.3. Removing a Nickname 679 If the participant no longer wants to be known by a nickname in the 680 conference, the participant can follow the method described in 681 Section 7.2. The nickname element of the Use-Nickname header MUST be 682 set to an empty quoted string. 684 7.4. Nicknames in the Conference Event Package 686 Typically the conference focus acts as a notifier of the SIP 687 conference event package [RFC4575]. The conference focus MAY notify 688 subscribers of the nickname reserved by a given participant. We 689 define an extension to the conference event package to include 690 nicknames. The extension adds a child element to the 691 element containing the nickname string. 693 The following element is to be added to the sequence of the USER-TYPE 694 in the XML schema in conference event package [RFC4575] 696 698 7.5. Nicknames not supported nor allowed 700 The participants of the conference are identified by the SIP, TEL and 701 IM URI's typically learned from the information received in 702 notifications of the conference event package [RFC4575]. If 703 nicknames are not supported nor allowed, the participant list of the 704 conference will be less presentable. 706 8. The SDP 'chatroom' attribute 708 There are a handful of use cases where a participant would like to 709 learn the chat room capabilities supported by the MSRP switch and the 710 chat room. For example, a participant would like to learn if the 711 MSRP switch supports private messaging, otherwise, the participant 712 may send what he believes is a private instant message addressed to a 713 participant, but since the MSRP switch does not support the functions 714 specified in this memo, the message gets eventually distributed to 715 all the participants of the chat room. 717 The reverse case also exists. A participant, say Alice, whose user 718 agent does not support the extensions defined by this document joins 719 the chat room. The MSRP switch learns that Alice application does 720 not support private messaging nor nicknames. If another participant, 721 say Bob, sends a private message to Alice, the MSRP switch does not 722 distribute it to Alice, because Alice is not able to differentiate it 723 from a regular message sent to the whole roster. Further more, if 724 Alice replied to this message, she would do it to the whole roster. 725 Because of this, the MSRP switch keeps also track of users who do not 726 support the extensions defined in this document. 728 In another scenario, the policy of a chat room may indicate that 729 certain functions are not allowed. For example, the policy may 730 indicate that nicknames or private messages are not allowed. 732 In order to provide the user with a good chat room experience, we 733 define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a 734 media-level attribute that MAY be included in conjunction with and 735 MSRP media stream (i.e., when an m= line in SDP indicates "TCP/MSRP" 736 or "TCP/TLS/MSRP"). The 'chatroom' attribute indicates the 737 intersection of support and chat room local policy allowance for a 738 number of functions specified in this document. Specifically, we 739 provide the means for indicating support to use nicknames and private 740 messaging. 742 The 'chatroom' SDP attribute has the following syntax: 744 chatroom = chatroom-label ":" chat-token *(SP chat-token) 745 chatroom-label = "chatroom" 746 chat-token = (nicknames-token | private-msg-token | token) 747 nicknames-token = "nicknames" 748 private-msg-token = "private-messages" 750 A conference focus that includes the 'nicknames' token in the session 751 description is signaling that the MSRP switch supports and the chat 752 room allows to use of the procedures specified in Section 7. A 753 conference focus that includes the 'private-messages' in the SDP 754 description is signaling that the MSRP switch supports and the chat 755 room allows to use of the procedures specified in Section 6.2. 757 Example of the 'chatroom' attribute for an MSRP media stream that 758 indicates the acceptance of nicknames and private messages: 760 a=chatroom:nickname private-messages 762 9. Examples 764 9.1. Joining a chat room 766 Figure 3 presents a flow diagram where Alice joins a chat room by 767 sending an INVITE request. This INVITE request contains a session 768 description that includes the chatroom extensions defined in this 769 document. 771 Alice Conference focus 772 | | 773 |(1) (SIP) INVITE | 774 |----------------------->| 775 |(2) (SIP) 200 OK | 776 |<-----------------------| 777 |(3) (SIP) ACK | 778 |----------------------->| 779 | | 781 Figure 3: Flow diagram of a user joining a chat room 783 F1: Alice constructs an SDP description that includes an MSRP media 784 stream. She also indicates her support for the chatroom extensions 785 defined in this document. She sends the INVITE request to the chat 786 room server. 788 INVITE sip:chatroom22@chat.example.com SIP/2.0 789 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 790 Max-Forwards: 70 791 From: Alice ;tag=9fxced76sl 792 To: Chatroom 22 793 Call-ID: 3848276298220188511@atlanta.example.com 794 CSeq: 1 INVITE 795 Contact: 796 Content-Type: application/sdp 797 Content-Length: [length] 799 v=0 800 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 801 s=- 802 c=IN IP4 atlanta.example.com 803 m=message 7654 TCP/MSRP * 804 a=accept-types:message/cpim text/plain text/html 805 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 806 a=chatroom:nickname private-messages 808 Figure 4: INVITE request containing an SDP offer with chat room 809 extensions 811 F2: The chat room server accepts the session establishment. It 812 includes the 'isfocus' and other relevant feature tags in the Contact 813 header field of the response. The chat room server also builds an 814 SDP answer that also that forces the reception of messages wrapped in 815 message/cpim envelops. It also includes the the chatroom attribute 816 with the allowed extensions. 818 SIP/2.0 200 OK 819 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 820 ;received=192.0.2.101 821 From: Alice ;tag=9fxced76sl 822 To: Chatroom 22 ;tag=8321234356 823 Call-ID: 3848276298220188511@atlanta.example.com 824 CSeq: 1 INVITE 825 Contact: \ 826 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \ 827 ;automata;isfocus;message;event="conference" 828 Content-Type: application/sdp 829 Content-Length: [length] 831 v=0 832 o=chat 2890844527 2890844527 IN IP4 chat.example.com 833 s=- 834 c=IN IP4 chat.example.com 835 m=message 12763 TCP/MSRP * 836 a=accept-types:message/cpim 837 a=accept-wrapped-types:text/plain text/html * 838 a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 839 a=chatroom:nickname private-messages 841 Figure 5: 200 (OK) response including chat room extensions 843 F3: The session established is acknowledged (details not shown). 845 9.2. Setting up a nickname 847 Figure 6 shows an example of Alice setting up a nickname using the 848 conference as provider. Her first proposal is not accepted because 849 the proposed nickname is already in use. Her second proposal is 850 accepted. 852 Alice MSRP switch 853 | | 854 |(1) (MSRP) NICKNAME | 855 |----------------------->| 856 |(2) (MSRP) 423 | 857 |<-----------------------| 858 |(3) (MSRP) NICKNAME | 859 |----------------------->| 860 |(4) (MSRP) 200 | 861 |<-----------------------| 862 | | 864 Figure 6: Flow diagram of a user setting up her nickname 866 F1: Alice sends an MSRP NICKNAME request that contains her proposed 867 nicknames in the Set-Nickname header field. 869 MSRP d93kswow NICKNAME 870 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 871 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 872 Use-Nickname: "Alice the great" 873 -------d93kswow$ 875 Figure 7: MSRP NICKNAME request with an initial nickname proposal 877 F2: The MSRP switch analyzes the existing allocation of nicknames and 878 detects that the nickname "Alice the great" is already provided to 879 another participant by the conference. The MSRP switch answers with 880 a 423 response. 882 MSRP d93kswow 423 Nickname usage failed 883 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 884 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 885 -------d93kswow$ 887 Figure 8: MSRP 423 response 889 F3: Alice receives the response. She proposes a new nickname in a 890 second NICKNAME request. 892 MSRP 09swk2d NICKNAME 893 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 894 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 895 Use-Nickname: "Alice in Wonderland" 896 -------09swk2d$ 898 Figure 9: MSRP NICKNAME request with a second nickname proposal 900 F4: The MSRP switch accepts the nickname proposal and answers with a 901 200 response. 903 MSRP 09swk2d 200 OK 904 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 905 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 906 -------09swk2d$ 908 Figure 10: MSRP NICKNAME request 910 9.3. Sending a regular message to the chat room 912 Figure 11 depicts a flow diagram where Alice is sending a regular 913 message addressed to the chat room. The MSRP switch distributes the 914 message to the rest of the participants. 916 Alice MSRP switch Bob Charlie 917 | | | | 918 | (1) (MSRP) SEND | | | 919 |--------------------->| (3) (MSRP) SEND | | 920 | (2) (MSRP) 200 |----------------------->| | 921 |<---------------------| (4) (MSRP) SEND | | 922 | |------------------------------->| 923 | | (5) (MSRP) 200 OK | | 924 | |<-----------------------| | 925 | | (6) (MSRP) 200 OK | | 926 | |<------------------------------ | 927 | | | | 928 | | | | 930 Figure 11: Sending a regular message to the chat room 932 F1: Alice builds a text message and wraps it in a CPIM message. She 933 addresses the CPIM message to the chat room. She encloses the result 934 in an MSRP SEND request and sends it to the MSRP switch via the 935 existing TCP connection. 937 MSRP 3490visdm SEND 938 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 939 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 940 Message-ID: 99s9s2 941 Byte-Range: 1-*/* 942 Content-Type: message/cpim 944 To: 945 From: 946 DateTime: 2009-03-02T15:02:31-03:00 947 Content-Type: text/plain 949 Hello guys, how are you today? 950 -------3490visdm$ 952 Figure 12: Instant message addressed to all participants in the chat 953 room 955 F2: The MSRP switch acknowledges the reception of the SEND request 956 with a 200 (OK) response. 958 MSRP 3490visdm 200 OK 959 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 960 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 961 Message-ID: 99s9s2 962 Byte-Range: 1-*/* 963 -------3490visdm$ 965 Figure 13: 200 (OK) response 967 F3: The MSRP switch creates a new MSRP SEND request that contains the 968 received message/cpim body and sends it to Bob. 970 MSRP 490ej23 SEND 971 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 972 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 973 Message-ID: 304sse2 974 Byte-Range: 1-*/* 975 Content-Type: message/cpim 977 To: 978 From: 979 DateTime: 2009-03-02T15:02:31-03:00 980 Content-Type: text/plain 982 Hello guys, how are you today? 983 -------490ej23$ 985 Figure 14: Instant message sent to all participants 987 The rest of the message flows are analogous to the previous. They 988 are not shown here. 990 9.4. Sending a private message to a participant 992 Figure 15 depicts a flow diagram where Alice is sending a private 993 message addressed to Bob's SIP AOR. The MSRP switch distributes the 994 message only to Bob. 996 Alice MSRP switch Bob 997 | | | 998 | (1) (MSRP) SEND | | 999 |--------------------->| (3) (MSRP) SEND | 1000 | (2) (MSRP) 200 |----------------------->| 1001 |<---------------------| | 1002 | | | 1003 | | | 1005 Figure 15: Sending a private message to Bob 1007 F1: Alice builds a text message and wraps it in a CPIM message. She 1008 addresses the CPIM message to the Bob's nickname, which she learned 1009 from a notification in the conference event package. She encloses 1010 the result in an MSRP SEND request and sends it to the MSRP switch 1011 via the existing TCP connection. 1013 MSRP 6959ssdf SEND 1014 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1015 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1016 Message-ID: okj3kw 1017 Byte-Range: 1-*/* 1018 Content-Type: message/cpim 1020 To: 1021 From: 1022 DateTime: 2009-03-02T15:02:31-03:00 1023 Content-Type: text/plain 1025 Hello Bob. 1026 -------6959ssdf$ 1028 Figure 16: Private instant message addressed to one participant 1030 F2: The MSRP switch acknowledges the reception of the SEND request 1031 with a 200 (OK) response. 1033 MSRP 6959ssdfm 200 OK 1034 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1035 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1036 Message-ID: okj3kw 1037 Byte-Range: 1-*/* 1038 -------6959ssdfm$ 1040 Figure 17: 200 (OK) response 1042 F3: The MSRP switch creates a new MSRP SEND request that contains the 1043 received message/cpim body and sends it only to Bob. Bob can 1044 distinguish the sender in the From header of the CPIM message. He 1045 also identifies this as a private message due to the To CPIM header. 1047 MSRP 9v9s2 SEND 1048 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1049 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1050 Message-ID: d9fghe982 1051 Byte-Range: 1-*/* 1052 Content-Type: message/cpim 1054 To: 1055 From: 1056 DateTime: 2009-03-02T15:02:31-03:00 1057 Content-Type: text/plain 1059 Hello Bob. 1060 -------9v9s2$ 1062 Figure 18: Private instant message sent to Bob 1064 9.5. Chuncked private message 1066 Figure 19 depicts an example of the private message in Section 9.4 1067 split in two chuncks. The MSRP switch must wait for the complete set 1068 of CPIM headers before distributing the messages. 1070 MSRP 7443ruls SEND 1071 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1072 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1073 Message-ID: aft4to 1074 Byte-Range: 1-*/174 1075 Content-Type: message/cpim 1077 To: 1078 From: 1079 -------7443ruls$ 1081 MSRP 7443ruls SEND 1082 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1083 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1084 Message-ID: aft4to 1085 Byte-Range: 68-174/174 1086 Content-Type: message/cpim 1088 DateTime: 2009-03-02T15:02:31-03:00 1089 Content-Type: text/plain 1091 Hello Bob 1092 -------7443ruls$ 1094 Figure 19: Chuncked private message 1096 9.6. Nickname in a conference information document 1098 Figure 20 depicts two user elements in a conference information 1099 document both having the nickname element with a nickname string. 1101 1102 1106 1109 1110 MSRP nickname example 1111 1112 1115 1116 2 1117 1118 1121 1122 1123 Dopey Donkey 1124 1125 1128 1129 Depressed Donkey 1130 1131 1132 1134 Figure 20: Nickname in a conference information document 1136 10. IANA Considerations 1137 10.1. New MSRP Method 1139 This specification defines a new MSRP method to be added to the 1140 Methods sub-registry under the MSRP Parameter registry: NICKNAME. 1141 See section Section 7 for details. 1143 10.2. New MSRP Header 1145 This specification defines a new MSRP header to be added to the 1146 header-field sub registry under the MSRP Parameter registry: 1147 Use-Nickname. See section Section 7 for details. 1149 10.3. New MSRP Status Codes 1151 This specification defines three new MSRP status codes to be added to 1152 the Status-Code sub-registry under MSRP parameters. 1154 The 404 status code indicates the failure to resolve the recipient 1155 URI in the To header field of the Message/CPIM wrapper in the SEND 1156 request. See section for details. 1158 The 428 status code indicates that the recipient of a SEND request 1159 does not support private messages. See section for details. 1161 The 423 response indicates that the requested nickname is not 1162 allocated to the user requesting it. See section Section 7 for 1163 details. 1165 10.4. New SDP Attribute 1167 This specification defines a new media level attribute in the Session 1168 Description Protocol (SDP) Parameters registry: chatroom. See 1169 section Section 8 for details. 1171 11. Security Considerations 1173 This document proposes extensions to the Message Session Relay 1174 Protocol [RFC4975]. Therefore, the security considerations of such 1175 document apply to this document as well. 1177 In general, messages sent to a multi-party session based messaging 1178 focus are not deem to expose any security threat. Nevertheless, if a 1179 participant wants to avoid eavesdropping from non authorized 1180 entities, it should send those messages a TLS [RFC5246] transport 1181 connection, as allowed by MSRP. 1183 Nicknames will be used to show the appearances of the participants of 1184 the conference. A successful take over of a nickname from a 1185 participant might lead to private messages to be sent to the wrong 1186 destination. The recipient's URI will be different from the URI 1187 associated to the original owner of the nickname, but the sender 1188 might not notice this. To avoid take overs the MSRP switch MUST make 1189 sure that a nickname is unique inside a chat room. Also the security 1190 consideration for any authenticated identity mechanisms used to 1191 validate the SIP AOR will apply to this document as well. If a 1192 nickname can be reserved if it previously has been used by another 1193 participant in the chat room, is up to the policy of the chat room. 1195 12. Contributors 1197 This work would have never been possible without the fruitful 1198 discussions in the SIMPLE WG mailing list, specially with Brian Rosen 1199 (Neustar) and Paul Kyzivat (Cisco), who provided extensive review and 1200 improvements throughout the document. 1202 13. Acknowledgments 1204 The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, 1205 Matt Lepinski, Mary Barnes and Ben Campbell for providing comments. 1207 14. References 1209 14.1. Normative References 1211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1212 Requirement Levels", BCP 14, RFC 2119, March 1997. 1214 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1215 A., Peterson, J., Sparks, R., Handley, M., and E. 1216 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1217 June 2002. 1219 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1220 "Indicating User Agent Capabilities in the Session 1221 Initiation Protocol (SIP)", RFC 3840, August 2004. 1223 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1224 (CPIM)", RFC 3860, August 2004. 1226 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1227 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1229 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1230 Description Protocol", RFC 4566, July 2006. 1232 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1233 Initiation Protocol (SIP) Event Package for Conference 1234 State", RFC 4575, August 2006. 1236 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1237 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1239 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1240 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1241 September 2007. 1243 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 1244 Centralized Conferencing", RFC 5239, June 2008. 1246 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1247 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1249 14.2. Informative References 1251 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1252 April 2000. 1254 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1255 with Session Description Protocol (SDP)", RFC 3264, 1256 June 2002. 1258 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1259 Protocol (XMPP): Core", RFC 3920, October 2004. 1261 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1262 RFC 3966, December 2004. 1264 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1265 Session Initiation Protocol (SIP)", RFC 4353, 1266 February 2006. 1268 Authors' Addresses 1270 Aki Niemi 1271 Nokia 1272 P.O. Box 407 1273 NOKIA GROUP, FIN 00045 1274 Finland 1276 Phone: +358 50 389 1644 1277 Email: aki.niemi@nokia.com 1279 Miguel A. Garcia-Martin 1280 Ericsson 1281 Calle Via de los Poblados 13 1282 Madrid, ES 28033 1283 Spain 1285 Email: miguel.a.garcia@ericsson.com 1287 Geir A. Sandbakken (editor) 1288 TANDBERG 1289 Philip Pedersens vei 20 1290 N-1366 Lysaker 1291 Norway 1293 Phone: +47 67 125 125 1294 Email: geir.sandbakken@tandberg.com 1295 URI: http://www.tandberg.com