idnits 2.17.1 draft-ietf-simple-chat-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 602 has weird spacing: '...ssaging and P...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Then the MSRP switch MUST inspect the To header field of the Message/ CPIM wrapper. If the To header field of the Message/CPIM wrapper does not contain the chat room URI, it must check if it contains a participants URI associated with a participant. If the URI in the To header can not be resolved (e.g. cased by a mistyped URI or that the recipient has abandoned he chat room), and the Failure-Report header field of the SEND request was either not present in the original request, or had a value of "yes" or "partial", the MSRP switch MUST generate a REPORT request to the sender. The status header field MUST be set to 427. The new 427 status code indicates a failure to resolve the recipient URI in the To header field. If the recipient is valid, but the recipient does not support private messages, and the Failure-Report header field of the SEND request was either not present in the original request, or had a value of "yes" or "partial", the MSRP switch MUST send a REPORT request having the status code of 428. The new response 428 indicate that the recipient does not support private messages. In either case the REPORT request MUST include a Message/CPIM wrapper, with the original From header field included in the SEND request, and the To header field of the original message. The message MUST not be forwarded to the recipient if above conditions applies. The MSRP switch should search it's mapping table to find the MSRP session established towards the recipient. If a match is found the MSRP switch MUST create a SEND request and MUST copy the contents of the sender's message to it. -- 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 (March 9, 2009) is 5525 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 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft Nokia 4 Intended status: Standards Track M. Garcia-Martin 5 Expires: September 10, 2009 Ericsson 6 G. Sandbakken, Ed. 7 TANDBERG 8 March 9, 2009 10 Multi-party Chat Using the Message Session Relay Protocol (MSRP) 11 draft-ietf-simple-chat-04 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 10, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 The Message Session Relay Protocol (MSRP) defines a mechanism for 60 sending instant messages within a peer-to-peer session, negotiated 61 using the Session Initiation Protocol (SIP) and the Session 62 Description Protocol (SDP). This document defines the necessary 63 tools for establishing multi-party chat sessions, or chat rooms, 64 using MSRP. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Motivations and Requirements . . . . . . . . . . . . . . . . . 6 71 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 72 5. Creating, Joining, and Deleting a Chat Room . . . . . . . . . 9 73 5.1. Creating a Chat Room . . . . . . . . . . . . . . . . . . . 9 74 5.2. Joining a Chat Room . . . . . . . . . . . . . . . . . . . 9 75 5.3. Deleting a Chat Room . . . . . . . . . . . . . . . . . . . 10 76 6. Sending and Receiving Instant Messages . . . . . . . . . . . . 10 77 6.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 10 78 6.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 12 79 7. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 7.1. Using Nicknames within a Conference . . . . . . . . . . . 14 81 7.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 15 82 7.3. Removing a Nickname . . . . . . . . . . . . . . . . . . . 16 83 7.4. Nicknames in the Conference Event Package . . . . . . . . 16 84 7.5. Nicknames not supported nor allowed . . . . . . . . . . . 16 85 8. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . . . 16 86 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 18 88 9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 19 89 9.3. Sending a regular message to the chat room . . . . . . . . 21 90 9.4. Sending a private message to a participant . . . . . . . . 23 91 9.5. Obtaining an anonymous URI . . . . . . . . . . . . . . . . 24 92 9.6. Sending a private message using anonymous URI . . . . . . 25 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 94 10.1. New MSRP Method . . . . . . . . . . . . . . . . . . . . . 27 95 10.2. New MSRP Header . . . . . . . . . . . . . . . . . . . . . 27 96 10.3. New MSRP Status Codes . . . . . . . . . . . . . . . . . . 27 97 10.4. New SDP Attribute . . . . . . . . . . . . . . . . . . . . 27 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 99 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 14.1. Normative References . . . . . . . . . . . . . . . . . . . 28 103 14.2. Informative References . . . . . . . . . . . . . . . . . . 29 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 106 1. Introduction 108 The Message Session Relay Protocol (MSRP) [RFC4975] defines a 109 mechanism for sending a series of instant messages within a session. 110 The Session Initiation Protocol (SIP) [RFC3261] in combination with 111 the Session Description Protocol (SDP) [RFC3264] allows for two peers 112 to establish and manage such sessions. 114 In another application of SIP, a user agent can join in a multi-party 115 conversation called a conference that is hosted by a specialized user 116 agent called a focus [RFC4353]. Such a conference can naturally 117 involve an MSRP session as one of possibly many media components. It 118 is the responsibility of an entity handling the media to relay 119 instant messages received from one participant to the rest of the 120 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. They also allow combining instant messaging with other 128 media components, such as voice, video, white boarding, screen 129 sharing, and file transfer. 131 Similar conferences are already available today with other 132 technologies different than MSRP. For example, Internet Relay Chat 133 (IRC) [RFC2810], Extensible Messaging and Presence Protocol [RFC3920] 134 based chat rooms, and many other proprietary systems provide this 135 kind of functionality. It makes sense to specify equivalent 136 functionality for MSRP-based systems to both provide competitive 137 features as well as enable interworking between the systems. 139 This document defines requirements, conventions, and extensions for 140 providing private messages and nickname management in centralized 141 conferences with MSRP. This document, however, does not specify 142 functionality that can be used in conference with media different 143 than MSRP. This memo uses the SIP Conferencing Framework [RFC4353] 144 as a design basis. It also aims to be compatible with the 145 Centralized Conferencing Framework [I-D.ietf-xcon-framework]. It is 146 expected that future mechanisms will be developed for providing 147 similar functionality in generic conferences, i.e., where the media 148 is not only restricted to MSRP. The mechanisms described in this 149 document provide a future compatible short-term solution for MSRP 150 centralized conferences. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119, BCP 14 157 [RFC2119], and indicate requirement levels for compliant 158 implementations. 160 This memo deals with a particular case of tightly coupled SIP 161 conferences where the media exchanged consist of session-based 162 instant messaging. Unless otherwise noted, we use the terminology 163 defined in the SIP Conferencing Framework [RFC4353] applied to the 164 scope of this document. In addition to that terminology, we 165 introduce some new terms: 167 Nickname: a pseudonym or descriptive name associated to a 168 participant. See Section 7 for details 170 Multi-party chat: an instance of a tightly coupled conference, in 171 which the media exchanged between the participants consist of 172 (among others) MSRP based instant messages. Also known as a chat 173 room. 175 Chat Room: a synonym for a multi-party chat 177 Chat Room URI: a URI that identifies a particular chat room. Since 178 a chat room is a specialized conference of instant messages, in 179 the context of this document, a chat room URI is a synonym of a 180 conference URI. 182 Sender: the conference participant that originally created an 183 instant message and sent it to the chat room for delivery. 185 Recipient: the destination conference participant(s). This 186 defaults to the full conference participant list, minus the IM 187 Sender. 189 MSRP switch: a media level entity that receives MSRP messages and 190 delivers them to the other conference participants. An MSRP 191 switch has a similar role to a conference mixer with the exception 192 that an MSRP switch does not actually "mix" together different 193 input media streams; it merely relays the messages between 194 participants. 196 Private Instant Message: an instant message sent in a chat room 197 whose intended to a single participant. A private IM is usually 198 rendered distinctly from the rest of the IMs, as to indicate that 199 the message was a private communication. 201 Anonymous URI: a temporary GRUU that can be registered with the 202 conference focus to conceal a participant's SIP AOR from the other 203 participants in the a conference. 205 3. Motivations and Requirements 207 Although conference frameworks describing many types of conferencing 208 applications already exist, such as the Framework and Data Model for 209 Centralized Conferencing [I-D.ietf-xcon-framework] and the SIP 210 Conferencing Framework [RFC4353], the exact details of session-based 211 instant messaging conferences are not well-defined at the moment. 213 To allow interoperable chat implementations, for both conference- 214 aware, and conference-unaware user agents, certain conventions for 215 MSRP conferences need to be defined. It also seems beneficial to 216 provide a set of features that enhance the baseline multi-party MSRP 217 in order to be able to create systems that have functionality on par 218 with existing chat systems, as well as enable building interworking 219 gateways to these existing chat systems. 221 We define the following requirements: 223 REQ-1: A basic requirement is the existence of a multi-party 224 conference, where participants can join and leave the 225 conference and get instant messages exchanged to the rest of 226 the participants. 228 REQ-2: The conference must have the ability to host other media in 229 addition to MSRP, as well as multiple streams of MSRP. 231 REQ-3: A conference participant must be able to determine the 232 identities of the sender and recipient of the received IMs. 234 REQ-4: A conference participant must be able to determine the 235 recipient of the received message. For instance, the 236 recipient of the message might be the entire conference or a 237 single participant of the conference (i.e., a private 238 message). 240 REQ-5: It must be possible to send a message to a single 241 participant within the conference (i.e., a private instant 242 message). 244 REQ-6: A conference participant may have a nickname or pseudonym 245 associated with their real identity. 247 REQ-7: It must be possible for a participant to change their 248 nickname during the progress of the conference. 250 REQ-8: It must be possible that a participant is only known by 251 their nickname and not their real identity to the rest of 252 the conference. 254 REQ-9: It must be possible for the MSRP switch itself to send IMs 255 to the conference (e.g. message of the day, welcome 256 messages, server is shutting down, etc.) 258 REQ-10: It must be possible for participants to learn the 259 capabilities support of the features described in this 260 document (and perhaps others). 262 4. Overview of Operation 264 In order to set up a conference, one must first be created. Users 265 wishing to host a conference themselves can of course do just that; 266 their user agents simply morph from an ordinary user agent into a 267 special purpose one called a conference focus. Another, commonly 268 used setup is one where a dedicated node in the network functions as 269 a conference focus. 271 Each chat room has an identity of its own: a SIP URI that 272 participants use to join the conference, e.g. by sending an INVITE 273 request. The conference focus processes the invitations, and as 274 such, maintains SIP dialogs with each participant. In an multi-party 275 chat, or chat room, MSRP is one of the established media streams. 276 Each conference participant establishes an MSRP session with an MSRP 277 switch, which is a special purpose MSRP application. The MSRP switch 278 is similar to a conference mixer in that it handles media sessions 279 with each of the participants and bridges these streams together. 280 However, unlike a conference mixer, the MSRP switch merely relays 281 messages between participants but doesn't actually mix the streams in 282 any way. The system is illustrated in Figure 1. 284 +------+ 285 | MSRP | 286 |Client| 287 +------+ +--.---+ +------+ 288 | MSRP | | | MSRP | 289 |Client| | _|Client| 290 +------._ | ,' +------+ 291 `._ | ,' 292 `.. +----------+ ,' 293 `| |' 294 | MSRP | 295 | Switch | 296 ,| |_ 297 _,-'' +----------+ ``-._ 298 +------.-' | `--+------+ 299 | MSRP | | | MSRP | 300 |Client| | |Client| 301 +------+ | +------+ 302 +---'--+ 303 | MSRP | 304 |Client| 305 +------+ 307 Figure 1: Multi-party chat in a Centralized Conference 309 Typically conference participants also subscribe to the conference 310 event package [RFC4575] to gather information about the conference 311 roster in the form of conference state notifications. For example, 312 participants can learn about other participants' identities. 314 All messages in the chat room use the 'Message/CPIM' wrapper content 315 type [RFC3862], so that it is possible to distinguish between private 316 and regular messages. When a participant wants to send an instant 317 message to the conference, it constructs an MSRP SEND request and 318 submits it to the MSRP switch including a regular payload (e.g. a 319 Message/CPIM message that contains a text, html, an image, etc.). 320 The Message/CPIM To header is set to the chat room URI. The switch 321 then fans out the SEND request to all of the other participants using 322 their existing MSRP sessions. 324 A participant can also send a private instant message addressed to a 325 participants whose identity has been learned, e.g. via a notification 326 from the conference event package [RFC4575]. In this case the sender 327 creates an MSRP SEND request with a Message/CPIM body whose To header 328 contains not the chat room URI but the recipient's URI. The MSRP 329 switch then forwards the SEND request to the recipient. 331 We extend the current MSRP negotiation that takes place in SDP 333 [RFC4566] to allow participants to learn whether the chat room 334 supports and is willing to accept (e.g. due to local policy 335 restrictions) certain MSRP functions defined in this memo, such as 336 nicknames or private messaging. 338 Naturally, when a participant wishes to leave a chat room, it sends a 339 SIP BYE request to the conference focus and disconnects. 341 5. Creating, Joining, and Deleting a Chat Room 343 5.1. Creating a Chat Room 345 Since we consider a chat room a particular type of conference where 346 one of the offered media happens to be MSRP, the methods defined by 347 the SIP Conference Framework [RFC4353] for creating conferences are 348 directly applicable to a chat room. 350 Once a chat room is created, it is identified by a SIP URI, like any 351 other conference. 353 5.2. Joining a Chat Room 355 Participants usually join the conference by sending an INVITE request 356 to the conference URI. As long as the conference policy allows, the 357 INVITE request is accepted by the focus and the user is brought into 358 the conference. Participants are aware that the peer is a focus due 359 to the presence of the "isfocus" feature tag [RFC3840] in the Contact 360 header field of the 200-class response to the INVITE request. 361 Participants are also aware that the mixer is an MSRP switch due to 362 the presence of an additional 'message' media type and either TCP/ 363 MSRP or TCP/TLS/MSRP as the protocol field in the SDP [RFC4566] 364 media-line. 366 The conference focus of a chat room MUST include support for a 367 Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by 368 setting the 'accept-types' MSRP media line attribute in the SDP offer 369 or answer to include 'Message/CPIM'. 371 Note that the 'Message/CPIM' wrapper is used to carry the sender 372 information that, otherwise, it will not be available to the 373 recipient. Additionally, 'Message/CPIM' wrapper carries the 374 recipient information (e.g. To and Cc: headers). 376 If a participant wants to remain anonymous to the rest of the 377 participants in the conference, the participant's UA can register or 378 acquire by other means a temporary GRUU with the conference focus. 379 The procedure SHOULD follow the recommendation of draft-ietf-sip-gruu 381 [I-D.ietf-sip-gruu]. The temporary GRUU can be used in the From and 382 To header in the 'Message/CPIM' wrapper concealing the participant's 383 SIP AOR from the other participants in the conference. 385 The conference focus of a chat room MUST learn the chat room 386 capabilities of each participant that joins the chat room, and MUST 387 inform the MSRP switch of such support. This is to prevent that the 388 MSRP switch distributes private messages to participants who do not 389 support private messaging. 391 5.3. Deleting a Chat Room 393 As with creating a conference, the methods defined by the SIP 394 Conference Framework [RFC4353] for deleting a conference are directly 395 applicable to a chat room. 397 Deleting a chat room is an action that heavily depends on the policy 398 of the chat room. The policy can determine that the chat room is 399 deleted when the creator leaves the conference, or with any out of 400 band mechanism. 402 6. Sending and Receiving Instant Messages 404 6.1. Regular Messages 406 This section describes the conventions used to send and receive 407 instant messages that are addressed to all the participants in the 408 chat room. These are sent over a regular MSRP SEND request that 409 contains a Message/CPIM wrapper [RFC3862] that in turn contains the 410 desired payload (e.g. text, image, video-clip, etc.). 412 When a chat room participant wishes to send an instant message to all 413 the other participants in the chat room, he constructs an MSRP SEND 414 request that MUST contain a top-level wrapper of type 'Message/CPIM' 415 [RFC3862]. The actual instant message payload inside 'Message/CPIM' 416 MAY be of any type negotiated in the SDP 'accepted-types' attribute 417 according to the MSRP rules. 419 The sender SHOULD populate the From header of the Message/CPIM 420 wrapper with a proper identity by which the user is recognized in the 421 conference. Identities that can be used (among others) are: 423 o A SIP URI [RFC3261] representing the participant's address-of- 424 record 426 o A tel URI [RFC3966] representing the participant's telephone 427 number 429 o An IM URI [RFC3860] representing the participant's instant 430 messaging address 432 o An temporary GRUU [I-D.ietf-sip-gruu] representing the anonymous 433 URI associated with the sender. 435 An MSRP switch that receives a SEND request from a participant SHOULD 436 first verify that the From header field of the Message/CPIM wrapper 437 is correctly populated with a valid URI. The valid URI can be the 438 SIP AOR of the participant, or a temporary GRUU registered with the 439 focus associated with an anonymous participant. If the URI included 440 in the From header field of the Message/CPIM wrapper is not valid 441 (e.g, because it does not "belong" to the user), then the MSRP switch 442 MUST generate a 403 response and MUST NOT forward the SEND request to 443 any of the participants. Otherwise, the MSRP switch SHOULD generate 444 a 200 response according to the MSRP rules for response generation. 446 Then the MSRP switch should inspect the To header field of the 447 Message/CPIM wrapper. If the To header field of the Message/CPIM 448 wrapper contains the chat room URI, the MSRP switch can generate a 449 copy of the SEND request to each of the participants in the 450 conference except the sender. The MSRP switch MUST NOT modify any of 451 the bodies included in the received SEND request. Note that the MSRP 452 switch does not need to wait for the reception of the complete MSRP 453 chunk or MSRP message before it starts the distribution to the rest 454 of the participants. Instead, once the MSRP switch has received the 455 headers of the Message/CPIM body it SHOULD start the distribution 456 process. 458 The MSRP SHALL follow the success report and failure report handling 459 described in section 7 of [RFC4975] when it receives a SEND request 460 with a Message/CPIM wrapper having the To header field set to the 461 chat room URI. The MSRP switch MAY use any report model in the 462 copies of the SEND request intended for the recipients, but any 463 received reports MUST NOT be forwarded to the originator of the 464 original SEND request. The report model for handling private 465 messages is different from SEND requests to the chat room (see 466 Section 6.2 for details) 468 An MSRP endpoint that receives a SEND request from an MSRP switch 469 containing a Message/CPIM wrapper SHOULD first inspect the To header 470 field of the Message/CPIM body. If the To header field is set to the 471 chat room URI, then it is a regular message that has been distributed 472 to all the participants in the conference. Then the MSRP endpoint 473 SHOULD inspect the From header field of the Message/CPIM body to 474 identify the sender. The From header field will include a URI that 475 identifies the sender. The endpoint might have also received further 476 identity information through a subscription to the SIP conference 477 event package [RFC4575]. 479 6.2. Private Messages 481 This section describes the conventions used to send and receive 482 private instant messages, i.e., instant messages that are addressed 483 to one participant of the chat room rather to all of them. A chat 484 room can signal support for private messages using the chatroom- 485 attribute (see Section 8 for details). 487 When a chat room participant wishes to send a private instant message 488 to a participant the chat room, he constructs an MSRP SEND request 489 that MUST contain a top-level wrapper of type 'Message/CPIM' 490 [RFC3862]. The actual instant message payload inside 'Message/CPIM' 491 MAY be of any type negotiated in the SDP 'accepted-types' attribute 492 according to the MSRP rules (e.g. text, image, video-clip etc.) 494 The sender SHOULD populate the From header of the Message/CPIM 495 wrapper with a proper identity by which the user is recognized in the 496 conference as indicated for regular instant messages. Then the 497 sender MUST populate the To header field with the identity of 498 intended recipient. The identity can be SIP, TEL, and IM URIs 499 typically learned from the information received in notifications of 500 the conference event package [RFC4575]. 502 As for regular messages, an MSRP switch that receives a SEND request 503 from a participant SHOULD first verify that the From header field of 504 the Message/CPIM wrapper is correctly populated with a valid URI. If 505 the URI included in the From header field of the Message/CPIM wrapper 506 is not valid (e.g, because it does not "belong" to the user), then 507 the MSRP switch MUST generate a 403 response and MUST NOT forward the 508 SEND request to any of the participants. Otherwise, the MSRP switch 509 SHOULD generate a 200 response according to the MSRP rules for 510 response generation. 512 Then the MSRP switch MUST inspect the To header field of the Message/ 513 CPIM wrapper. If the To header field of the Message/CPIM wrapper 514 does not contain the chat room URI, it must check if it contains a 515 participants URI associated with a participant. If the URI in the To 516 header can not be resolved (e.g. cased by a mistyped URI or that the 517 recipient has abandoned he chat room), and the Failure-Report header 518 field of the SEND request was either not present in the original 519 request, or had a value of "yes" or "partial", the MSRP switch MUST 520 generate a REPORT request to the sender. The status header field 521 MUST be set to 427. The new 427 status code indicates a failure to 522 resolve the recipient URI in the To header field. If the recipient 523 is valid, but the recipient does not support private messages, and 524 the Failure-Report header field of the SEND request was either not 525 present in the original request, or had a value of "yes" or 526 "partial", the MSRP switch MUST send a REPORT request having the 527 status code of 428. The new response 428 indicate that the recipient 528 does not support private messages. In either case the REPORT request 529 MUST include a Message/CPIM wrapper, with the original From header 530 field included in the SEND request, and the To header field of the 531 original message. The message MUST not be forwarded to the recipient 532 if above conditions applies. The MSRP switch should search it's 533 mapping table to find the MSRP session established towards the 534 recipient. If a match is found the MSRP switch MUST create a SEND 535 request and MUST copy the contents of the sender's message to it. 537 If the original SEND request contained a Success-report header field 538 with the value of "yes" it MUST be added to the SEND request intended 539 for the recipient. If the MSRP switch receives an success report 540 from the recipient of the private message, and the original request 541 had the Success-report header field present with a value of "yes", 542 the MSRP switch MUST create a success REPORT and MUST copy the 543 contents of the recipient's report to it. The REPORT MUST be sent to 544 the originator of the original SEND request. If the original SEND 545 request contained the Success-report header field with the value of 546 "no", it may be added to the SEND request intended for the recipient; 547 but any received reports from the recipient MUST NOT be forwarded to 548 the originator of the original SEND request. 550 If the original SEND request contained a Failure-report header field 551 with the value of "yes" or "partial" it MUST be added to the SEND 552 request intended for the recipient. The MSRP switch MUST follow the 553 Failure-Report handling described in section 7.1.1 of [RFC4975] If 554 the MSRP switch receives a failure report from the recipient of the 555 private message, and the original SEND request had the Failure-report 556 header field present with the value of "yes" or "partial", the MSRP 557 switch MUST create a failure REPORT and MUST copy the contents of the 558 recipient's report to it. The REPORT MUST be sent to the originator 559 of the original SEND request. If the original SEND request contained 560 a Failure-report header field with the value of "no", it may be added 561 to the SEND request intended for the recipient; but any received 562 reports from the recipient MUST NOT be forwarded to the originator of 563 the original SEND request. 565 An MSRP endpoint that receives a SEND request from an MSRP switch 566 containing a Message/CPIM wrapper SHOULD first inspect the To header 567 field of the Message/CPIM body. If the To header field is not set to 568 the chat room URI, then it is a private message. Then the MSRP 569 endpoint SHOULD inspect the From header field of the Message/CPIM 570 body to identify the sender. The From header field will include a 571 URI that identifies the sender. The endpoint might have also 572 received further identity information through a subscription to the 573 SIP conference event package [RFC4575]. 575 It is possible that a participant, identified by a SIP Address of 576 Record, joins a conference of instant messages from two or more 577 different SIP UAs. It is RECOMMENDED that the an MSRP switch can map 578 a participant or anonymous URI for two or more MSRP sessions. If the 579 policy of the server allows for this, the MSRP switch MUST copy all 580 messages intended for the recipient through each MSRP session. 582 7. Nicknames 584 A common characteristic of existing chat room services is that 585 participants have the ability to identify themselves with a nickname 586 to the rest of the participants of the conference. It is used for 587 easy reference of participants in the chat room, and can also provide 588 anonymous participants with a meaningful descriptive name. 590 Nicknames are a useful construct in many use cases, of which MSRP 591 chat is but one example. Nicknames are an alternate form of 592 identity, associated with a URI of which the participant is known to 593 the focus. It is not a 'display-name', but it is used somewhat like 594 a display name. A main difference is that a nickname is unique 595 inside a chat room to allow an unambiguous reference to a participant 596 in the chat. Nicknames may be long lived, or may be temporary. 597 Users also need to reserve a nickname prior to its utilization. 599 This memo specifies the nickname as a string. The nickname string 600 MUST be unambiguous within the scope of the chat room (conference 601 instance). This scope is similar to having a nickname unique inside 602 a chat room from Extensible Messaging and Presence Protocol 603 [RFC3920]. The chat room may have policies associated with 604 nicknames. It may not accept nickname strings at all, or a it may 605 provide a wider unambiguous scope like a domain or server, similar to 606 Internet Relay Chat (IRC) [RFC2810]. 608 7.1. Using Nicknames within a Conference 610 This memo provides a mechanism to reserve a nickname for a 611 participant for as long as the participants is logged into the chat 612 room. The mechanism is based on a NICKNAME MSRP method (see below) 613 and a new "Use-Nickname" header. Note that other mechanisms may 614 exists (for example, a web page reservation system), although they 615 are outside the scope of this document. 617 A conference participant who has established an MSRP session with an 618 MSRP switch, where the MSRP switch has indicated the support and 619 availability of nicknames with the 'nicknames' token in the 620 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP 621 switch. The NICKNAME request MUST include a new Use-Nickname header 622 that contains the nickname string that the participant wants to 623 reserve. 625 An MSRP switch that receives a NICKNAME request containing a nickname 626 in the Use-Nickname header field SHOULD first verify whether the 627 policy of the chat room allows the nickname functionality. If is not 628 allowed, the MSRP switch MUST answer with a 501 response. 630 If the policy of the chat room allows the usage of nicknames, the 631 MSRP switch SHOULD validate that the SIP AOR is entitled to reserve 632 the nickname. The participant's authenticated identity can be 633 derived after a successful HTTP Digest Authentication, included in a 634 trusted SIP P-Asserted-Identity header field, included in a valid SIP 635 Identity header field, or derived from any other present or future 636 SIP authentication mechanism. Once the MSRP switch has validated 637 that the participant is entitled to reserve the nickname, the MSRP 638 switch answers to the MSRP NICKNAME request with a 200 response. 640 The reservation of a nickname can fail, e.g. if the NICKNAME request 641 contains a malformed or non-existent Use-Nickname header field, or if 642 the same nickname has already been reserved by another participant in 643 the conference. The validation can also fail where the SIP AOR is 644 not entitled to reserve the nickname. In any of these cases the MSRP 645 switch MUST answer with a newly defined 423 response. The semantics 646 of the 423 response are: "Nickname usage failed; the nickname is not 647 allocated to this user". 649 As indicated earlier, this specification defines a new MSRP header 650 field: "Use-Nickname". The Use-Nickname header field carries a 651 nickname string, and SHOULD be included in the NICKNAME requests. 653 The syntax of the NICKNAME method and the "Use-Nickname" header field 654 is built upon the MSRP formal syntax [RFC4975] 656 ext-method =/ NICKNAMEm 657 NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps 658 ext-header =/ Use-Nickname 659 ; ext-header is specified in RFC 4975 660 Use-Nickname = "Use-Nickname" ":" nickname 661 nickname = quoted-string 663 7.2. Modifying a Nickname 665 Typically participants will reserve a nickname as soon as they join 666 the chat room. But it is also possible for participants to modify 667 their own nicknames and replace them it a new one at any time during 668 the duration of the MSRP session. Modification of the nickname is 669 not different from the initial reservation and usage of a nickname, 670 thus the NICKNAME method is used as described in Section 7.1. 672 If a NICKNAME request that attempts to modify the current nickname of 673 the user for some reason fails, the current nickname stays in effect. 674 A new nickname comes into effect and the old one is released only 675 after a NICKNAME request is accepted with a 200 response. 677 7.3. Removing a Nickname 679 If the participant no longer wants to be known by a nickname in the 680 conference, the participant can follow the method described in 681 Section 7.2. The nickname element of the Use-Nickname header MUST be 682 set to an empty quoted string. 684 7.4. Nicknames in the Conference Event Package 686 Typically the conference focus acts as a notifier of the SIP 687 conference event package [RFC4575]. The conference focus MAY notify 688 subscribers of the nickname reserved by a given participant. We 689 define an extension to the conference event package to include 690 nicknames. The extension adds a attribute to the 691 containing the nickname string. 693 695 7.5. Nicknames not supported nor allowed 697 The participants SHOULD be notified of the URIs associated with the 698 other participants of the conference even if nicknames are provided. 699 The entity attribute in event notification framework being an SIP AOR 700 or anonymous URI. A client not supporting the extensions of this 701 memo will not render nicknames and can therefore can not be referred 702 to using nickname inside the chat room. The same would apply where a 703 chat room do not allow nicknames to be used. 705 8. The SDP 'chatroom' attribute 707 There are a handful of use cases where a participant would like to 708 learn the chat room capabilities supported by the MSRP switch and the 709 chat room. For example, a participant would like to learn if the 710 MSRP switch supports private messaging, otherwise, the participant 711 may send what he believes is a private instant message addressed to a 712 participant, but since the MSRP switch does not support the functions 713 specified in this memo, the message gets eventually distributed to 714 all the participants of the chat room. 716 The reverse case also exists. A participant, say Alice, whose user 717 agent does not support the extensions defined by this document joins 718 the chat room. The MSRP switch learns that Alice application does 719 not support private messaging nor nicknames. If another participant, 720 say Bob, sends a private message to Alice, the MSRP switch does not 721 distribute it to Alice, because Alice is not able to differentiate it 722 from a regular message sent to the whole roster. Further more, if 723 Alice replied to this message, she would do it to the whole roster. 724 Because of this, the MSRP switch keeps also track of users who do not 725 support the extensions defined in this document. 727 In another scenario, the policy of a chat room may indicate that 728 certain functions are not allowed. For example, the policy may 729 indicate that nicknames or private messages are not allowed. 731 In order to provide the user with a good chat room experience, we 732 define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a 733 media-level attribute that MAY be included in conjunction with and 734 MSRP media stream (i.e., when an m= line in SDP indicates "TCP/MSRP" 735 or "TCP/TLS/MSRP"). The 'chatroom' attribute indicates the 736 intersection of support and chat room local policy allowance for a 737 number of functions specified in this document. Specifically, we 738 provide the means for indicating support to use nicknames and private 739 messaging. 741 The 'chatroom' SDP attribute has the following syntax: 743 chatroom = chatroom-label ":" chat-token *(SP chat-token) 744 chatroom-label = "chatroom" 745 chat-token = (nicknames-token | private-msg-token | token) 746 nicknames-token = "nicknames" 747 private-msg-token = "private-messages" 749 A conference focus that includes the 'nicknames' token in the session 750 description is signaling that the MSRP switch supports and the chat 751 room allows to use the procedures specified in Section 7. A 752 conference focus that includes the 'private-messages' in the SDP 753 description is signaling that the MSRP switch supports and the chat 754 room allows to use the procedures specified in Section 6.2. 756 Example of the 'chatroom' attribute for an MSRP media stream that 757 indicates the acceptance of nicknames and private messages: 759 a=chatroom:nickname private-messages 761 9. Examples 763 9.1. Joining a chat room 765 Figure 2 presents a flow diagram where Alice joins a chat room by 766 sending an INVITE request. This INVITE request contains a session 767 description that includes the chatroom extensions defined in this 768 document. 770 Alice Conference focus 771 | | 772 |(1) (SIP) INVITE | 773 |----------------------->| 774 |(2) (SIP) 200 OK | 775 |<-----------------------| 776 |(3) (SIP) ACK | 777 |----------------------->| 778 | | 780 Figure 2: Flow diagram of a user joining a chat room 782 F1: Alice constructs an SDP description that includes an MSRP media 783 stream. She also indicates her support for the chatroom extensions 784 defined in this document. She sends the INVITE request to the chat 785 room server. 787 INVITE sip:chatroom22@chat.example.com SIP/2.0 788 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 789 Max-Forwards: 70 790 From: Alice ;tag=9fxced76sl 791 To: Chatroom 22 792 Call-ID: 3848276298220188511@atlanta.example.com 793 CSeq: 1 INVITE 794 Contact: 795 Content-Type: application/sdp 796 Content-Length: [length] 798 v=0 799 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 800 s=- 801 c=IN IP4 atlanta.example.com 802 m=message 7654 TCP/MSRP * 803 a=accept-types:message/cpim text/plain text/html 804 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 805 a=chatroom:nickname private-messages 807 Figure 3: INVITE request containing an SDP offer with chat room 808 extensions 810 F2: The chat room server accepts the session establishment. It 811 includes the 'isfocus' and other relevant feature tags in the Contact 812 header field of the response. The chat room server also builds an 813 SDP answer that also that forces the reception of messages wrapped in 814 message/cpim envelops. It also includes the the chatroom attribute 815 with the allowed extensions. 817 SIP/2.0 200 OK 818 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 819 ;received=192.0.2.101 820 From: Alice ;tag=9fxced76sl 821 To: Chatroom 22 ;tag=8321234356 822 Call-ID: 3848276298220188511@atlanta.example.com 823 CSeq: 1 INVITE 824 Contact: \ 825 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \ 826 ;automata;isfocus;message;event="conference" 827 Content-Type: application/sdp 828 Content-Length: [length] 830 v=0 831 o=chat 2890844527 2890844527 IN IP4 chat.example.com 832 s=- 833 c=IN IP4 chat.example.com 834 m=message 12763 TCP/MSRP * 835 a=accept-types:message/cpim 836 a=accept-wrapped-types:text/plain text/html * 837 a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 838 a=chatroom:nickname private-messages 840 Figure 4: 200 (OK) response including chat room extensions 842 F3: The session established is acknowledged (details not shown). 844 9.2. Setting up a nickname 846 Figure 5 shows an example of Alice setting up a nickname using the 847 conference as provider. Her first proposal is not accepted because 848 the proposed nickname is already in use. Her second proposal is 849 accepted. 851 Alice MSRP switch 852 | | 853 |(1) (MSRP) NICKNAME | 854 |----------------------->| 855 |(2) (MSRP) 423 | 856 |<-----------------------| 857 |(3) (MSRP) NICKNAME | 858 |----------------------->| 859 |(4) (MSRP) 200 | 860 |<-----------------------| 861 | | 863 Figure 5: Flow diagram of a user setting up her nickname 865 F1: Alice sends an MSRP NICKNAME request that contains her proposed 866 nicknames in the Set-Nickname header field. 868 MSRP d93kswow NICKNAME 869 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 870 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 871 Use-Nickname: "Alice the great" 872 -------d93kswow$ 874 Figure 6: MSRP NICKNAME request with an initial nickname proposal 876 F2: The MSRP switch analyzes the existing allocation of nicknames and 877 detects that the nickname "Alice is great" is already provided to 878 another participant by the conference. The MSRP switch answers with 879 a 423 response. 881 MSRP d93kswow 423 Nickname usage failed 882 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 883 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 884 -------d93kswow$ 886 Figure 7: MSRP 423 response 888 F3: Alice receives the response. She proposes a new nickname in a 889 second NICKNAME request. 891 MSRP 09swk2d NICKNAME 892 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 893 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 894 Use-Nickname: "Alice in wonderland" 895 -------09swk2d$ 897 Figure 8: MSRP NICKNAME request with a second nickname proposal 899 F4: The MSRP switch accepts the nickname proposal and answers with a 900 200 response. 902 MSRP 09swk2d 200 OK 903 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 904 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 905 -------09swk2d$ 907 Figure 9: MSRP NICKNAME request 909 9.3. Sending a regular message to the chat room 911 Figure 10 depicts a flow diagram where Alice is sending a regular 912 message addressed to the chat room. The MSRP switch distributes the 913 message to the rest of the participants. 915 Alice MSRP switch Bob Charlie 916 | | | | 917 | (1) (MSRP) SEND | | | 918 |--------------------->| (3) (MSRP) SEND | | 919 | (2) (MSRP) 200 |----------------------->| | 920 |<---------------------| (4) (MSRP) SEND | | 921 | |------------------------------->| 922 | | (5) (MSRP) 200 OK | | 923 | |<-----------------------| | 924 | | (6) (MSRP) 200 OK | | 925 | |<------------------------------ | 926 | | | | 927 | | | | 929 Figure 10: Sending a regular message to the chat room 931 F1: Alice builds a text message and wraps it in a CPIM message. She 932 addresses the CPIM message to the chat room. She encloses the result 933 in an MSRP SEND request and sends it to the MSRP switch via the 934 existing TCP connection. 936 MSRP 3490visdm SEND 937 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 938 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 939 Message-ID: 99s9s2 940 Byte-Range: 1-*/* 941 Content-Type: message/cpim 943 To: 944 From: 945 DateTime: 2009-03-02T15:02:31-03:00 946 Content-Type: text/plain 948 Hello guys, how are you today? 949 -------3490visdm$ 951 Figure 11: Instant message addressed to all participants in the chat 952 room 954 F2: The MSRP switch acknowledges the reception of the SEND request 955 with a 200 (OK) response. 957 MSRP 3490visdm 200 OK 958 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 959 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 960 Message-ID: 99s9s2 961 Byte-Range: 1-*/* 962 -------3490visdm$ 964 Figure 12: 200 (OK) response 966 F3: The MSRP switch creates a new MSRP SEND request that contains the 967 received message/cpim body and sends it to Bob. 969 MSRP 490ej23 SEND 970 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 971 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 972 Message-ID: 304sse2 973 Byte-Range: 1-*/* 974 Content-Type: message/cpim 976 To: 977 From: 978 DateTime: 2009-03-02T15:02:31-03:00 979 Content-Type: text/plain 981 Hello guys, how are you today? 982 -------490ej23$ 983 Figure 13: Instant message sent to all participants 985 The rest of the message flows are analogous to the previous. They 986 are not shown here. 988 9.4. Sending a private message to a participant 990 Figure 14 depicts a flow diagram where Alice is sending a private 991 message addressed to Bob's SIP AOR. The MSRP switch distributes the 992 message only to Bob. 994 Alice MSRP switch Bob 995 | | | 996 | (1) (MSRP) SEND | | 997 |--------------------->| (3) (MSRP) SEND | 998 | (2) (MSRP) 200 |----------------------->| 999 |<---------------------| | 1000 | | | 1001 | | | 1003 Figure 14: Sending a private message to Bob 1005 F1: Alice builds a text message and wraps it in a CPIM message. She 1006 addresses the CPIM message to the Bob's nickname, which she learned 1007 from a notification in the conference event package. She encloses 1008 the result in an MSRP SEND request and sends it to the MSRP switch 1009 via the existing TCP connection. 1011 MSRP 6959ssdf SEND 1012 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1013 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1014 Message-ID: okj3kw 1015 Byte-Range: 1-*/* 1016 Content-Type: message/cpim 1018 To: 1019 From: 1020 DateTime: 2009-03-02T15:02:31-03:00 1021 Content-Type: text/plain 1023 Hello Bob. 1024 -------6959ssdf$ 1026 Figure 15: Private instant message addressed to one participant 1028 F2: The MSRP switch acknowledges the reception of the SEND request 1029 with a 200 (OK) response. 1031 MSRP 6959ssdfm 200 OK 1032 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1033 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1034 Message-ID: okj3kw 1035 Byte-Range: 1-*/* 1036 -------6959ssdfm$ 1038 Figure 16: 200 (OK) response 1040 F3: The MSRP switch creates a new MSRP SEND request that contains the 1041 received message/cpim body and sends it only to Bob. Bob can 1042 distinguish the sender in the From header of the CPIM message. He 1043 also identifies this as a private message due to the To CPIM header. 1045 MSRP 9v9s2 SEND 1046 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1047 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1048 Message-ID: d9fghe982 1049 Byte-Range: 1-*/* 1050 Content-Type: message/cpim 1052 To: 1053 From: 1054 DateTime: 2009-03-02T15:02:31-03:00 1055 Content-Type: text/plain 1057 Hello Bob. 1058 -------9v9s2$ 1060 Figure 17: Private instant message sent to Bob 1062 9.5. Obtaining an anonymous URI 1064 Figure 18 presents a flow diagram where Alice registers her SIP AOR 1065 with the conference focus. The response will contain a temp-gruu 1066 which can be used as an anonymous URI when joining the conference. 1067 The temp-gruu is also used to send anonymous MSRP messages to and 1068 from the MSRP switch. 1070 Alice Conference focus 1071 | | 1072 |(1) (SIP) REGISTER | 1073 |----------------------->| 1074 |(2) (SIP) 200 OK | 1075 |<-----------------------| 1076 | | 1078 Figure 18: Flow diagram of registering an anonymous URI 1080 F1: Alice constructs an REGISTER including an instance id in her 1081 Contact header defined in draft-ietf-sip-gruu [I-D.ietf-sip-gruu]. 1083 REGISTER sip:chatroom22@chat.example.com SIP/2.0 1084 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1085 Max-Forwards: 70 1086 From: Alice ;tag=9fxced76sl 1087 To: Alice 1088 Supported: gruu 1089 Call-ID: 3848276298220188511@atlanta.example.com 1090 CSeq: 1 REGISTER 1091 Contact: \ 1092 ;+sip.instance="" 1093 Content-Length: 0 1095 Figure 19: REGISTER request containing a Contact header with an 1096 instance id 1098 F2: The chat room server accepts the registration returning a "pub- 1099 gruu" and a "temp-gruu". 1101 SIP/2.0 200 OK 1102 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1103 ;received=192.0.2.101 1104 From: Alice ;tag=9fxced76sl 1105 To: Alice 1106 Call-ID: 3848276298220188511@atlanta.example.com 1107 CSeq: 1 REGISTER 1109 Contact: \ 1110 ;pub-gruu="sip:callee@example.com \ 1111 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" \ 1112 ;temp-gruu="sip:tgruu.7hatz6cn-098s-anonymous@chat.example.com;gr" \ 1113 ;+sip.instance="" 1115 Content-Length: 0 1117 Figure 20: 200 (OK) response including a temp-gruu in the Contact 1118 header 1120 9.6. Sending a private message using anonymous URI 1122 Figure 21 depicts a flow diagram where Alice is utilizing the 1123 temporary GRUU when sending a private message to Bob 1124 Alice MSRP switch Bob 1125 | | | 1126 | (1) (MSRP) SEND | | 1127 |--------------------->| (3) (MSRP) SEND | 1128 | (2) (MSRP) 200 |----------------------->| 1129 |<---------------------| | 1130 | | | 1131 | | | 1132 | | | 1134 Figure 21: Sending an anonymous private message to Bob 1136 F1: Alice builds a text message adding her registered temp-gruu to 1137 the From header of the CPIM message 1139 MSRP 7443ruls SEND 1140 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1141 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1142 Message-ID: aft4to 1143 Byte-Range: 1-*/* 1144 Content-Type: message/cpim 1146 To: 1147 From: 1148 DateTime: 2009-03-02T15:02:31-03:00 1149 Content-Type: text/plain 1151 Hello Bob. 1152 -------7443ruls$ 1154 Figure 22: Anonymous private instant message 1156 F2: The MSRP switch inspects the From header field and verifies that 1157 the temp-gruuu in registered to Alice. If the temporary gruu is 1158 valid, the MSRP acknowledges the reception of SEND request with a 200 1159 (OK) response 1161 MSRP 7443ruls 200 OK 1162 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 1163 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 1164 Message-ID: aft4to 1165 Byte-Range: 1-*/* 1166 -------7443ruls$ 1168 Figure 23: 200 (OK) response 1170 Flow F3 is not shown 1172 10. IANA Considerations 1174 10.1. New MSRP Method 1176 This specification defines a new MSRP method to be added to the 1177 Methods sub-registry under the MSRP Parameter registry: NICKNAME. 1178 See section Section 7 for details. 1180 10.2. New MSRP Header 1182 This specification defines a new MSRP header to be added to the 1183 header-field sub registry under the MSRP Parameter registry: 1184 Use-Nickname. See section Section 7 for details. 1186 10.3. New MSRP Status Codes 1188 This specification defines three new MSRP status codes to be added to 1189 the Status-Code sub-registry under MSRP parameters. 1191 The 427 status code indicates the failure to resolve the recipient 1192 URI in the To header field of the Message/CPIM wrapper in the SEND 1193 request. See section for details. 1195 The 428 status code indicates that the recipient of a SEND request 1196 does not support private messages. See section for details. 1198 The 423 response indicates that the requested nickname is not 1199 allocated to the user requesting it. See section Section 7 for 1200 details. 1202 10.4. New SDP Attribute 1204 This specification defines a new media level attribute in the Session 1205 Description Protocol (SDP) Parameters registry: chatroom. See 1206 section Section 8 for details. 1208 11. Security Considerations 1210 This document proposes extensions to the Message Session Relay 1211 Protocol [RFC4975]. Therefore, the security considerations of such 1212 document apply to this document as well. 1214 In general, messages sent to a multi-party session based messaging 1215 focus are not deem to expose any security threat. Nevertheless, if a 1216 participant wants to avoid eavesdropping from non authorized 1217 entities, it should send those messages a TLS [RFC4346] transport 1218 connection, as allowed by MSRP. 1220 12. Contributors 1222 This work would have never been possible without the fruitful 1223 discussions in the SIMPLE WG mailing list, specially with Brian Rosen 1224 (Neustar) and Paul Kyzivat (Cisco), who provided extensive review and 1225 improvements throughout the document. 1227 13. Acknowledgments 1229 The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach and 1230 Matt Lepinski for providing comments. 1232 14. References 1234 14.1. Normative References 1236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1237 Requirement Levels", BCP 14, RFC 2119, March 1997. 1239 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1240 A., Peterson, J., Sparks, R., Handley, M., and E. 1241 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1242 June 2002. 1244 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1245 "Indicating User Agent Capabilities in the Session 1246 Initiation Protocol (SIP)", RFC 3840, August 2004. 1248 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1249 (CPIM)", RFC 3860, August 2004. 1251 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1252 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1254 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1255 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1257 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1258 Description Protocol", RFC 4566, July 2006. 1260 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1261 Initiation Protocol (SIP) Event Package for Conference 1262 State", RFC 4575, August 2006. 1264 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1265 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1267 [I-D.ietf-sip-gruu] 1268 Rosenberg, J., "Obtaining and Using Globally Routable User 1269 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1270 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 1271 October 2007. 1273 14.2. Informative References 1275 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1276 April 2000. 1278 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1279 with Session Description Protocol (SDP)", RFC 3264, 1280 June 2002. 1282 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1283 Protocol (XMPP): Core", RFC 3920, October 2004. 1285 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1286 RFC 3966, December 2004. 1288 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1289 Session Initiation Protocol (SIP)", RFC 4353, 1290 February 2006. 1292 [I-D.ietf-xcon-framework] 1293 Barnes, M., Boulton, C., and O. Levin, "A Framework for 1294 Centralized Conferencing", draft-ietf-xcon-framework-11 1295 (work in progress), April 2008. 1297 Authors' Addresses 1299 Aki Niemi 1300 Nokia 1301 P.O. Box 407 1302 NOKIA GROUP, FIN 00045 1303 Finland 1305 Phone: +358 50 389 1644 1306 Email: aki.niemi@nokia.com 1307 Miguel A. Garcia-Martin 1308 Ericsson 1309 Calle Via de los Poblados 13 1310 Madrid, ES 28033 1311 Spain 1313 Email: miguel.a.garcia@ericsson.com 1315 Geir A. Sandbakken (editor) 1316 TANDBERG 1317 Philip Pedersens vei 20 1318 N-1366 Lysaker 1319 Norway 1321 Phone: +47 67 125 125 1322 Email: geir.sandbakken@tandberg.com 1323 URI: http://www.tandberg.com