idnits 2.17.1 draft-niemi-simple-chat-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1313. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2007) is 6265 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) == Missing Reference: 'Display-Name' is mentioned on line 485, but not defined ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-18 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) == Outdated reference: A later version (-11) exists of draft-ietf-xcon-framework-06 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft M. Garcia-Martin 4 Intended status: Standards Track Nokia 5 Expires: September 3, 2007 March 2, 2007 7 Multi-party Instant Message (IM) Sessions Using the Message Session 8 Relay Protocol (MSRP) 9 draft-niemi-simple-chat-06 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 3, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The Message Session Relay Protocol (MSRP) defines a mechanism for 43 sending instant messages within a peer-to-peer session, negotiated 44 using the Session Initiation Protocol (SIP) and the Session 45 Description Protocol (SDP). This document defines the necessary 46 tools for establishing multi-party instant messaging (IM) sessions, 47 or chat rooms, with MSRP. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Motivations and Requirements . . . . . . . . . . . . . . . . . 5 54 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 55 5. Creating, Joining, and Deleting a Chat Room . . . . . . . . . 8 56 5.1. Creating a Chat Room . . . . . . . . . . . . . . . . . . . 8 57 5.2. Joining a Chat Room . . . . . . . . . . . . . . . . . . . 8 58 5.3. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . 9 59 5.4. Deleting a Chat Room . . . . . . . . . . . . . . . . . . . 10 60 6. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 6.1. Provisioning Nicknames . . . . . . . . . . . . . . . . . . 12 62 6.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 14 63 6.3. Mapping Nicknames to Other Identities . . . . . . . . . . 14 64 7. Sending and Receiving Instant Messages . . . . . . . . . . . . 15 65 7.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 15 66 7.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 17 67 8. Sidebars . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 19 70 9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 21 71 9.3. Sending a regular message to the chat room . . . . . . . . 23 72 9.4. Sending a private message to a participant . . . . . . . . 25 73 9.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 27 74 9.6. Security Considerations . . . . . . . . . . . . . . . . . 27 75 9.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 27 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 80 Intellectual Property and Copyright Statements . . . . . . . . . . 30 82 1. Introduction 84 The Message Session Relay Protocol (MSRP) 85 [I-D.ietf-simple-message-sessions] defines a mechanism for sending a 86 series of instant messages within a session. The Session Initiation 87 Protocol (SIP) [RFC3261] in combination with the Session Description 88 Protocol (SDP) [RFC3264] allows for two peers to establish and manage 89 such sessions. 91 In another application of SIP, a user agent can join in a multi-party 92 session or conference that is hosted by a specialized user agent 93 called a conference focus [RFC4353]. Such a conference can naturally 94 involve an MSRP session as one of possibly many media components. It 95 is the responsibility of an entity handling the media to relay 96 instant messages received from one participant to the rest of the 97 participants in the conference. 99 Several such systems already exist in the Internet. Participants in 100 a chat room can be identified with a pseudonym or nickname, and 101 decide whether their real identity is disclosed to other 102 participants. Participants can also use a rich set of features, such 103 as the ability to send private instant messages to one or more 104 participants, and the ability to establish sub-conferences with one 105 or more of the participants within the existing conference. They 106 also allow combining instant messaging with other media components, 107 such as voice, video, whiteboarding, screen sharing, and file 108 transfer. 110 Such conferences are already available today with other technologies 111 different than MSRP. For example, Internet Relay Chat (IRC) 112 [RFC2810], Extensible Messaging and Presence Protocol [RFC3920] based 113 chat rooms, and many other proprietary systems provide this kind of 114 functionality. It makes sense to specify equivalent functionality 115 for MSRP-based systems to both provide competitive features as well 116 as enable interworking between the systems. 118 This document defines requirements, conventions, and extensions for 119 providing private messages and nickname management in centralized 120 conferences with MSRP. This document, however, does not specify 121 functionality that can be used in conference with media different 122 than MSRP. This memo uses the SIP Conferencing Framework [RFC4353] 123 as a design basis. It also aims to be compatible with the 124 Centralized Conferencing Framework [I-D.ietf-xcon-framework]. It is 125 expected that future mechanisms will be developed for providing 126 similar functionality in generic conferences, i.e., where the media 127 is not only restricted to MSRP. The mechanisms described in this 128 document provide a future compatible short-term solution for MSRP 129 centralized conferences. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119, BCP 14 136 [RFC2119], and indicate requirement levels for compliant 137 implementations. 139 This memo deals with a particular case of tightly coupled SIP 140 conferences where the media exchanged consist of session-based 141 instant messaging. Unless otherwise noted, we use the terminology 142 defined in the SIP Conferencing Framework [RFC4353] applied to the 143 scope of this document. In addition to that terminology, we 144 introduce some new terms: 146 Nickname: a descriptive name associated to a participant. 148 Nickname URI: A SIP URI that includes a nickname in the user part. 149 See more information in Section 6. 151 Session-based Instant Messaging Conference: an instance of a 152 tightly coupled conference, in which the media exchanged between 153 the participants consist of (among others) MSRP based instant 154 messages. Also known as a chat room. 156 Chat Room: a synonym for session-based instant messaging 157 conference. 159 Chat Room URI: a URI that identifies a particular chat room in a 160 conference server. Since a chat room is a specialized conference 161 of instant messages, in the context of this document, a chat room 162 URI is a synonym of a conference URI. 164 Conference Server: a (possibly decomposed) server that provides 165 multipart text conference services. It is also the combination of 166 a conference focus and an MSRP switch. 168 Sender: the conference participant that originally created an 169 instant message and sent it to the chat room for delivery. 171 Recipient: the destination conference participant(s). This 172 defaults to the full conference participant list, minus the IM 173 Sender. 175 MSRP switch: a media level entity that receives MSRP messages and 176 delivers them to the other conference participants. An MSRP 177 switch has a similar role to a conference mixer with the exception 178 that an MSRP switch does not actually "mix" together different 179 input media streams; it merely relays the messages between 180 participants. 182 Private Instant Message: an instant message sent in a chat room 183 whose intended recipient is something other than the default. The 184 recipient of a private IM can either be one specific conference 185 participant, or a subset of the full participant list. A private 186 IM is usually rendered distinctly from the rest of the IMs, as to 187 indicate that the message was a private communication. 189 3. Motivations and Requirements 191 Although conference frameworks describing many types of conferencing 192 applications already exist, such as the Framework and Data Model for 193 Centralized Conferencing [I-D.ietf-xcon-framework] and the SIP 194 Conferencing Framework [RFC4353], the exact details of session-based 195 instant messaging conferences are not well-defined at the moment. 197 To allow interoperable chat implementations, for both conference- 198 aware, and conference-unaware user agents, certain conventions for 199 MSRP conferences need to be defined. It also seems beneficial to 200 provide a set of features that enhance the baseline multiparty MSRP 201 in order to be able to create systems that have functionality on par 202 with existing chat systems, as well as enable building interworking 203 gateways to these existing chat systems. 205 We define the following requirements: 207 REQ-1: A basic requirement is the existence of a multiparty 208 conference, where participants can join and leave the 209 conference and get instant messages exchanged to the rest of 210 the participants. 212 REQ-2: The conference must have the ability to host other media in 213 addition to MSRP, as well as multiple streams of MSRP. 215 REQ-3: A conference participant must be able to determine the 216 identities of the sender and recipient of the received IMs. 218 REQ-4: A conference participant must be able to determine the 219 recipient of the received message. For instance, the 220 recipient of the message might be the entire conference, a 221 conference sidebar or a single participant of the conference 222 (i.e., a private message). 224 REQ-5: It must be possible to send a message to a single 225 participant, or a subset of the conference participants 226 (i.e., a private instant message). 228 REQ-6: It must be possible to set up a sidebar session with one or 229 more participants of the chat room. 231 REQ-7: A conference participant may have a nickname or pseudonym 232 associated with their real identity. 234 REQ-8: It must be possible for a participant to change their 235 nickname during the progress of the conference. 237 REQ-9: It must be possible that a participant is only known by 238 their nickname and not their real identity to the rest of 239 the conference. 241 REQ-10: It must be possible for the MSRP switch itself to send IMs 242 to the conference (e.g., message of the day, welcome 243 messages, server is shutting down, etc.) 245 REQ-11: It must be possible for participants to learn the 246 capabilities support of the features described in this 247 document (and perhaps others). 249 4. Overview of Operation 251 In order to set up a conference, one must first be created. Users 252 wishing to host a conference themselves can of course do just that; 253 their user agents simply morph from an ordinary user agent into a 254 special purpose one called a conference focus. Another, commonly 255 used setup is one where a dedicated node in the network functions as 256 a conference focus. 258 Each chat room has an identity of its own: a SIP URI that 259 participants use to join the conference, e.g., by sending an INVITE 260 request. The conference focus processes the invitations, and as 261 such, maintains SIP dialogs with each participant. In an instant 262 messaging conference, or chat room, MSRP is one of the established 263 media streams. Each conference participant establishes an MSRP 264 session with an MSRP switch, which is a special purpose MSRP 265 application. The MSRP switch is similar to a conference mixer in 266 that it handles media sessions with each of the participants and 267 bridges these streams together. However, unlike a conference mixer, 268 the MSRP switch merely relays messages between participants but 269 doesn't actually mix the streams in any way. The system is 270 illustrated in Figure 1. 272 +------+ 273 | MSRP | 274 |Client| 275 +------+ +--.---+ +------+ 276 | MSRP | | | MSRP | 277 |Client| | _|Client| 278 +------._ | ,' +------+ 279 `._ | ,' 280 `.. +----------+ ,' 281 `| |' 282 | MSRP | 283 | Switch | 284 ,| |_ 285 _,-'' +----------+ ``-._ 286 +------.-' | `--+------+ 287 | MSRP | | | MSRP | 288 |Client| | |Client| 289 +------+ | +------+ 290 +---'--+ 291 | MSRP | 292 |Client| 293 +------+ 295 Figure 1: Multiparty MSRP in a Centralized Conference 297 Typically conference participants also subscribe to the conference 298 event package [RFC4575] to gather information about the conference 299 roster in the form of conference state notifications. For example, 300 participants can learn about other participants' identities. 302 All messages in the chat room use the 'Message/CPIM' wrapper content 303 type [RFC3862], so that it is possible to distinguish between private 304 and regular messages. When a participant wants to send an instant 305 message to the conference, it constructs an MSRP SEND request and 306 submits it to the MSRP switch including a regular payload (e.g., a 307 Message/CPIM message that contains a text, html, an image, etc.). 308 The Message/CPIM To header is set to the chat room URI. The switch 309 then fans out the SEND request to all of the other participants using 310 their existing MSRP sessions. 312 A participant can also send a private instant message addressed to 313 one or more conference participants whose identities have been 314 learnt, e.g., via a notification from the conference event package 315 [RFC4575]. In this case the sender creates an MSRP SEND request with 316 a Message/CPIM body whose To or Cc headers contain not the chat room 317 URI but one or more nickname or participant URIs. The MSRP switch 318 then fans out the SEND request to each of the participants listed in 319 the To or Cc headers of the Message/CPIM body. 321 We extend the current MSRP negotiation that takes place in SDP 322 [RFC4566] to allow participants to learn whether the chat room 323 supports and is willing to accept (e.g., due to local policy 324 restrictions) certain MSRP functions defined in this memo, such as 325 nicknames or private messaging. 327 Naturally, when a participant wishes to leave a chat room, it sends a 328 SIP BYE request to the conference focus and disconnects. 330 5. Creating, Joining, and Deleting a Chat Room 332 5.1. Creating a Chat Room 334 Since we consider a chat room a particular type of conference where 335 one of the offered media happens to be MSRP, the methods defined by 336 the SIP Conference Framework [RFC4353] for creating conferences are 337 directly applicable to a chat room. 339 Once a chat room is created, it is identified by a SIP URI, like any 340 other conference. 342 5.2. Joining a Chat Room 344 Participants usually join the conference by sending an INVITE request 345 to the conference URI. As long as the conference policy allows, the 346 INVITE request is accepted by the focus and the user is brought into 347 the conference. Participants are aware that the peer is a focus due 348 to the presence of the "isfocus" feature tag [RFC3840] in the Contact 349 header field of the 200-class response to the INVITE request. 350 Participants are also aware that the mixer is an MSRP switch due to 351 the presence of an additional 'message' media type and either TCP/ 352 MSRP or TCP/TLS/MSRP as the protocol field in the SDP [RFC4566] 353 media-line. 355 The conference focus of a chat room MUST include support for a 356 Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by 357 setting the 'accept-types' MSRP media line attribute in the SDP offer 358 or answer to include 'Message/CPIM'. 360 Note that the 'Message/CPIM' wrapper is used to carry the sender 361 information that, otherwise, it will not be available to the 362 recipient. Additionally, 'Message/CPIM' wrapper carries the 363 recipient information (e.g., To and Cc: headers). 365 The conference focus of a chat room MUST learn the chatroom 366 capabilities of each participant that joins the chat room, and MUST 367 inform the MSRP mixer of such support. This is to prevent that the 368 MSRP mixer distributes private messages to participants who do not 369 support private messaging. 371 5.3. The SDP 'chatroom' attribute 373 There are a handful of use cases where a participant would like to 374 learn the chatroom capabilities supported by the MSRP switch and the 375 chat room. For example, a participant would like to learn if the 376 MSRP switch supports private messaging, otherwise, the participant 377 may send what he believes is a private instant message addressed to a 378 few participants, but since the MSRP switch does not support the 379 functions specified in this memo, the message gets eventually 380 distributed to all the participants of the chat room. 382 The reverse case also exists. A participant, say Alice, whose user 383 agent does not support the extensions defined by this document joins 384 the chat room. The MSRP switch learns that Alice application does 385 not support private messaging nor nicknames. If another participant, 386 say Bob, sends a private message to Alice, the MSRP switch does not 387 distribute it to Alice, because Alice is not able to differentiate it 388 from a regular message sent to the whole roaster. Further more, if 389 Alice replied to this message, she would do it to the whole roaster. 390 Because of this, the MSRP mixer keeps also track of users who do not 391 support the extensions defined in this document. 393 In another scenario, the policy of a chat room may indicate that 394 certain functions are not allowed. For example, the policy may 395 indicate that nicknames or private messages are not allowed. 397 In order to provide the user with a good chatroom experience, we 398 define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a 399 media-level attribute that MAY be included in conjunction with and 400 MSRP media stream (i.e., when an m= line in SDP indicates "TCP/MSRP" 401 or "TCP/TLS/MSRP"). The 'chatroom' attribute indicates the 402 intersection of support and chatroom local policy allowance for a 403 number of functions specified in this document. Specifically, we 404 provide the means for indicating support to use nicknames and private 405 messaging. 407 The 'chatroom' SDP attribute has the following syntax: 409 chatroom = chatroom-label ":" chat-token *(SP chat-token) 410 chatroom-label = "chatroom" 411 chat-token = (nicknames-token | private-msg-token | token) 412 nicknames-token = "nicknames" 413 private-msg-token = "private-messages" 415 A conference focus that includes the 'nicknames' token in the session 416 description is signalling that the MSRP switch supports and the 417 chatroom allows to use the procedures specified in Section 6. A 418 conference focus that includes the 'private-messages' in the SDP 419 description is signalling that the MSRP switch supports and the 420 chatroom allows to use the procedures specified in Section 7.2. 422 Example of the 'chatroom' attribute for an MSRP media stream that 423 indicates the acceptance of nicknames and private messages: 425 a=chatroom:nickname private-messages 427 5.4. Deleting a Chat Room 429 As with creating a conference, the methods defined by the SIP 430 Conference Framework [RFC4353] for deleting a conference are directly 431 applicable to a chat room. 433 Deleting a chat room is an action that heavily depends on the policy 434 of the chat room. The policy can determine that the chat room is 435 deleted when the creator leaves the conference, or with any out of 436 band mechanism. 438 6. Nicknames 440 A common characteristic of existing chat room services is that 441 participants have the ability to identify themselves with a nickname 442 to the rest of the participants of the conference. This provides a 443 layer of anonymity, whereby the conference server authenticates the 444 participant, but still allows the participant to keep anonymity of 445 his SIP URI towards the rest of the participants without downgrading 446 his services. Specifically, anonymous participants are able to 447 receive private instant messages from other participants without 448 revealing their SIP URI. 450 One option to satisfy an aspect of nicknames consists of using the 451 display name with a real identity as the URI, for example, in CPIM 452 headers. A nickname in the display name offers a pseudonym that 453 anyone can map to a real identity, thus not satisfying the anonymity 454 requirements. 456 Another option consists of using a nicknaming service, that allows 457 allocating nickname URIs to users. Using such a URI in a conference 458 in effect anonymizes the user, but still allows the user to be 459 reached outside the chat room using the same identity. However, 460 defining such nicknaming service machinery is out of the scope of 461 this specification. 463 Instead, we take the approach of defining a nickname as the 464 combination of an optional quoted display name followed by a nickname 465 URI, and allowing the use of such nicknames in To and Cc headers in 466 CPIM. A nickname URI is a SIP URI formed from the chat room URI that 467 embeds a nickname identifier. A nickname URI does not resolve to the 468 user himself, but to the particular chat room where the user has 469 joined. 471 In other words, a nickname is simply a username that is scoped for a 472 particular chat room. Such nicknames are allocated on a first-come 473 first-served policy, meaning they can also be "stolen". It is out of 474 the scope of this specification to define nickname retention schemes, 475 or nickaming services as discussed above. 477 Note that for some hosted chat rooms, this feature of nicknames 478 may be too much to tolerate. For such chat rooms, it may be more 479 desirable to disallow nicknames altogether, and have chat room 480 participants be identified with their own full SIP URI instead (or 481 any other URI scheme they used to join the room). 483 Based on the above discussion, we define a nickname as follows: 485 Nickname = [Display-Name] (nickname-URI) 487 An example of a nickname is: 489 "Alice in wonderland" 491 The display name of a nickname is used only for displaying purposes. 492 The nickname URI is used for routing. In particular, the conference 493 server maintains a mapping table between nickname URIs, SIP URIs and 494 MSRP sessions pertaining to a participant. 496 Nickname URIs are scoped to a chatroom. Therefore, a nickname 497 identifier MUST be unique within a chatroom, and SHOULD be unique 498 within a conference server or administrative domain. This way, two 499 different users cannot have the same nickname in different rooms on 500 the same chat server, unless there are valid reasons for allowing 501 this. For example, some chat rooms might need to assign some well- 502 known nickname to a secretary, which of course might be a different 503 user in different rooms. 505 However, it is still possible that the same user is using different 506 nicknames in different chat rooms hosted by the same conference 507 server. 509 In order to maintain high compatibility with existing SIP User 510 Agents, we define a convention for creating a nickname URI. The 511 convention consist on prepending an escaped nickname identifier and a 512 possible escaped '@' sign to the existing username part of the chat 513 room URI. 515 Let us take a look at an example. Assume the chat room URI allocated 516 to a given chat room is 'sip:room34@example.com'. A user whose 517 nickname identifier is set to 'nordicguy' is represented with the 518 nickname URI: 'sip:nordicguy%40room34@example.com'. 520 In another example the chat room URI does not include a username 521 part. For example, the chat room URI is 'sip:chat34.example.com'. 522 In this context a user whose nickname is 'nordicguy' gets represented 523 with a nickname URI of 'sip:nordicguy@chat34.example.com'. 525 An interesting property of this approach is that nickname URIs do not 526 really resolve to the SIP UA or real identity of the user. Instead, 527 they resolve to the conference server. Only the conference server 528 and the owner of the nickname are able to map a nickname URI to the 529 SIP URI of the user. Other participants can use the conference 530 server as an intermediary for delivery of private messages addressed 531 to any of the nickname URIs of the chat room. 533 As a consequence of the structure of the nickname URI, if a user has 534 the same nickname identifier in two different chat rooms, the 535 nickname URI will be different (because the chat room URIs are 536 different). For example, the nickname URIs of 'nordicguy' in two 537 different chat rooms would be 'sip:nordicguy%40conf12@example.com' 538 and 'sip:nordicguy%40conf34@example.com'. Each one is used within 539 its own chat room. 541 6.1. Provisioning Nicknames 543 Since nicknames are scoped within a chat room (and usually also 544 within a chat server or administrative domain), we provide a 545 mechanism for requesting and reserving a nickname for the user's 546 disposal for the duration the user is logged into the chat room. The 547 mechanism is based on the definition of the NICKNAME MSRP method (see 548 below). Note that other mechanisms may exists (for example, a web 549 page reservation system), although they are outside the scope of this 550 document. Further more, the mechanism that we specify in this memo 551 is able to reserve a nickname for the user's disposal for the time 552 the user is logged into the chat room. Other mechanisms that provide 553 persistent nicknames or nickname reservation across multiple chat 554 rooms or conference servers are outside the scope of this memo. 556 A participant in a chat room MAY send a NICKNAME method to the MSRP 557 switch to request the reservation of a nickname for the user's 558 disposal for the duration of the session (i.e., while the participant 559 is joined to the chat room) at any time once the MSRP session has 560 been established and authenticated. Typically users will reserve a 561 nickname as soon as the join the chat room, prior to sending any 562 messages. 564 We additionally define two new MSRP header fields "Set-Nickname" and 565 "Proposed-Nickname". The "Set-Nickname" header field carries a 566 nickname, while the "Proposed-Nickname" header field can carry one or 567 more nicknames. Set-Nickname header field MUST only be included in a 568 NICKNAME request. The Proposed-Nickname header fields MUST only be 569 included a 423 responses to NICKNAME requests. URIs included in the 570 Set-Nickname and Proposed-Nickname header fields MUST be formatted 571 according to the conventions for nickname URIs. 573 The syntax of the NICKNAME method and the "Proposed-Nickname" header 574 field is built upon the MSRP formal syntax 575 [I-D.ietf-simple-message-sessions] and the SIP formal syntax 576 [RFC3261]: 578 ext-method =/ NICKNAMEm 579 NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps 580 ext-header =/ Set-Nickname 581 ; ext-header is specified in RFC XXXX 582 ; name-addr is specified in RFC 3261 583 Set-Nickname = "Set-Nickname" ":" name-addr 584 ext-header =/ Proposed-Nickname 585 Proposed-Nickname = "Proposed-Nickname" ":" name-addr 586 *(COMMA name-addr) 588 A conference participant who has established an MSRP session with an 589 MSRP switch, where the MSRP switch has indicated the support and 590 availability of nicknames with the 'nicknames' token in the 591 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP 592 switch. The MSRP NICKNAME request MUST contain a Set-Nickname header 593 field that includes one nickname URI that the user would like to be 594 known as. URIs included in the Set-Nickname header field MUST be 595 formatted as nickname URIs. 597 An MSRP switch that receives a NICKNAME request containing a proposed 598 nickname in the Set-Nickname header field SHOULD verify first whether 599 the policy of the chat room allows the nickname functionality. If is 600 not allowed, the MSRP switch MUST answer with a 501 response. 602 If the policy of the chat room allows conference participants to 603 negotiate and use their nicknames, the MSRP switch then examines 604 nickname contained in the Set-Nickname header field. If the URI 605 included in the Set-Nickname header field is not formatted as a 606 nickname URI (e.g., the chat room URI is not used), then the MSRP 607 switch discards that proposal and moves to the next one. For every 608 valid nickname URI the MSRP switch finds if the proposed nickname URI 609 is already in use or matches the local policy otherwise. If the 610 proposal is not acceptable for any reason, the MSRP switch discards 611 the proposal and moves to the next one. Note that the MSRP switch 612 bases its decision on the nickname URI only, and it does not use the 613 display name for this validation. If a proposed nickname URI is 614 valid and not already used, the MSRP switch inserts the entry into 615 its mapping table, associated to the user's SIP URI and MSRP session, 616 and generates a 200 response to the NICKNAME request. The 200 617 response MUST include a Proposed-Nickname header field that contains 618 the selected nickname. 620 If the MSRP NICKNAME request does not contain a Proposed-Nickname 621 header field, or if it contains such header, but all the proposed 622 nicknames are not acceptable (e.g., because they are already taken), 623 the MSRP switch generates a 423 response. The 423 response SHOULD 624 contain a Proposed-Nickname header field that contains one or more 625 nickname URIs proposed by the MSRP switch. 627 The sender of an MSRP NICKNAME request can receive a 200 response 628 that contains a Proposed-Nickname header field containing the 629 nickname URI that the user has been granted for the duration of the 630 session. If the response is a 423, then none of the proposals of the 631 NICKNAME request were accepted. The 423 response includes a 632 Proposed-Nickname header field that contains the MSRP switch 633 proposals. The MSRP endpoint MAY send a new NICKNAME request that 634 includes a new nickname proposal. 636 6.2. Modifying a Nickname 638 At any time during the session the MSRP endpoint may want to modify 639 his nickname. Modification of the nickname is not different from the 640 initial provision of a nickname, thus the NICKNAME method is used as 641 described in Section 6.1. 643 If a NICKNAME method that attempts to modify the current nickname of 644 the user for some reason fails, the current nickname stays in effect. 645 The new nickname comes into effect and the old one is released only 646 after a NICKNAME method is accepted and receives a 200-class 647 repsonse. 649 6.3. Mapping Nicknames to Other Identities 651 The MSRP switch maintains a mapping table that correlates, for a 652 given user, his nickname, SIP URI, and MSRP session ID. This 653 correlation is valid for the duration of the session (unless 654 mechanisms specified elsewhere exists to provide long-lasting 655 nicknames). Thus, at the dismissal of the session the MSRP switch 656 should dispose the nickname and make it available to other 657 participants. 659 Typically the conference focus acts as a notifier of the SIP 660 conference event package [RFC4575]. The conference focus MAY notify 661 subscribers of the nickname allocated to a given participant. We 662 define an extension to the conference event package to include 663 nicknames. The extension defines a new element as a child 664 element of the existing element. The element 665 includes an 'entity' attribute that contains the nickname URI. A 666 child element contains the display name of the 667 nickname. 669 TO BE DONE: include a formal definition of the 670 extension to the conference event package. 672 7. Sending and Receiving Instant Messages 674 7.1. Regular Messages 676 This section describes the conventions used to send and receive 677 instant messages that are addressed to all the participants in the 678 chat room. These are sent over a regular MSRP SEND request that 679 contains a Message/CPIM wrapper [RFC3862] that in turn contains the 680 desired payload (e.g., text, image, video-clip, etc.). 682 When a chat room participant wishes to send an instant message to all 683 the other participants in the chat room, he constructs an MSRP SEND 684 request that MUST contain a top-level wrapper of type 'Message/CPIM' 685 [RFC3862]. The actual instant message payload inside 'Message/CPIM' 686 MAY be of any type negotiated in the SDP 'accepted-types' attribute 687 according to the MSRP rules. 689 The sender SHOULD populate the From header of the Message/CPIM 690 wrapper with a proper identity by which the user is recognized in the 691 conference. Identities that can be used (among others) are: 693 o A SIP URI [RFC3261] representing the participant's address-of- 694 record 696 o A tel URI [RFC3966] representing the participant's telephone 697 number 699 o An IM URI [RFC3860] representing the participant's instant 700 messaging address 702 o A nickname URI formatted according to the rules indicated in 703 Section 6 and allocated for the user. 705 If the sender of the message wants to remain anonymous to the rest of 706 the participants, and providing that the policy of the conference 707 allows anonymous participation, the creator SHOULD populate the From 708 header of the Message/CPIM body with an anonymous identity, e.g., 709 using the "anonymous" SIP URI as described in RFC 3261 [RFC3261] 710 Section 8.1.1.3. or using a nickname URI (see Section 6) that has 711 been allocated to the user. 713 The sender MUST populate the To header field of the Message/CPIM body 714 with the chat room URI. 716 An MSRP switch that receives a SEND request from a participant SHOULD 717 first verify that the From header field of the Message/CPIM wrapper 718 is correctly populated with a valid URI as indicated earlier. If the 719 URI included in the From header field of the Message/CPIM wrapper is 720 not valid (e.g, because it does not "belong" to the user), then the 721 MSRP switch MUST generate a 403 response and MUST NOT forward the 722 SEND request to any of the participants. Otherwise, the MSRP switch 723 SHOULD generate a 200 response according to the MSRP rules for 724 response generation. 726 Then the MSRP switch should inspect the To header field of the 727 Message/CPIM wrapper. If the To header field of the Message/CPIM 728 wrapper contains the chat room URI, the MSRP switch can generate a 729 copy of the SEND request to each of the participants in the 730 conference except the sender. The MSRP switch MUST NOT modify any of 731 the bodies included in the received SEND request. Note that the MSRP 732 switch does not need to wait for the reception of the complete MSRP 733 chunk or MSRP message before it starts the distribution to the rest 734 of the participants. Instead, once the MSRP switch has received the 735 headers of the Message/CPIM body it SHOULD start the distribution 736 process. 738 An MSRP endpoint that receives a SEND request from an MSRP switch 739 containing a Message/CPIM wrapper SHOULD first inspect the To header 740 field of the Message/CPIM body. If the To header field is set to the 741 chat room URI, then it is a regular message that has been distributed 742 to all the participants in the conference. Then the MSRP endpoint 743 SHOULD inspect the From header field of the Message/CPIM body to 744 identify the sender. The From header field will include a URI that 745 identifies the sender. The endpoint might have also received further 746 identity information through a subscription to the SIP conference 747 event package [RFC4575]. 749 7.2. Private Messages 751 This section describes the conventions used to send and receive 752 private instant messages, i.e., instant messages that are addressed 753 to one or more selected participants of the chat room rather to all 754 of them. A private instant message is sent over a regular MSRP SEND 755 request that contains a Message/CPIM wrapper [RFC3862] which contains 756 the desired payload (e.g., text, image, video-clip, etc.), according 757 to the procedures of RFC 3862 [RFC3862]. 759 When a chat room participant wishes to send a private instant message 760 to one or more participants in the chat room, he constructs an MSRP 761 SEND request that MUST contain a top-level wrapper of type 'Message/ 762 CPIM' [RFC3862]. The actual instant message payload inside 'Message/ 763 CPIM' MAY be of any type negotiated in the SDP 'accepted-types' 764 attribute according to the MSRP rules. 766 The sender SHOULD populate the From header of the Message/CPIM 767 wrapper with a proper identity by which the user is recognized in the 768 conference as indicated for regular instant messages. Then the 769 sender MUST populate the To header field and MAY populate the Cc 770 header field of the Message/CPIM with the identity of intended 771 recipients. These identities include SIP, TEL, and IM URIs, and 772 nickname URIs (see Section 6) typically learnt from the information 773 received in notifications of the conference event package [RFC4575]. 775 As for regular messages, an MSRP switch that receives a SEND request 776 from a participant SHOULD first verify that the From header field of 777 the Message/CPIM wrapper is correctly populated with a valid URI as 778 indicated earlier. If the URI included in the From header field of 779 the Message/CPIM wrapper is not valid (e.g, because it does not 780 "belong" to the user), then the MSRP switch MUST generate a 403 781 response and MUST NOT forward the SEND request to any of the 782 participants. Otherwise, the MSRP switch SHOULD generate a 200 783 response according to the MSRP rules for response generation. 785 Then the MSRP switch MUST inspect the To header field of the Message/ 786 CPIM wrapper. If the To header field of the Message/CPIM wrapper 787 does not contain the chatroom URI the MSRP switch inspects the URIs 788 included in both the To and Cc headers. For each URI found there, 789 the MSRP switch first searches for support for private messages from 790 the intended recipient. If the recipient does not support private 791 messages, the MSRP switch does not forward the message to that 792 recipient. For each of the remaining intended recipients, the MSRP 793 switch searches in its mapping table to find the MSRP session 794 established towards the user's MSRP endpoint. Once a match is found 795 the MSRP switch MUST create a SEND request on that MSRP session and 796 MUST copy the contents (e.g., the whole Message/CPIM wrapper and its 797 bodies) to a SEND request and send it over that MSRP session. 799 There might be situations where one or more URIs included in the To 800 or Cc headers of the Message/CPIM wrapper cannot resolve to existing 801 MSRP sessions, e.g., due to a mistyped URI or because the recipient 802 has abandoned the chat room. In this case it might be benefitial for 803 the sender to become aware of which recipients the MSRP switch failed 804 to resolve. To support this case we define a new MSRP response code 805 427. This response code is not used in MSRP responses, but as part 806 of the REPORT status code. Note that the 427 status code in a REPORT 807 request merely indicates a failure in resolving a URI to an active 808 MSRP session, and it does not indicate whether the SEND request was 809 successfully received by any of the recipients (it might be still 810 possible that a URI resolves to an active MSRP session but the SEND 811 request cannot be delivered due to congestion, failure of the TCP 812 connection, or any failure at the recipient's MSRP endpoint). 814 If the MSRP switch cannot resolve any of the URIs included in the To 815 or Cc headers, and the Failure-Report header field of the SEND 816 request was either not present in the original request, or had a 817 value of "yes", the MSRP switch MUST generate a REPORT request to the 818 sender. The Status header field MUST be set to 427. The REPORT 819 request MUST include a Message/CPIM wrapper, with the original From 820 header field included in the SEND request, and the To and Cc header 821 fields containing the subset of failed-to-resolve URIs included in 822 the To and Cc header fields of original Message/CPIM wrapper, 823 respectively. 825 An MSRP endpoint that receives a SEND request from an MSRP switch 826 containing a Message/CPIM wrapper SHOULD first inspect the To header 827 field of the Message/CPIM body. If the To header field is not set to 828 the chat room URI, then it is a private message that has been 829 distributed to only selected participants in the conference 830 (addressed in the To and Cc headers of the Message/CPIM body). Then 831 the MSRP endpoint SHOULD inspect the From header field of the 832 Message/CPIM body to identify the sender. The From header field will 833 include a URI that identifies the sender. The endpoint might have 834 also received further identity information through a subscription to 835 the SIP conference event package [RFC4575]. 837 8. Sidebars 839 This document does not provide any protocol means to create, 840 manipulate, or send messages to sidebars. In many cases, a sidebar 841 is a logical subgroup of participants which exists only in each of 842 the recipients endpoints. Sending a message to the sidebar is 843 modelled as a private message addressed to each of the members of the 844 sidebar. As such, it is to possible to re-create the 'sidebar user 845 experience' totally in the endpoints by correlating collections of 846 private messages, thus, this document does not create any sidebar- 847 specific mechanism. 849 9. Examples 851 9.1. Joining a chat room 853 Figure 6 presents a flow diagram where Alice joins a chat room by 854 sending an INVITE request. This INVITE request contains a session 855 description that includes the chatroom extensions defined in this 856 document. 858 Alice Conference focus 859 | | 860 |(1) (SIP) INVITE | 861 |----------------------->| 862 |(2) (SIP) 200 OK | 863 |<-----------------------| 864 |(3) (SIP) ACK | 865 |----------------------->| 866 | | 868 Figure 6: Flow diagram of a user joining a chat room 870 F1: Alice constructs an SDP description that includes an MSRP media 871 stream. She also indicates her support for the chatroom extensions 872 defined in this document. She sends the INVITE request to the 873 chatroom server. 875 INVITE sip:chatroom22@chat.example.com SIP/2.0 876 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 877 Max-Forwards: 70 878 From: Alice ;tag=9fxced76sl 879 To: Chatroom 22 880 Call-ID: 3848276298220188511@atlanta.example.com 881 CSeq: 1 INVITE 882 Contact: 883 Content-Type: application/sdp 884 Content-Length: [length] 886 v=0 887 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 888 s=- 889 c=IN IP4 atlanta.example.com 890 m=message 7654 TCP/MSRP * 891 a=accept-types:message/cpim text/plain text/html 892 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 893 a=chatroom:nickname private-messages 895 Figure 7: INVITE request containing an SDP offer with chatroom 896 extensions 898 F2: The chatroom server accepts the session establishment. It 899 includes the 'isfocus' and other relevant feature tags in the Contact 900 header field of the response. The chatroom server also builds an SDP 901 answer that also that forces the reception of messages wrapped in 902 message/cpim envelops. It also includes the the chatroom attribute 903 with the allowed extensions. 905 SIP/2.0 200 OK 906 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 907 ;received=192.0.2.101 908 From: Alice ;tag=9fxced76sl 909 To: Chatroom 22 ;tag=8321234356 910 Call-ID: 3848276298220188511@atlanta.example.com 911 CSeq: 1 INVITE 912 Contact: \ 913 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \ 914 ;automata;isfocus;message;event="conference" 915 Content-Type: application/sdp 916 Content-Length: [length] 918 v=0 919 o=chat 2890844527 2890844527 IN IP4 chat.example.com 920 s=- 921 c=IN IP4 chat.example.com 922 m=message 12763 TCP/MSRP * 923 a=accept-types:message/cpim 924 a=accept-wrapped-types:text/plain text/html * 925 a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 926 a=chatroom:nickname private-messages 928 Figure 8: 200 (OK) response including chatroom extensions 930 F3: The session established is acknowledged (details not shown). 932 9.2. Setting up a nickname 934 Figure 9 shows an example of Alice setting up a nickname. Her first 935 proposal is not accepted because the proposed nickname is already in 936 use. Her second proposal is accepted. 938 Alice MSRP mixer 939 | | 940 |(1) (MSRP) NICKNAME | 941 |----------------------->| 942 |(2) (MSRP) 423 | 943 |<-----------------------| 944 |(3) (MSRP) NICKNAME | 945 |----------------------->| 946 |(4) (MSRP) 200 | 947 |<-----------------------| 948 | | 950 Figure 9: Flow diagram of a user setting up her nickname 952 F1: Alice sends an MSRP NICKNAME request that contains her proposed 953 nicknames in the Set-Nickname header field. 955 MSRP d93kswow NICKNAME 956 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 957 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 958 Set-Nickname: "Alice" 959 -------d93kswow$ 961 Figure 10: MSRP NICKNAME request with an initial nickname proposal 963 F2: The MSRP mixer analyzes the existing allocation of nicknames and 964 detects that the nickname identified by the URI 965 sip:alice%40chatroom22@chat.example.com is already in used by another 966 participant. The MSRP mixer answers with a 423 response that 967 includes a Proposed-Nickname header field with a proposal of 968 available nicknames. 970 MSRP d93kswow 423 Nickname already in use 971 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 972 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 973 Proposed-Nickname: "Alice 2" \ 974 975 -------d93kswow$ 977 Figure 11: MSRP 423 response 979 NOTE: MSRP does not permit line folding. A "\" in the examples 980 shows a line continuation due to limitations in line length of 981 this document. Neither the backslash, nor the extra CRLF are 982 included in the actual request or response. 984 F3: Alice receives the response, however, she does not like the 985 proposed nickname by the MSRP mixer. She proposes two new nicknames 986 in a new NICKNAME request. 988 MSRP 09swk2d NICKNAME 989 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 990 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 991 Set-Nickname: "Alice in Wonderland" \ 992 , \ 993 "Alice in Wonderland" \ 994 995 -------09swk2d$ 997 Figure 12: MSRP NICKNAME request with a second nickname proposal 999 F4: The MRSP mixer accepts the nickname proposal and answers with a 1000 200 response. The Set-Nickname header indicates the chosen nickname. 1002 MSRP 09swk2d 200 OK 1003 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1004 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1005 Set-Nickname: "Alice in Wonderland" \ 1006 1007 -------09swk2d$ 1009 Figure 13: MSRP NICKNAME request with an initial proposal 1011 9.3. Sending a regular message to the chat room 1013 Figure 14 depicts a flow diagram where Alice is sending a regular 1014 message addressed to the chat room. The MSRP mixer distributes the 1015 message to the rest of the participants. 1017 Alice MSRP mixer Bob Charlie 1018 | | | | 1019 | (1) (MSRP) SEND | | | 1020 |--------------------->| (3) (MSRP) SEND | | 1021 | (2) (MSRP) 200 |----------------------->| | 1022 |<---------------------| (4) (MSRP) SEND | | 1023 | |------------------------------->| 1024 | | (5) (MSRP) 200 OK | | 1025 | |<-----------------------| | 1026 | | (6) (MSRP) 200 OK | | 1027 | |<------------------------------ | 1028 | | | | 1029 | | | | 1031 Figure 14: Sending a regular message to the chat room 1033 F1: Alice builds a text message and wraps it in a CPIM message. She 1034 addresses the CPIM message to the chat room. She encloses the result 1035 in an MSRP SEND request and sends it to the MSRP mixer via the 1036 existing TCP connection. 1038 MSRP 3490visdm SEND 1039 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1040 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1041 Message-ID: 99s9s2 1042 Byte-Range: 1-*/* 1043 Content-Type: message/cpim 1045 To: 1046 From: "Alice in Wonderland" \ 1047 1048 DateTime: 2007-03-02T15:02:31-03:00 1049 Content-Type: text/plain 1051 Hello guys, how are you today? 1052 -------3490visdm$ 1054 Figure 15: Instant message addressed to all participants in the chat 1055 room 1057 F2: The MSRP mixer acknowledges the reception of the SEND request 1058 with a 200 (OK) response. 1060 MSRP 3490visdm 200 OK 1061 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1062 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1063 Message-ID: 99s9s2 1064 Byte-Range: 1-*/* 1065 -------3490visdm$ 1067 Figure 16: 200 (OK) response 1069 F3: The MSRP mixer creates a new MSRP SEND request that contains the 1070 received message/cpim body and sends it to Bob. 1072 MSRP 490ej23 SEND 1073 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1074 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1075 Message-ID: 304sse2 1076 Byte-Range: 1-*/* 1077 Content-Type: message/cpim 1079 To: 1080 From: "Alice in Wonderland" \ 1081 1082 DateTime: 2007-03-02T15:02:31-03:00 1083 Content-Type: text/plain 1085 Hello guys, how are you today? 1086 -------490ej23$ 1088 Figure 17: Instant message sent to all participants 1090 The rest of the message flows are analogous to the previous. They 1091 are not shown here. 1093 9.4. Sending a private message to a participant 1095 Figure 18 depicts a flow diagram where Alice is sending a private 1096 message addressed to Bob's nickname. The MSRP mixer distributes the 1097 message only to Bob. 1099 Alice MSRP mixer Bob Charlie 1100 | | | | 1101 | (1) (MSRP) SEND | | | 1102 |--------------------->| (3) (MSRP) SEND | | 1103 | (2) (MSRP) 200 |----------------------->| | 1104 |<---------------------| (4) (MSRP) SEND | | 1105 | |------------------------------->| 1106 | | | | 1107 | | | | 1109 Figure 18: Sending a private message to Bob 1111 F1: Alice builds a text message and wraps it in a CPIM message. She 1112 addresses the CPIM message to the Bob's nickname, which she learnt 1113 from a notification in the conference event package. She encloses 1114 the result in an MSRP SEND request and sends it to the MSRP mixer via 1115 the existing TCP connection. 1117 MSRP 6959ssdf SEND 1118 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1119 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1120 Message-ID: okj3kw 1121 Byte-Range: 1-*/* 1122 Content-Type: message/cpim 1124 To: "Bob the great" \ 1125 1126 From: "Alice in Wonderland" \ 1127 1128 DateTime: 2007-03-02T15:02:31-03:00 1129 Content-Type: text/plain 1131 Hello Bob. 1132 -------6959ssdf$ 1134 Figure 19: Private instant message addressed to one participant 1136 F2: The MSRP mixer acknowledges the reception of the SEND request 1137 with a 200 (OK) response. 1139 MSRP 6959ssdfm 200 OK 1140 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1141 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1142 Message-ID: okj3kw 1143 Byte-Range: 1-*/* 1144 -------6959ssdfm$ 1146 Figure 20: 200 (OK) response 1148 F3: The MSRP mixer creates a new MSRP SEND request that contains the 1149 received message/cpim body and sends it only to Bob. Bob can 1150 distinguish the sender in the From header of the CPIM message. He 1151 also identifies this as a private message due to the To CPIM header. 1153 MSRP 9v9s2 SEND 1154 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1155 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1156 Message-ID: d9fghe982 1157 Byte-Range: 1-*/* 1158 Content-Type: message/cpim 1160 To: "Bob the great" \ 1161 1162 From: "Alice in Wonderland" \ 1163 1164 DateTime: 2007-03-02T15:02:31-03:00 1165 Content-Type: text/plain 1167 Hello Bob. 1168 -------9v9s2$ 1170 Figure 21: Private instant message sent to Bob 1172 Flow F4 is not shown. 1174 9.5. IANA Considerations 1176 TBD. 1178 9.6. Security Considerations 1180 This document proposes extensions to the Message Session Relay 1181 Protocol [I-D.ietf-simple-message-sessions]. Therefore, the security 1182 considerations of such document apply to this document as well. 1184 In general, messages sent to a multi-party session based messaging 1185 focus are not deem to expose any security threat. Nevertheless, if a 1186 participant wants to avoid eavesdropping from non authorized 1187 entities, it should send those messages a TLS [RFC4346] transport 1188 connection, as allowed by MSRP. 1190 9.7. Acknowledgements 1192 The authors want to thank Eva Leppanen, Adamu Haruna, Paul Kyzivat, 1193 and Adam Roach for providing comments. 1195 10. References 1196 10.1. Normative References 1198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1199 Requirement Levels", BCP 14, RFC 2119, March 1997. 1201 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1202 A., Peterson, J., Sparks, R., Handley, M., and E. 1203 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1204 June 2002. 1206 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1207 "Indicating User Agent Capabilities in the Session 1208 Initiation Protocol (SIP)", RFC 3840, August 2004. 1210 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1211 (CPIM)", RFC 3860, August 2004. 1213 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1214 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1216 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1217 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1219 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1220 Description Protocol", RFC 4566, July 2006. 1222 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1223 Initiation Protocol (SIP) Event Package for Conference 1224 State", RFC 4575, August 2006. 1226 [I-D.ietf-simple-message-sessions] 1227 Campbell, B., "The Message Session Relay Protocol", 1228 draft-ietf-simple-message-sessions-18 (work in progress), 1229 December 2006. 1231 10.2. Informative References 1233 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1234 April 2000. 1236 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1237 with Session Description Protocol (SDP)", RFC 3264, 1238 June 2002. 1240 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1241 Protocol (XMPP): Core", RFC 3920, October 2004. 1243 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1244 RFC 3966, December 2004. 1246 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1247 Session Initiation Protocol (SIP)", RFC 4353, 1248 February 2006. 1250 [I-D.ietf-xcon-framework] 1251 Barnes, M., "A Framework and Data Model for Centralized 1252 Conferencing", draft-ietf-xcon-framework-06 (work in 1253 progress), December 2006. 1255 Authors' Addresses 1257 Aki Niemi 1258 Nokia 1259 P.O. Box 407 1260 NOKIA GROUP, FIN 00045 1261 Finland 1263 Phone: +358 50 389 1644 1264 Email: aki.niemi@nokia.com 1266 Miguel A. Garcia-Martin 1267 Nokia 1268 P.O. Box 407 1269 NOKIA GROUP, FIN 00045 1270 Finland 1272 Phone: +358 50 480 4586 1273 Email: miguel.an.garcia@nokia.com 1275 Full Copyright Statement 1277 Copyright (C) The IETF Trust (2007). 1279 This document is subject to the rights, licenses and restrictions 1280 contained in BCP 78, and except as set forth therein, the authors 1281 retain all their rights. 1283 This document and the information contained herein are provided on an 1284 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1285 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1286 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1287 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1288 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1289 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1291 Intellectual Property 1293 The IETF takes no position regarding the validity or scope of any 1294 Intellectual Property Rights or other rights that might be claimed to 1295 pertain to the implementation or use of the technology described in 1296 this document or the extent to which any license under such rights 1297 might or might not be available; nor does it represent that it has 1298 made any independent effort to identify any such rights. Information 1299 on the procedures with respect to rights in RFC documents can be 1300 found in BCP 78 and BCP 79. 1302 Copies of IPR disclosures made to the IETF Secretariat and any 1303 assurances of licenses to be made available, or the result of an 1304 attempt made to obtain a general license or permission for the use of 1305 such proprietary rights by implementers or users of this 1306 specification can be obtained from the IETF on-line IPR repository at 1307 http://www.ietf.org/ipr. 1309 The IETF invites any interested party to bring to its attention any 1310 copyrights, patents or patent applications, or other proprietary 1311 rights that may cover technology that may be required to implement 1312 this standard. Please address the information to the IETF at 1313 ietf-ipr@ietf.org. 1315 Acknowledgment 1317 Funding for the RFC Editor function is provided by the IETF 1318 Administrative Support Activity (IASA).