idnits 2.17.1 draft-ietf-simple-chat-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to 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 (May 31, 2010) is 5078 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 (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft Nokia 4 Intended status: Standards Track M. Garcia-Martin 5 Expires: December 2, 2010 Ericsson 6 G. Sandbakken, Ed. 7 TANDBERG 8 May 31, 2010 10 Multi-party Chat Using the Message Session Relay Protocol (MSRP) 11 draft-ietf-simple-chat-07 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 December 2, 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 . . . . . . . . . . . . 12 77 6.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 12 78 6.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 13 79 6.3. MSRP reports and responses . . . . . . . . . . . . . . . . 15 80 7. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 7.1. Using Nicknames within a Conference . . . . . . . . . . . 16 82 7.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 17 83 7.3. Removing a Nickname . . . . . . . . . . . . . . . . . . . 18 84 7.4. Nicknames in the Conference Event Package . . . . . . . . 18 85 7.5. Nicknames not supported nor allowed . . . . . . . . . . . 18 86 8. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . . . 18 87 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 19 89 9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 21 90 9.3. Sending a regular message to the chat room . . . . . . . . 22 91 9.4. Sending a private message to a participant . . . . . . . . 24 92 9.5. Chuncked private message . . . . . . . . . . . . . . . . . 26 93 9.6. Nickname in a conference information document . . . . . . 26 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 95 10.1. New MSRP Method . . . . . . . . . . . . . . . . . . . . . 27 96 10.2. New MSRP Header . . . . . . . . . . . . . . . . . . . . . 28 97 10.3. New MSRP Status Codes . . . . . . . . . . . . . . . . . . 28 98 10.4. New SDP Attribute . . . . . . . . . . . . . . . . . . . . 29 99 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 100 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 101 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 103 14.1. Normative References . . . . . . . . . . . . . . . . . . . 30 104 14.2. Informative References . . . . . . . . . . . . . . . . . . 31 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 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 RFC 4353 [RFC4353]. 174 Sender: the conference participant that originally created an 175 instant message and sent it to the chat room for delivery. 177 Recipient: the destination conference participant(s). This 178 defaults to the full conference participant list, minus the IM 179 Sender. 181 MSRP switch: a media level entity that is a MSRP endpoint. It is a 182 special MSRP endpoint that receives MSRP messages, and delivers 183 them to the other conference participants. The MSRP switch has a 184 similar role to a conference mixer with the exception that the 185 MSRP switch does not actually "mix" together different input media 186 streams; it merely relays the messages between participants. 188 Private Instant Message: an instant message sent in a chat room 189 intended for a single participant. A private IM is usually 190 rendered distinctly from the rest of the IMs, indicating that the 191 message was a private communication. 193 Anonymous URI: a URI concealing the participant's SIP AOR from the 194 other participants in the conference. The allocation of such a 195 URI is out of scope of this specification. An anonymous URI must 196 be valid for the length of the conference, and will be utilized by 197 the MSRP switch to forward messages to and from anonymous 198 participants. 200 3. Motivations and Requirements 202 Although conference frameworks describing many types of conferencing 203 applications already exist, such as the Framework for Centralized 204 Conferencing [RFC5239] and the SIP Conferencing Framework [RFC4353], 205 the exact details of session-based instant messaging conferences are 206 not well-defined at the moment. 208 To allow interoperable chat implementations, for both conference- 209 aware, and conference-unaware user agents, certain conventions for 210 MSRP conferences need to be defined. It also seems beneficial to 211 provide a set of features that enhance the baseline multi-party MSRP 212 in order to be able to create systems that have functionality on par 213 with existing chat systems, as well as enable building interworking 214 gateways to these existing chat systems. 216 We define the following requirements: 218 REQ-1: A basic requirement is the existence of a multi-party 219 conference, where participants can join and leave the 220 conference and get instant messages exchanged to the rest of 221 the participants. 223 REQ-2: A conference participant must be able to determine the 224 identities of the sender and recipient of the received IMs. 226 REQ-3: A conference participant must be able to determine the 227 recipient of the received message. For instance, the 228 recipient of the message might be the entire conference or a 229 single participant of the conference (i.e., a private 230 message). 232 REQ-4: It must be possible to send a message to a single participant 233 within the conference (i.e., a private instant message). 235 REQ-5: A conference participant may have a nickname or pseudonym 236 associated with their real identity. 238 REQ-6: It must be possible for a participant to change their 239 nickname during the progress of the conference. 241 REQ-7: It must be possible that a participant is only known by an 242 anonymous identity and not their real identity to the rest of 243 the conference. 245 REQ-8: It must be possible for the MSRP switch to originate IMs to 246 the conference as an owner or administrator (e.g. message of 247 the day, welcome messages, server is shutting down, etc.) 249 REQ-9: It must be possible for the conference participants to learn 250 the chat room capabilities described in this document. 252 4. Overview of Operation 254 In order to set up a conference, one must first be created. Users 255 wishing to host a conference themselves can of course do just that; 256 their User Agent (UA) simply morphs from an ordinary UA into a 257 special purpose one called a Focus UA. Another, commonly used setup 258 is one where a dedicated node in the network functions as a Focus UA. 260 Each chat room has an identity of its own: a SIP URI that 261 participants use to join the conference, e.g. by sending an INVITE 262 request. The conference focus processes the invitations, and as 263 such, maintains SIP dialogs with each participant. In a multi-party 264 chat, or chat room, MSRP is one of the established media streams. 265 Each conference participant establishes an MSRP session with the MSRP 266 switch, which is a special purpose MSRP application. The MSRP 267 sessions can be relayed by one or more MSRP relays, which are 268 specified in RFC 4976 [RFC4976]. This is illustrated in Figure 1 269 MSRP Sessions 270 +---------------------------+ 271 | +-----------+ | 272 +---+--+ +---+--+ | | 273 | SIP | | SIP | | | 274 | MSRP | | MSRP | +--+---+----+ 275 |Client| |Client| | MSRP | 276 +---+--+ ++-----+ | Relay | 277 | | +-----+-----+ 278 SIP Dialogs | / | 279 | | | MSRP Sessions 280 +----+------+--+ | 281 | Conference | +-------+-----+ 282 | Focus UA | | MSRP | 283 | |........| Switch | 284 | | | | 285 +---+--------+-+ +-------+-----+ 286 | \ | 287 SIP Dialogs | | | MSRP Sessions 288 | \ | 289 +--+---+ +-+----+ +-----+------+ 290 | SIP | | SIP | | MSRP | 291 | MSRP | | MSRP | | Relay | 292 |Client| |Client| +-+-------+--+ 293 +---+--+ +--+---+ | | 294 | +-----------+ | 295 +------------------------------+ 296 MSRP sessions 298 Figure 1: Multi-party chat overview shown with MSRP Relays and a 299 conference Focus UA 301 The MSRP switch is similar to a conference mixer in that it handles 302 media sessions with each of the participants and bridges these 303 streams together. However, unlike a conference mixer, the MSRP 304 switch merely forwards messages between participants but doesn't 305 actually mix the streams in any way. The system is illustrated in 306 Figure 2. 308 +------+ 309 | MSRP | 310 |Client| 311 +------+ +--.---+ +------+ 312 | MSRP | | | MSRP | 313 |Client| | _|Client| 314 +------._ | ,' +------+ 315 `._ | ,' 316 `.. +----------+ ,' 317 `| |' 318 | MSRP | 319 | Switch | 320 ,| |_ 321 _,-'' +----------+ ``-._ 322 +------.-' | `--+------+ 323 | MSRP | | | MSRP | 324 |Client| | |Client| 325 +------+ | +------+ 326 +---'--+ 327 | MSRP | 328 |Client| 329 +------+ 331 Figure 2: Multi-party chat in a Centralized Conference 333 Typically conference participants also subscribe to the conference 334 event package [RFC4575] to gather information about the conference 335 roster in the form of conference state notifications. For example, 336 participants can learn about other participants' identities. 338 All messages in the chat room use the 'Message/CPIM' wrapper content 339 type [RFC3862], so that it is possible to distinguish between private 340 and regular messages. When a participant wants to send an instant 341 message to the conference, it constructs an MSRP SEND request and 342 submits it to the MSRP switch including a regular payload (e.g. a 343 Message/CPIM message that contains a text, HTML, an image, etc.). 344 The Message/CPIM To header is set to the chat room URI. The switch 345 then fans out the SEND request to all of the other participants using 346 their existing MSRP sessions. 348 A participant can also send a private instant message addressed to a 349 participant whose identity has been learned, e.g. via a notification 350 from the conference event package [RFC4575]. In this case the sender 351 creates an MSRP SEND request with a Message/CPIM body whose To header 352 contains not the chat room URI but the recipient's URI. The MSRP 353 switch then forwards the SEND request to the recipient. This 354 specification supports the sending of private messages to one and 355 only one recipient. However, if the recipient is logged from 356 different endpoints, the MSRP switch will distribute the private 357 message to each endpoint the recipient is logged. 359 We extend the current MSRP negotiation that takes place in SDP 360 [RFC4566] to allow participants to learn whether the chat room 361 supports and is willing to accept (e.g. due to local policy 362 restrictions) certain MSRP functions defined in this memo, such as 363 nicknames or private messaging. 365 Naturally, when a participant wishes to leave a chat room, it sends a 366 SIP BYE request to the Focus UA and terminates the SIP dialog with 367 the focus and MSRP sessions with the MSRP switch. 369 This document assumes that each chat room is allocated its own SIP 370 URI. A user joining a chat room sends an INVITE request to that SIP 371 URI, and as a result, a new MSRP session is established between the 372 user and the MSRP switch. It is assumed that an MSRP session is 373 mapped to a chat room. If a user wants to join a second chat room, 374 he creates a different INVITE request, through a different SIP 375 dialog, which leads to the creation of a second MSRP session between 376 the user and the MSRP switch. Notice that these two MSRP sessions 377 can still be multiplexed over the same TCP connection as per regular 378 MSRP procedures. However, each chat room is associated to a unique 379 MSRP session and a unique SIP dialog. 381 5. Creating, Joining, and Deleting a Chat Room 383 5.1. Creating a Chat Room 385 Since we consider a chat room a particular type of conference having 386 MSRP media, the methods defined by the SIP Conference Framework 387 [RFC4353] for creating conferences are directly applicable to a chat 388 room. 390 Once a chat room is created, it is identified by a SIP URI, like any 391 other conference. 393 5.2. Joining a Chat Room 395 Participants usually join the conference by sending an INVITE request 396 to the conference URI. As long as the conference policy allows, the 397 INVITE request is accepted by the focus and the user is brought into 398 the conference. 400 The MSRP switch needs to be aware of the URIs of the participant 401 (SIP, Tel, or IM URIs) in order to validate messages sent from this 402 participant prior to their forwarding. This information is known to 403 the focus of the conference. Therefore an interface between the 404 focus and the MSRP switch is assumed. However, the interface between 405 the focus and the MSRP switch is outside the scope of this document. 407 Conference aware participants will detect that the peer is a focus 408 due to the presence of the "isfocus" feature tag [RFC3840] in the 409 Contact header field of the 200-class response to the INVITE request. 410 Conference unaware participants will not notice it is a focus, and 411 can not apply the additional mechanisms defined in this document. 412 Participants are also aware that the mixer is an MSRP switch due to 413 the presence of an 'message' media type and either TCP/MSRP or TCP/ 414 TLS/MSRP as the protocol field in the SDP [RFC4566] media-line. 416 The conference focus of a chat room MUST include support for a 417 Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by 418 setting the 'accept-types' MSRP media line attribute in the SDP offer 419 or answer to include 'Message/CPIM'. 421 Note that the 'Message/CPIM' wrapper is used to carry the sender 422 information that, otherwise, it will not be available to the 423 recipient. Additionally, 'Message/CPIM' wrapper carries the 424 recipient information (e.g. To and Cc: headers). 426 If a participant wants to remain anonymous to the rest of the 427 participants in the conference, the participant's UA must provide an 428 anonymous URI to the conference focus. The URI will be used in the 429 From and To headers in the 'Message/CPIM' wrapper, and can be learned 430 by the other participants of the conference. Notice that in order 431 for the anonymity mechanism to work, the anonymous URI must not 432 reveal the participant's SIP AOR. The mechanism for acquiring an 433 anonymous URI is outside the scope of this specification. 435 The conference focus of a chat room MUST learn the chat room 436 capabilities of each participant that joins the chat room. The 437 conference focus must inform the MSRP switch of such support in order 438 to prevent the MSRP switch from distributing private messages to 439 participants who do not support private messaging. The recipient 440 would not be able to render the message as private, and any potential 441 reply would be sent to the whole chat room. 443 5.3. Deleting a Chat Room 445 As with creating a conference, the methods defined by the SIP 446 Conference Framework [RFC4353] for deleting a conference are directly 447 applicable to a chat room. The MSRP switch will terminate the MSRP 448 sessions with all the participants. 450 Deleting a chat room is an action that heavily depends on the policy 451 of the chat room. The policy can determine that the chat room is 452 deleted when the creator leaves the conference, or with any out of 453 band mechanism. 455 6. Sending and Receiving Instant Messages 457 6.1. Regular Messages 459 This section describes the conventions used to send and receive 460 instant messages that are addressed to all the participants in the 461 chat room. These are sent over a regular MSRP SEND request that 462 contains a Message/CPIM wrapper [RFC3862] that in turn contains the 463 desired payload (e.g. text, image, video-clip, etc.). 465 When a chat room participant wishes to send an instant message to all 466 the other participants in the chat room, it constructs an MSRP SEND 467 request according to the procedures specified in RFC 4975 [RFC4975]. 468 The sender MAY choose the desired MSRP report model (e.g., populate 469 the Success-Report and Failure-Report MSRP header fields). 471 The SEND request MUST contain a top-level wrapper of type 'Message/ 472 CPIM' according to RFC 3862 [RFC3862]. The actual instant message 473 payload MUST be included as payload of the 'Message/CPIM' wrapper and 474 MAY be of any type negotiated in the SDP 'accept-types' attribute 475 according to the MSRP rules. 477 On sending a regular message the sender MUST populate the To header 478 of the Message/CPIM wrapper with the URI of the chat room. The 479 sender SHOULD populate the From header of the Message/CPIM wrapper 480 with a proper identity by which the user is recognized in the 481 conference. Identities that can be used (among others) are: 483 o A SIP URI [RFC3261] representing the participant's address-of- 484 record 486 o A tel URI [RFC3966] representing the participant's telephone 487 number 489 o An IM URI [RFC3860] representing the participant's instant 490 messaging address 492 o An Anonymous URI representing the participant's anonymous address 494 An MSRP switch that receives a SEND request from a participant SHOULD 495 first verify that the From header field of the Message/CPIM wrapper 496 is correctly populated with a valid URI of a participant. This 497 imposes a requirement for the focus of the conference to inform the 498 MSRP switch the URIs which the participant is known, in order for the 499 MSRP switch to validate messages. Section 6.3 provides further 500 information with the actions to be taken in case this validation 501 fails. 503 If the MSRP switch receives a message containing several To header 504 fields in the Message/CPIM wrapper the MSRP switch MUST reject the 505 MSRP SEND request with a 403 response, as per procedures in RFC 4975 506 [RFC4975]. 508 Then the MSRP switch should inspect the To header field of the 509 Message/CPIM wrapper. If the To header field of the Message/CPIM 510 wrapper contains the chat room URI and there are no other To header 511 fields, the MSRP switch can generate a copy of the SEND request to 512 each of the participants in the conference except the sender. The 513 MSRP switch MUST NOT modify the content received in the SEND request. 514 However, the MSRP switch MAY re-chunk any of the outbound MSRP SEND 515 requests. 517 Note that the MSRP switch does not need to wait for the reception of 518 the complete MSRP chunk or MSRP message before it starts the 519 distribution to the rest of the participants. Instead, once the MSRP 520 switch has received the headers of the Message/CPIM body it SHOULD 521 start the distribution process. Having the Message/CPIM header only 522 in the first chunk, the MSRP switch MUST track the Message-Id until 523 the last chunk of the message has been distributed. 525 An MSRP endpoint that receives a SEND request from the MSRP switch 526 containing a Message/CPIM wrapper SHOULD first inspect the To header 527 field of the Message/CPIM body. If the To header field is set to the 528 chat room URI, it should render it as a regular message that has been 529 distributed to all the participants in the conference. Then the MSRP 530 endpoint SHOULD inspect the From header field of the Message/CPIM 531 body to identify the sender. The From header field will include a 532 URI that identifies the sender. The endpoint might have also 533 received further identity information through a subscription to the 534 SIP conference event package [RFC4575]. 536 6.2. Private Messages 538 This section describes the conventions used to send and receive 539 private instant messages, i.e., instant messages that are addressed 540 to one participant of the chat room rather to all of them. A chat 541 room can signal support for private messages using the chatroom- 542 attribute (see Section 8 for details). 544 When a chat room participant wishes to send a private instant message 545 to a participant the chat room, it follows the same procedures for 546 creating a SEND request as for regular messages (Section 6.1). The 547 only difference is that the MSRP endpoint MUST populate a single To 548 header of the Message/CPIM with the identity of the intended 549 recipient. The identity can be SIP, TEL, and IM URIs typically 550 learned from the information received in notifications of the 551 conference event package [RFC4575]. 553 As for regular messages, an MSRP switch that receives a SEND request 554 from a participant SHOULD first verify that the From header field of 555 the Message/CPIM wrapper is correctly populated with a valid URI 556 (i.e., the URI is a participant of this chat room). Section 6.3 557 provides further information with the actions to be taken in case 558 this validation fails. 560 If the MSRP switch receives a message containing several To header 561 fields in the Message/CPIM wrapper the MSRP switch MUST reject the 562 MSRP SEND request with a 403 response, as per procedures in RFC 4975 563 [RFC4975]. 565 Then the MSRP switch MUST verify that the To header of the Message/ 566 CPIM wrapper is a participant of the chat room. If this To header 567 field does not contain the URI of a participant of the chat room or 568 if the To header field cannot be resolved (e.g., caused by a mistyped 569 URI), the MSRP switch MUST reject the request with a 404 response. 570 This new 404 status code indicates a failure to resolve the recipient 571 URI in the To header field of the Message/CPIM wrapper. 573 Notice the importance of the From and To headers in the Message/ 574 CPIM wrapper. If an intermediary modifies these values, the MSRP 575 switch might not be able to identify the source or intended 576 destination of the message, resulting in a rejection of the 577 message. 579 Finally, the MSRP switch MUST verify that the recipient supports 580 private messages. If the recipient does not support private 581 messages, the MSRP switch MUST reject the request with a 428 582 response. This new response 428 indicate that the recipient does not 583 support private messages. Any potential REPORT request that the MSRP 584 switch sends to the sender MUST include a Message/CPIM wrapper 585 containing the original From header field included in the SEND 586 request and the To header field of the original Message/CPIM wrapper. 587 The MSRP switch MUST NOT forward private messages to a recipient that 588 does not support private messaging. 590 If successful, the MSRP switch should search its mapping table to 591 find the MSRP sessions established towards the recipient. If a match 592 is found the MSRP switch MUST create a SEND request and MUST copy the 593 contents of the sender's message to it. 595 An MSRP endpoint that receives a SEND request from the MSRP switch 596 does the same validations as for regular messages (Section 6.1). If 597 the To header field is different from the chat room URI, the MSRP 598 endpoints know that it is a private message. It should render who it 599 is from based on the From header of the Message/CPIM wrapper 601 It is possible that a participant, identified by a SIP Address of 602 Record or other valid URI, joins a conference of instant messages 603 from two or more different SIP UAs. It is RECOMMENDED that the the 604 MSRP switch can map a URI to two or more MSRP sessions. If the 605 policy of the server allows for this, the MSRP switch MUST copy all 606 messages intended to the recipient through each MSRP session mapped 607 to the recipient's URI. 609 6.3. MSRP reports and responses 611 This section discusses the common procedures for regular and private 612 messages with respect to MSRP reports and responses. Any particular 613 procedure affecting only regular messages or only private messages is 614 discussed in the previous Section 6.1 or Section 6.2, respectively. 616 MSRP switches MUST follow the success report and failure report 617 handling described in section 7 of RFC 4975 [RFC4975], complemented 618 with the procedures described in this section. The MSRP switch MUST 619 act as am MSRP endpoint receiver of the request according to section 620 5.3 of RFC 4975 [RFC4975]. 622 If the MSRP switch receives an MSRP SEND request that does not 623 contain a Message/CPIM wrapper, the MSRP switch MUST reject the 624 request with a 415 response (specified in RFC 4975 [RFC4975]). 626 If the MSRP switch receives an MSRP SEND request where the URI 627 included in the From header field of the Message/CPIM wrapper is not 628 valid, (e.g, because it does not "belong" to the sender of the 629 message or is not a valid participant of the chat room), the MSRP 630 switch MUST reject the request with a 403 response. In non-error 631 cases, the MSRP switch MUST construct responses according to section 632 7.2 of RFC 4975 [RFC4975]. 634 On receiving a SEND request, the MSRP switch MAY use any report model 635 in the copies of the regular SEND request intended for the 636 recipients, but any received reports MUST NOT be forwarded to the 637 originator of the original SEND request. This could lead to having 638 the sender receiving multiple reports for a single MSRP request. 640 7. Nicknames 642 A common characteristic of existing chat room services is that 643 participants have the ability to present themselves with a nickname 644 to the rest of the participants of the conference. It is used for 645 easy reference of participants in the chat room, and can also provide 646 anonymous participants with a meaningful descriptive name. 648 A nickname is a useful construct in many use cases, of which MSRP 649 chat is but one example. It is associated with a URI of which the 650 participant is known to the focus. It is a user selectable 651 appearance of which the participant wants to be known to the other 652 participants. It is not a 'display-name', but it is used somewhat 653 like a display name. A main difference is that a nickname is unique 654 inside a chat room to allow an unambiguous reference to a participant 655 in the chat. Nicknames may be long lived, or may be temporary. 656 Users also need to reserve a nickname prior to its utilization. 658 This memo specifies the nickname as a string. The nickname string 659 MUST be unambiguous within the scope of the chat room (conference 660 instance). This scope is similar to having a nickname unique inside 661 a chat room from Extensible Messaging and Presence Protocol 662 [RFC3920]. The chat room may have policies associated with 663 nicknames. It may not accept nickname strings at all, or a it may 664 provide a wider unambiguous scope like a domain or server, similar to 665 Internet Relay Chat (IRC) [RFC2810]. 667 7.1. Using Nicknames within a Conference 669 This memo provides a mechanism to reserve a nickname for a 670 participant for as long as the participant is logged into the chat 671 room. The mechanism is based on a NICKNAME MSRP method (see below) 672 and a new "Use-Nickname" header. Note that other mechanisms may 673 exist (for example, a web page reservation system), although they are 674 outside the scope of this document. 676 A conference participant who has established an MSRP session with the 677 MSRP switch, where the MSRP switch has indicated the support and 678 availability of nicknames with the 'nicknames' token in the 679 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP 680 switch. The NICKNAME request MUST include a new Use-Nickname header 681 that contains the nickname string that the participant wants to 682 reserve. MSRP NICKNAME requests MUST NOT include Success-Report or 683 Failure-Report header fields. 685 The MSRP switch that receives a NICKNAME request containing a 686 nickname in the Use-Nickname header field SHOULD first verify whether 687 the policy of the chat room allows the nickname functionality. If 688 not allowed, the MSRP switch must reject the request with a 501 689 response, as per RFC 4975 [RFC4975]. 691 If the policy of the chat room allows the usage of nicknames, the 692 MSRP switch SHOULD validate that the SIP AOR is entitled to reserve 693 the nickname. The participant's authenticated identity can be 694 derived after a successful HTTP Digest Authentication, included in a 695 trusted SIP P-Asserted-Identity header field, included in a valid SIP 696 Identity header field, or derived from any other present or future 697 SIP authentication mechanism. Once the MSRP switch has validated 698 that the participant is entitled to reserve the nickname, the MSRP 699 switch MUST answer the NICKNAME request with a 200 response as per 700 regular MSRP procedures. 702 The reservation of a nickname can fail, e.g. if the NICKNAME request 703 contains a malformed or non-existent Use-Nickname header field, or if 704 the same nickname has already been reserved by another participant in 705 the conference. The validation can also fail where the sender of the 706 message is not entitled to reserve the nickname. In any of these 707 cases the MSRP switch MUST answer the NICKNAME request with a 423 708 response. The semantics of the 423 response are: "Nickname usage 709 failed; the nickname is not allocated to this user". 711 As indicated earlier, this specification defines a new MSRP header 712 field: "Use-Nickname". The Use-Nickname header field carries a 713 nickname string, and SHOULD be included in the NICKNAME requests. 715 The syntax of the NICKNAME method and the "Use-Nickname" header field 716 is built upon the MSRP formal syntax [RFC4975] 718 ext-method =/ NICKNAMEm 719 NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps 720 ext-header =/ Use-Nickname 721 ; ext-header is specified in RFC 4975 722 Use-Nickname = "Use-Nickname" ":" nickname 723 nickname = quoted-string 725 7.2. Modifying a Nickname 727 Typically participants will reserve a nickname as soon as they join 728 the chat room. But it is also possible for participants to modify 729 their own nicknames and replace them it a new one at any time during 730 the duration of the MSRP session. Modification of the nickname is 731 not different from the initial reservation and usage of a nickname, 732 thus the NICKNAME method is used as described in Section 7.1. 734 If a NICKNAME request that attempts to modify the current nickname of 735 the user for some reason fails, the current nickname stays in effect. 737 A new nickname comes into effect and the old one is released only 738 after a NICKNAME request is accepted with a 200 response. 740 7.3. Removing a Nickname 742 If the participant no longer wants to be known by a nickname in the 743 conference, the participant can follow the method described in 744 Section 7.2. The nickname element of the Use-Nickname header MUST be 745 set to an empty quoted string. 747 7.4. Nicknames in the Conference Event Package 749 Typically the conference focus acts as a notifier of the SIP 750 conference event package [RFC4575]. The conference focus MAY notify 751 subscribers of the nickname reserved by a given participant. We 752 define an extension to the conference event package to include 753 nicknames. The extension adds a child element to the 754 element containing the nickname string. 756 The following element is to be added to the sequence of the USER-TYPE 757 in the XML schema in conference event package [RFC4575] 759 761 7.5. Nicknames not supported nor allowed 763 The participants of the conference are identified by the SIP, TEL and 764 IM URI's typically learned from the information received in 765 notifications of the conference event package [RFC4575]. If 766 nicknames are not supported nor allowed, the participant list of the 767 conference will be less presentable. 769 8. The SDP 'chatroom' attribute 771 There are a handful of use cases where a participant would like to 772 learn the chat room capabilities supported by the MSRP switch and the 773 chat room. For example, a participant would like to learn if the 774 MSRP switch supports private messaging, otherwise, the participant 775 may send what he believes is a private instant message addressed to a 776 participant, but since the MSRP switch does not support the functions 777 specified in this memo, the message gets eventually distributed to 778 all the participants of the chat room. 780 The reverse case also exists. A participant, say Alice, whose user 781 agent does not support the extensions defined by this document joins 782 the chat room. The MSRP switch learns that Alice application does 783 not support private messaging nor nicknames. If another participant, 784 say Bob, sends a private message to Alice, the MSRP switch does not 785 distribute it to Alice, because Alice is not able to differentiate it 786 from a regular message sent to the whole roster. Further more, if 787 Alice replied to this message, she would do it to the whole roster. 788 Because of this, the MSRP switch keeps also track of users who do not 789 support the extensions defined in this document. 791 In another scenario, the policy of a chat room may indicate that 792 certain functions are not allowed. For example, the policy may 793 indicate that nicknames or private messages are not allowed. 795 In order to provide the user with a good chat room experience, we 796 define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a 797 media-level attribute that MAY be included in conjunction with and 798 MSRP media stream (i.e., when an m= line in SDP indicates "TCP/MSRP" 799 or "TCP/TLS/MSRP"). The 'chatroom' attribute indicates the 800 intersection of support and chat room local policy allowance for a 801 number of functions specified in this document. Specifically, we 802 provide the means for indicating support to use nicknames and private 803 messaging. 805 The 'chatroom' SDP attribute has the following syntax: 807 chatroom = chatroom-label ":" chat-token *(SP chat-token) 808 chatroom-label = "chatroom" 809 chat-token = (nicknames-token | private-msg-token | token) 810 nicknames-token = "nicknames" 811 private-msg-token = "private-messages" 813 A conference focus that includes the 'nicknames' token in the session 814 description is signaling that the MSRP switch supports and the chat 815 room allows to use of the procedures specified in Section 7. A 816 conference focus that includes the 'private-messages' in the SDP 817 description is signaling that the MSRP switch supports and the chat 818 room allows to use of the procedures specified in Section 6.2. 820 Example of the 'chatroom' attribute for an MSRP media stream that 821 indicates the acceptance of nicknames and private messages: 823 a=chatroom:nickname private-messages 825 9. Examples 827 9.1. Joining a chat room 829 Figure 3 presents a flow diagram where Alice joins a chat room by 830 sending an INVITE request. This INVITE request contains a session 831 description that includes the chatroom extensions defined in this 832 document. 834 Alice Conference focus 835 | | 836 |F1: (SIP) INVITE | 837 |----------------------->| 838 |F2: (SIP) 200 OK | 839 |<-----------------------| 840 |F3: (SIP) ACK | 841 |----------------------->| 842 | | 844 Figure 3: Flow diagram of a user joining a chat room 846 F1: Alice constructs an SDP description that includes an MSRP media 847 stream. She also indicates her support for the chatroom extensions 848 defined in this document. She sends the INVITE request to the chat 849 room server. 851 INVITE sip:chatroom22@chat.example.com SIP/2.0 852 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 853 Max-Forwards: 70 854 From: Alice ;tag=9fxced76sl 855 To: Chatroom 22 856 Call-ID: 3848276298220188511@atlanta.example.com 857 CSeq: 1 INVITE 858 Contact: 859 Content-Type: application/sdp 860 Content-Length: [length] 862 v=0 863 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 864 s=- 865 c=IN IP4 atlanta.example.com 866 m=message 7654 TCP/MSRP * 867 a=accept-types:message/cpim text/plain text/html 868 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 869 a=chatroom:nickname private-messages 871 F2: The chat room server accepts the session establishment. It 872 includes the 'isfocus' and other relevant feature tags in the Contact 873 header field of the response. The chat room server also builds an 874 SDP answer that also that forces the reception of messages wrapped in 875 Message/CPIM envelopes. It also includes the the chatroom attribute 876 with the allowed extensions. 878 SIP/2.0 200 OK 879 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 880 ;received=192.0.2.101 881 From: Alice ;tag=9fxced76sl 882 To: Chatroom 22 ;tag=8321234356 883 Call-ID: 3848276298220188511@atlanta.example.com 884 CSeq: 1 INVITE 885 Contact: \ 886 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \ 887 ;automata;isfocus;message;event="conference" 888 Content-Type: application/sdp 889 Content-Length: [length] 891 v=0 892 o=chat 2890844527 2890844527 IN IP4 chat.example.com 893 s=- 894 c=IN IP4 chat.example.com 895 m=message 12763 TCP/MSRP * 896 a=accept-types:message/cpim 897 a=accept-wrapped-types:text/plain text/html * 898 a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 899 a=chatroom:nickname private-messages 901 F3: The session established is acknowledged (details not shown). 903 9.2. Setting up a nickname 905 Figure 4 shows an example of Alice setting up a nickname using the 906 conference as provider. Her first proposal is not accepted because 907 the proposed nickname is already in use. Her second proposal is 908 accepted. 910 Alice MSRP switch 911 | | 912 |F1: (MSRP) NICKNAME | 913 |----------------------->| 914 |F2: (MSRP) 423 | 915 |<-----------------------| 916 |F3: (MSRP) NICKNAME | 917 |----------------------->| 918 |F4: (MSRP) 200 | 919 |<-----------------------| 920 | | 922 Figure 4: Flow diagram of a user setting up her nickname 924 F1: Alice sends an MSRP NICKNAME request that contains her proposed 925 nicknames in the Set-Nickname header field. 927 MSRP d93kswow NICKNAME 928 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 929 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 930 Use-Nickname: "Alice the great" 931 -------d93kswow$ 933 F2: The MSRP switch analyzes the existing allocation of nicknames and 934 detects that the nickname "Alice the great" is already provided to 935 another participant by the conference. The MSRP switch answers with 936 a 423 response. 938 MSRP d93kswow 423 Nickname usage failed 939 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 940 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 941 -------d93kswow$ 943 F3: Alice receives the response. She proposes a new nickname in a 944 second NICKNAME request. 946 MSRP 09swk2d NICKNAME 947 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 948 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 949 Use-Nickname: "Alice in Wonderland" 950 -------09swk2d$ 952 F4: The MSRP switch accepts the nickname proposal and answers with a 953 200 response. 955 MSRP 09swk2d 200 OK 956 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 957 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 958 -------09swk2d$ 960 9.3. Sending a regular message to the chat room 962 Figure 5 depicts a flow diagram where Alice is sending a regular 963 message addressed to the chat room. The MSRP switch distributes the 964 message to the rest of the participants. 966 Alice MSRP switch Bob Charlie 967 | | | | 968 | F1: (MSRP) SEND | | | 969 |--------------------->| F3: (MSRP) SEND | | 970 | F2: (MSRP) 200 |----------------------->| | 971 |<---------------------| F4: (MSRP) SEND | | 972 | |------------------------------->| 973 | | F5: (MSRP) 200 OK | | 974 | |<-----------------------| | 975 | | F6: (MSRP) 200 OK | | 976 | |<------------------------------ | 977 | | | | 978 | | | | 980 Figure 5: Sending a regular message to the chat room 982 F1: Alice builds a text message and wraps it in a CPIM message. She 983 addresses the CPIM message to the chat room. She encloses the result 984 in an MSRP SEND request and sends it to the MSRP switch via the 985 existing TCP connection. 987 MSRP 3490visdm SEND 988 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 989 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 990 Message-ID: 99s9s2 991 Byte-Range: 1-*/* 992 Content-Type: message/cpim 994 To: 995 From: 996 DateTime: 2009-03-02T15:02:31-03:00 997 Content-Type: text/plain 999 Hello guys, how are you today? 1000 -------3490visdm$ 1002 F2: The MSRP switch acknowledges the reception of the SEND request 1003 with a 200 (OK) response. 1005 MSRP 3490visdm 200 OK 1006 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1007 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1008 Message-ID: 99s9s2 1009 -------3490visdm$ 1011 F3: The MSRP switch creates a new MSRP SEND request that contains the 1012 received Message/CPIM body and sends it to Bob. 1014 MSRP 490ej23 SEND 1015 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1016 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1017 Message-ID: 304sse2 1018 Byte-Range: 1-*/* 1019 Content-Type: message/cpim 1021 To: 1022 From: 1023 DateTime: 2009-03-02T15:02:31-03:00 1024 Content-Type: text/plain 1026 Hello guys, how are you today? 1027 -------490ej23$ 1029 The rest of the message flows are analogous to the previous. They 1030 are not shown here. 1032 9.4. Sending a private message to a participant 1034 Figure 6 depicts a flow diagram where Alice is sending a private 1035 message addressed to Bob's SIP AOR. The MSRP switch distributes the 1036 message only to Bob. 1038 Alice MSRP switch Bob 1039 | | | 1040 | F1: (MSRP) SEND | | 1041 |--------------------->| F3: (MSRP) SEND | 1042 | F2: (MSRP) 200 |----------------------->| 1043 |<---------------------| | 1044 | | | 1045 | | | 1047 Figure 6: Sending a private message to Bob 1049 F1: Alice builds a text message and wraps it in a CPIM message. She 1050 addresses the CPIM message to the Bob's URI, which she learned from a 1051 notification in the conference event package. She encloses the 1052 result in an MSRP SEND request and sends it to the MSRP switch via 1053 the existing TCP connection. 1055 MSRP 6959ssdf SEND 1056 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1057 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1058 Message-ID: okj3kw 1059 Byte-Range: 1-*/* 1060 Content-Type: message/cpim 1062 To: 1063 From: 1064 DateTime: 2009-03-02T15:02:31-03:00 1065 Content-Type: text/plain 1067 Hello Bob. 1068 -------6959ssdf$ 1070 F2: The MSRP switch acknowledges the reception of the SEND request 1071 with a 200 (OK) response. 1073 MSRP 6959ssdfm 200 OK 1074 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1075 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1076 Message-ID: okj3kw 1077 -------6959ssdfm$ 1079 F3: The MSRP switch creates a new MSRP SEND request that contains the 1080 received Message/CPIM body and sends it only to Bob. Bob can 1081 distinguish the sender in the From header of the CPIM message. He 1082 also identifies this as a private message due to the To CPIM header. 1084 MSRP 9v9s2 SEND 1085 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1086 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1087 Message-ID: d9fghe982 1088 Byte-Range: 1-*/* 1089 Content-Type: message/cpim 1091 To: 1092 From: 1093 DateTime: 2009-03-02T15:02:31-03:00 1094 Content-Type: text/plain 1096 Hello Bob. 1097 -------9v9s2$ 1099 9.5. Chuncked private message 1101 The MSRP message below depicts an example of the private message in 1102 Section 9.4 split in two chuncks. The MSRP switch must wait for the 1103 complete set of CPIM headers before distributing the messages. 1105 MSRP 7443ruls SEND 1106 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1107 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1108 Message-ID: aft4to 1109 Byte-Range: 1-*/174 1110 Content-Type: message/cpim 1112 To: 1113 From: 1114 -------7443ruls$ 1116 MSRP 7443ruls SEND 1117 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1118 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1119 Message-ID: aft4to 1120 Byte-Range: 68-174/174 1121 Content-Type: message/cpim 1123 DateTime: 2009-03-02T15:02:31-03:00 1124 Content-Type: text/plain 1126 Hello Bob 1127 -------7443ruls$ 1129 9.6. Nickname in a conference information document 1131 Figure 7 depicts two user elements in a conference information 1132 document both having the nickname element with a nickname string. 1134 1135 1139 1142 1143 MSRP nickname example 1144 1145 1148 1149 2 1150 1151 1154 1155 1156 Dopey Donkey 1157 1158 1161 1162 Depressed Donkey 1163 1164 1165 1167 Figure 7: Nickname in a conference information document 1169 10. IANA Considerations 1171 10.1. New MSRP Method 1173 This specification defines a new MSRP method to be added to the 1174 Methods sub-registry of the Message Session Relay Protocol (MSRP) 1175 Parameters registry: 1177 NICKNAME 1179 See section Section 7 for details. 1181 10.2. New MSRP Header 1183 This specification defines a new MSRP header to be added to the 1184 Header Field sub-registry of the Message Session Relay Protocol 1185 (MSRP) Parameters registry: 1187 Use-Nickname 1189 See Section 7 for details. 1191 10.3. New MSRP Status Codes 1193 This specification defines three new MSRP status codes to be added to 1194 the Status-Code sub-registry of the Message Session Relay Protocol 1195 (MSRP) parameters registry. 1197 The 404 status code indicates the failure to resolve the recipient 1198 URI in the To header field of the Message/CPIM wrapper in the SEND 1199 request, e.g, due to an unknown recipient. See Section 6.2 for 1200 details. 1202 The 423 response indicates a failure in allocated the requested 1203 NICKNAME. This can be caused by a malformed NICKNAME request (e.g., 1204 no Use-Nickname header field), an already allocated nickname, or a 1205 policy that prevents the sender to use nicknames. See Section 7 for 1206 details. 1208 The 428 status code indicates that the recipient of a SEND request 1209 does not support private messages. See section Section 6.2 for 1210 details. 1212 Table 1 summarizes the IANA registration data with respect to new 1213 MSRP status codes: 1215 +-------+---------------------------------------+-----------+ 1216 | Value | Description | Reference | 1217 +-------+---------------------------------------+-----------+ 1218 | 404 | Failure to resolve recipient's URI | RFC XXXX | 1219 | 423 | Unable to allocate requested nickname | RFC XXXX | 1220 | 428 | Private messages not supported | RFC XXXX | 1221 +-------+---------------------------------------+-----------+ 1223 Table 1: New status codes 1225 10.4. New SDP Attribute 1227 This specification defines a new media-level attribute in the Session 1228 Description Protocol (SDP) Parameters registry. The registration 1229 data is as follows: 1231 Contact: Miguel Garcia 1233 Phone: +34 91 339 1000 1235 Attribute name: chatroom 1237 Long-form attribute name: Chat Room 1239 Type of attribute: media level only 1241 This attribute is not subject to the charset attribute 1243 Description: This attribute identifiers support and local policy 1244 allowance for a number of chatroomt related functions 1246 Specification: RFC XXXX 1248 See section Section 8 for details. 1250 11. Security Considerations 1252 This document proposes extensions to the Message Session Relay 1253 Protocol [RFC4975]. Therefore, the security considerations of such 1254 document apply to this document as well. 1256 In general, messages sent to a multi-party session based messaging 1257 focus are not deem to expose any security threat. Nevertheless, if a 1258 participant wants to avoid eavesdropping from non authorized 1259 entities, it should send those messages a TLS [RFC5246] transport 1260 connection, as allowed by MSRP. 1262 Nicknames will be used to show the appearances of the participants of 1263 the conference. A successful take over of a nickname from a 1264 participant might lead to private messages to be sent to the wrong 1265 destination. The recipient's URI will be different from the URI 1266 associated to the original owner of the nickname, but the sender 1267 might not notice this. To avoid take overs the MSRP switch MUST make 1268 sure that a nickname is unique inside a chat room. Also the security 1269 consideration for any authenticated identity mechanisms used to 1270 validate the SIP AOR will apply to this document as well. If a 1271 nickname can be reserved if it previously has been used by another 1272 participant in the chat room, is up to the policy of the chat room. 1274 12. Contributors 1276 This work would have never been possible without the fruitful 1277 discussions in the SIMPLE WG mailing list, specially with Brian Rosen 1278 (Neustar) and Paul Kyzivat (Cisco), who provided extensive review and 1279 improvements throughout the document. 1281 13. Acknowledgments 1283 The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, 1284 Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrian 1285 Georgescu, and Nancy Greene for providing comments. 1287 14. References 1289 14.1. Normative References 1291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1292 Requirement Levels", BCP 14, RFC 2119, March 1997. 1294 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1295 A., Peterson, J., Sparks, R., Handley, M., and E. 1296 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1297 June 2002. 1299 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1300 "Indicating User Agent Capabilities in the Session 1301 Initiation Protocol (SIP)", RFC 3840, August 2004. 1303 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1304 (CPIM)", RFC 3860, August 2004. 1306 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1307 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1309 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1310 Description Protocol", RFC 4566, July 2006. 1312 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1313 Initiation Protocol (SIP) Event Package for Conference 1314 State", RFC 4575, August 2006. 1316 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1317 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1319 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1320 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1321 September 2007. 1323 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 1324 Centralized Conferencing", RFC 5239, June 2008. 1326 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1327 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1329 14.2. Informative References 1331 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1332 April 2000. 1334 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1335 with Session Description Protocol (SDP)", RFC 3264, 1336 June 2002. 1338 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1339 Protocol (XMPP): Core", RFC 3920, October 2004. 1341 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1342 RFC 3966, December 2004. 1344 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1345 Session Initiation Protocol (SIP)", RFC 4353, 1346 February 2006. 1348 Authors' Addresses 1350 Aki Niemi 1351 Nokia 1352 P.O. Box 407 1353 NOKIA GROUP, FIN 00045 1354 Finland 1356 Phone: +358 50 389 1644 1357 Email: aki.niemi@nokia.com 1358 Miguel A. Garcia-Martin 1359 Ericsson 1360 Calle Via de los Poblados 13 1361 Madrid, ES 28033 1362 Spain 1364 Email: miguel.a.garcia@ericsson.com 1366 Geir A. Sandbakken (editor) 1367 TANDBERG 1368 Philip Pedersens vei 20 1369 N-1366 Lysaker 1370 Norway 1372 Phone: +47 67 125 125 1373 Email: geir.sandbakken@tandberg.com 1374 URI: http://www.tandberg.com