idnits 2.17.1 draft-ietf-simple-chat-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1211. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1235. 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 == Line 554 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", 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", 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 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 (October 30, 2008) is 5657 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 (==), 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 Nokia 4 Intended status: Standards Track M. Garcia-Martin 5 Expires: May 3, 2009 Nokia Siemens Networks 6 G. Sandbakken, Ed. 7 TANDBERG 8 October 30, 2008 10 Multi-party Chat Using the Message Session Relay Protocol (MSRP) 11 draft-ietf-simple-chat-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 3, 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 The Message Session Relay Protocol (MSRP) defines a mechanism for 45 sending instant messages within a peer-to-peer session, negotiated 46 using the Session Initiation Protocol (SIP) and the Session 47 Description Protocol (SDP). This document defines the necessary 48 tools for establishing multi-party chat sessions, or chat rooms, 49 using MSRP. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Motivations and Requirements . . . . . . . . . . . . . . . . . 5 56 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 57 5. Creating, Joining, and Deleting a Chat Room . . . . . . . . . 8 58 5.1. Creating a Chat Room . . . . . . . . . . . . . . . . . . . 8 59 5.2. Joining a Chat Room . . . . . . . . . . . . . . . . . . . 8 60 5.3. Deleting a Chat Room . . . . . . . . . . . . . . . . . . . 9 61 6. Sending and Receiving Instant Messages . . . . . . . . . . . . 9 62 6.1. Regular Messages . . . . . . . . . . . . . . . . . . . . . 9 63 6.2. Private Messages . . . . . . . . . . . . . . . . . . . . . 10 64 7. Nicknames . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7.1. Using Nicknames within a Conference . . . . . . . . . . . 13 66 7.2. Modifying a Nickname . . . . . . . . . . . . . . . . . . . 14 67 7.3. Removing a Nickname . . . . . . . . . . . . . . . . . . . 14 68 7.4. Nicknames in the Conference Event Package . . . . . . . . 14 69 7.5. Nicknames not supported nor allowed . . . . . . . . . . . 15 70 8. The SDP 'chatroom' attribute . . . . . . . . . . . . . . . . . 15 71 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 9.1. Joining a chat room . . . . . . . . . . . . . . . . . . . 16 73 9.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 18 74 9.3. Sending a regular message to the chat room . . . . . . . . 20 75 9.4. Sending a private message to a participant . . . . . . . . 21 76 9.5. Obtaining an anonymous URI . . . . . . . . . . . . . . . . 23 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 79 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 80 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 83 14.2. Informative References . . . . . . . . . . . . . . . . . . 26 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 85 Intellectual Property and Copyright Statements . . . . . . . . . . 28 87 1. Introduction 89 The Message Session Relay Protocol (MSRP) [RFC4975] defines a 90 mechanism for sending a series of instant messages within a session. 91 The Session Initiation Protocol (SIP) [RFC3261] in combination with 92 the Session Description Protocol (SDP) [RFC3264] allows for two peers 93 to establish and manage such sessions. 95 In another application of SIP, a user agent can join in a multi-party 96 conversation called a conference that is hosted by a specialized user 97 agent called a focus [RFC4353]. Such a conference can naturally 98 involve an MSRP session as one of possibly many media components. It 99 is the responsibility of an entity handling the media to relay 100 instant messages received from one participant to the rest of the 101 participants in the conference. 103 Several such systems already exist in the Internet. Participants in 104 a chat room can be identified with a pseudonym or nickname, and 105 decide whether their real identity is disclosed to other 106 participants. Participants can also use a rich set of features such 107 as the ability to send private instant messages to other 108 participants. They also allow combining instant messaging with other 109 media components, such as voice, video, white boarding, screen 110 sharing, and file transfer. 112 Similar conferences are already available today with other 113 technologies different than MSRP. For example, Internet Relay Chat 114 (IRC) [RFC2810], Extensible Messaging and Presence Protocol [RFC3920] 115 based chat rooms, and many other proprietary systems provide this 116 kind of functionality. It makes sense to specify equivalent 117 functionality for MSRP-based systems to both provide competitive 118 features as well as enable interworking between the systems. 120 This document defines requirements, conventions, and extensions for 121 providing private messages and nickname management in centralized 122 conferences with MSRP. This document, however, does not specify 123 functionality that can be used in conference with media different 124 than MSRP. This memo uses the SIP Conferencing Framework [RFC4353] 125 as a design basis. It also aims to be compatible with the 126 Centralized Conferencing Framework [I-D.ietf-xcon-framework]. It is 127 expected that future mechanisms will be developed for providing 128 similar functionality in generic conferences, i.e., where the media 129 is not only restricted to MSRP. The mechanisms described in this 130 document provide a future compatible short-term solution for MSRP 131 centralized conferences. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119, BCP 14 138 [RFC2119], and indicate requirement levels for compliant 139 implementations. 141 This memo deals with a particular case of tightly coupled SIP 142 conferences where the media exchanged consist of session-based 143 instant messaging. Unless otherwise noted, we use the terminology 144 defined in the SIP Conferencing Framework [RFC4353] applied to the 145 scope of this document. In addition to that terminology, we 146 introduce some new terms: 148 Nickname: a pseudonym or descriptive name associated to a 149 participant. See Section 7 for details 151 Multi-party chat: an instance of a tightly coupled conference, in 152 which the media exchanged between the participants consist of 153 (among others) MSRP based instant messages. Also known as a chat 154 room. 156 Chat Room: a synonym for a multi-party chat 158 Chat Room URI: a URI that identifies a particular chat room. Since 159 a chat room is a specialized conference of instant messages, in 160 the context of this document, a chat room URI is a synonym of a 161 conference URI. 163 Sender: the conference participant that originally created an 164 instant message and sent it to the chat room for delivery. 166 Recipient: the destination conference participant(s). This 167 defaults to the full conference participant list, minus the IM 168 Sender. 170 MSRP switch: a media level entity that receives MSRP messages and 171 delivers them to the other conference participants. An MSRP 172 switch has a similar role to a conference mixer with the exception 173 that an MSRP switch does not actually "mix" together different 174 input media streams; it merely relays the messages between 175 participants. 177 Private Instant Message: an instant message sent in a chat room 178 whose intended to a single participant. A private IM is usually 179 rendered distinctly from the rest of the IMs, as to indicate that 180 the message was a private communication. 182 Anonymous URI: a temporary GRUU that can be registered with the 183 conference focus to conceal a participant's SIP AOR from the other 184 participants in the a conference. 186 3. Motivations and Requirements 188 Although conference frameworks describing many types of conferencing 189 applications already exist, such as the Framework and Data Model for 190 Centralized Conferencing [I-D.ietf-xcon-framework] and the SIP 191 Conferencing Framework [RFC4353], the exact details of session-based 192 instant messaging conferences are not well-defined at the moment. 194 To allow interoperable chat implementations, for both conference- 195 aware, and conference-unaware user agents, certain conventions for 196 MSRP conferences need to be defined. It also seems beneficial to 197 provide a set of features that enhance the baseline multi-party MSRP 198 in order to be able to create systems that have functionality on par 199 with existing chat systems, as well as enable building interworking 200 gateways to these existing chat systems. 202 We define the following requirements: 204 REQ-1: A basic requirement is the existence of a multi-party 205 conference, where participants can join and leave the 206 conference and get instant messages exchanged to the rest of 207 the participants. 209 REQ-2: The conference must have the ability to host other media in 210 addition to MSRP, as well as multiple streams of MSRP. 212 REQ-3: A conference participant must be able to determine the 213 identities of the sender and recipient of the received IMs. 215 REQ-4: A conference participant must be able to determine the 216 recipient of the received message. For instance, the 217 recipient of the message might be the entire conference or a 218 single participant of the conference (i.e., a private 219 message). 221 REQ-5: It must be possible to send a message to a single 222 participant within the conference (i.e., a private instant 223 message). 225 REQ-6: A conference participant may have a nickname or pseudonym 226 associated with their real identity. 228 REQ-7: It must be possible for a participant to change their 229 nickname during the progress of the conference. 231 REQ-8: It must be possible that a participant is only known by 232 their nickname and not their real identity to the rest of 233 the conference. 235 REQ-9: It must be possible for the MSRP switch itself to send IMs 236 to the conference (e.g. message of the day, welcome 237 messages, server is shutting down, etc.) 239 REQ-10: It must be possible for participants to learn the 240 capabilities support of the features described in this 241 document (and perhaps others). 243 4. Overview of Operation 245 In order to set up a conference, one must first be created. Users 246 wishing to host a conference themselves can of course do just that; 247 their user agents simply morph from an ordinary user agent into a 248 special purpose one called a conference focus. Another, commonly 249 used setup is one where a dedicated node in the network functions as 250 a conference focus. 252 Each chat room has an identity of its own: a SIP URI that 253 participants use to join the conference, e.g. by sending an INVITE 254 request. The conference focus processes the invitations, and as 255 such, maintains SIP dialogs with each participant. In an multi-party 256 chat, or chat room, MSRP is one of the established media streams. 257 Each conference participant establishes an MSRP session with an MSRP 258 switch, which is a special purpose MSRP application. The MSRP switch 259 is similar to a conference mixer in that it handles media sessions 260 with each of the participants and bridges these streams together. 261 However, unlike a conference mixer, the MSRP switch merely relays 262 messages between participants but doesn't actually mix the streams in 263 any way. The system is illustrated in Figure 1. 265 +------+ 266 | MSRP | 267 |Client| 268 +------+ +--.---+ +------+ 269 | MSRP | | | MSRP | 270 |Client| | _|Client| 271 +------._ | ,' +------+ 272 `._ | ,' 273 `.. +----------+ ,' 274 `| |' 275 | MSRP | 276 | Switch | 277 ,| |_ 278 _,-'' +----------+ ``-._ 279 +------.-' | `--+------+ 280 | MSRP | | | MSRP | 281 |Client| | |Client| 282 +------+ | +------+ 283 +---'--+ 284 | MSRP | 285 |Client| 286 +------+ 288 Figure 1: Multiparty MSRP in a Centralized Conference 290 Typically conference participants also subscribe to the conference 291 event package [RFC4575] to gather information about the conference 292 roster in the form of conference state notifications. For example, 293 participants can learn about other participants' identities. 295 All messages in the chat room use the 'Message/CPIM' wrapper content 296 type [RFC3862], so that it is possible to distinguish between private 297 and regular messages. When a participant wants to send an instant 298 message to the conference, it constructs an MSRP SEND request and 299 submits it to the MSRP switch including a regular payload (e.g. a 300 Message/CPIM message that contains a text, html, an image, etc.). 301 The Message/CPIM To header is set to the chat room URI. The switch 302 then fans out the SEND request to all of the other participants using 303 their existing MSRP sessions. 305 A participant can also send a private instant message addressed to a 306 participants whose identity has been learned, e.g. via a notification 307 from the conference event package [RFC4575]. In this case the sender 308 creates an MSRP SEND request with a Message/CPIM body whose To header 309 contains not the chat room URI but the recipient's URI. The MSRP 310 switch then forwards the SEND request to the recipient. 312 We extend the current MSRP negotiation that takes place in SDP 314 [RFC4566] to allow participants to learn whether the chat room 315 supports and is willing to accept (e.g. due to local policy 316 restrictions) certain MSRP functions defined in this memo, such as 317 nicknames or private messaging. 319 Naturally, when a participant wishes to leave a chat room, it sends a 320 SIP BYE request to the conference focus and disconnects. 322 5. Creating, Joining, and Deleting a Chat Room 324 5.1. Creating a Chat Room 326 Since we consider a chat room a particular type of conference where 327 one of the offered media happens to be MSRP, the methods defined by 328 the SIP Conference Framework [RFC4353] for creating conferences are 329 directly applicable to a chat room. 331 Once a chat room is created, it is identified by a SIP URI, like any 332 other conference. 334 5.2. Joining a Chat Room 336 Participants usually join the conference by sending an INVITE request 337 to the conference URI. As long as the conference policy allows, the 338 INVITE request is accepted by the focus and the user is brought into 339 the conference. Participants are aware that the peer is a focus due 340 to the presence of the "isfocus" feature tag [RFC3840] in the Contact 341 header field of the 200-class response to the INVITE request. 342 Participants are also aware that the mixer is an MSRP switch due to 343 the presence of an additional 'message' media type and either TCP/ 344 MSRP or TCP/TLS/MSRP as the protocol field in the SDP [RFC4566] 345 media-line. 347 The conference focus of a chat room MUST include support for a 348 Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by 349 setting the 'accept-types' MSRP media line attribute in the SDP offer 350 or answer to include 'Message/CPIM'. 352 Note that the 'Message/CPIM' wrapper is used to carry the sender 353 information that, otherwise, it will not be available to the 354 recipient. Additionally, 'Message/CPIM' wrapper carries the 355 recipient information (e.g. To and Cc: headers). 357 If a participant wants to remain anonymous to the rest of the 358 participants in the conference, the participant's UA can register or 359 acquire by other means a temporary GRUU with the conference focus. 360 The procedure SHOULD follow the recommendation of draft-ietf-sip-gruu 362 [I-D.ietf-sip-gruu]. The temporary GRUU can be used in the From and 363 To header in the 'Message/CPIM' wrapper concealing the participant's 364 SIP AOR from the other participants in the conference. 366 The conference focus of a chat room MUST learn the chat room 367 capabilities of each participant that joins the chat room, and MUST 368 inform the MSRP switch of such support. This is to prevent that the 369 MSRP switch distributes private messages to participants who do not 370 support private messaging. 372 5.3. Deleting a Chat Room 374 As with creating a conference, the methods defined by the SIP 375 Conference Framework [RFC4353] for deleting a conference are directly 376 applicable to a chat room. 378 Deleting a chat room is an action that heavily depends on the policy 379 of the chat room. The policy can determine that the chat room is 380 deleted when the creator leaves the conference, or with any out of 381 band mechanism. 383 6. Sending and Receiving Instant Messages 385 6.1. Regular Messages 387 This section describes the conventions used to send and receive 388 instant messages that are addressed to all the participants in the 389 chat room. These are sent over a regular MSRP SEND request that 390 contains a Message/CPIM wrapper [RFC3862] that in turn contains the 391 desired payload (e.g. text, image, video-clip, etc.). 393 When a chat room participant wishes to send an instant message to all 394 the other participants in the chat room, he constructs an MSRP SEND 395 request that MUST contain a top-level wrapper of type 'Message/CPIM' 396 [RFC3862]. The actual instant message payload inside 'Message/CPIM' 397 MAY be of any type negotiated in the SDP 'accepted-types' attribute 398 according to the MSRP rules. 400 The sender SHOULD populate the From header of the Message/CPIM 401 wrapper with a proper identity by which the user is recognized in the 402 conference. Identities that can be used (among others) are: 404 o A SIP URI [RFC3261] representing the participant's address-of- 405 record 407 o A tel URI [RFC3966] representing the participant's telephone 408 number 410 o An IM URI [RFC3860] representing the participant's instant 411 messaging address 413 o An temporary GRUU [I-D.ietf-sip-gruu] representing the anonymous 414 URI associated with the sender. 416 An MSRP switch that receives a SEND request from a participant SHOULD 417 first verify that the From header field of the Message/CPIM wrapper 418 is correctly populated with a valid URI. The valid URI can be the 419 SIP AOR of the participant, or a temporary GRUU registered with the 420 focus associated with an anonymous participant. If the URI included 421 in the From header field of the Message/CPIM wrapper is not valid 422 (e.g, because it does not "belong" to the user), then the MSRP switch 423 MUST generate a 403 response and MUST NOT forward the SEND request to 424 any of the participants. Otherwise, the MSRP switch SHOULD generate 425 a 200 response according to the MSRP rules for response generation. 427 Then the MSRP switch should inspect the To header field of the 428 Message/CPIM wrapper. If the To header field of the Message/CPIM 429 wrapper contains the chat room URI, the MSRP switch can generate a 430 copy of the SEND request to each of the participants in the 431 conference except the sender. The MSRP switch MUST NOT modify any of 432 the bodies included in the received SEND request. Note that the MSRP 433 switch does not need to wait for the reception of the complete MSRP 434 chunk or MSRP message before it starts the distribution to the rest 435 of the participants. Instead, once the MSRP switch has received the 436 headers of the Message/CPIM body it SHOULD start the distribution 437 process. 439 An MSRP endpoint that receives a SEND request from an MSRP switch 440 containing a Message/CPIM wrapper SHOULD first inspect the To header 441 field of the Message/CPIM body. If the To header field is set to the 442 chat room URI, then it is a regular message that has been distributed 443 to all the participants in the conference. Then the MSRP endpoint 444 SHOULD inspect the From header field of the Message/CPIM body to 445 identify the sender. The From header field will include a URI that 446 identifies the sender. The endpoint might have also received further 447 identity information through a subscription to the SIP conference 448 event package [RFC4575]. 450 6.2. Private Messages 452 This section describes the conventions used to send and receive 453 private instant messages, i.e., instant messages that are addressed 454 to one participant of the chat room rather to all of them. A chat 455 room can signal support for private messages using the chatroom- 456 attribute (see Section 8 for details). 458 When a chat room participant wishes to send a private instant message 459 to a participant the chat room, he constructs an MSRP SEND request 460 that MUST contain a top-level wrapper of type 'Message/CPIM' 461 [RFC3862]. The actual instant message payload inside 'Message/CPIM' 462 MAY be of any type negotiated in the SDP 'accepted-types' attribute 463 according to the MSRP rules (e.g. text, image, video-clip etc.) 465 The sender SHOULD populate the From header of the Message/CPIM 466 wrapper with a proper identity by which the user is recognized in the 467 conference as indicated for regular instant messages. Then the 468 sender MUST populate the To header field with the identity of 469 intended recipient. The identity can be SIP, TEL, and IM URIs 470 typically learned from the information received in notifications of 471 the conference event package [RFC4575]. 473 As for regular messages, an MSRP switch that receives a SEND request 474 from a participant SHOULD first verify that the From header field of 475 the Message/CPIM wrapper is correctly populated with a valid URI. If 476 the URI included in the From header field of the Message/CPIM wrapper 477 is not valid (e.g, because it does not "belong" to the user), then 478 the MSRP switch MUST generate a 403 response and MUST NOT forward the 479 SEND request to any of the participants. Otherwise, the MSRP switch 480 SHOULD generate a 200 response according to the MSRP rules for 481 response generation. 483 Then the MSRP switch MUST inspect the To header field of the Message/ 484 CPIM wrapper. If the To header field of the Message/CPIM wrapper 485 does not contain the chat room URI, it must check if it contains a 486 participants URI associated with a participant. If the URI in the To 487 header can not be resolved (e.g. cased by a mistyped URI or that the 488 recipient has abandoned he chat room), and the Failure-Report header 489 field of the SEND request was either not present in the original 490 request, or had a value of "yes", the MSRP switch MUST generate a 491 REPORT request to the sender. The status header field MUST be set to 492 427. The new 427 status code indicates a failure to resolve the 493 recipient URI in the To header field. If the recipient is valid, but 494 the recipient does not support private messages, and the Failure- 495 Report header field of the SEND request was either not present in the 496 original request, or had a value of "yes", the MSRP switch MUST send 497 a REPORT request having the status code of 428. The new response 428 498 indicate that the recipient does not support private messages. In 499 either case the REPORT request MUST include a Message/CPIM wrapper, 500 with the original From header field included in the SEND request, and 501 the To header field of the original message. The message MUST not be 502 forwarded to the recipient if above conditions applies. The MSRP 503 switch should search it's mapping table to find the MSRP session 504 established towards the recipient. If a match is found the MSRP 505 switch MUST create a SEND request and MUST copy the contents of the 506 sender's message to it. 508 If the original SEND request contained a Success-report header field 509 with the value of "yes" it MUST be added to the SEND request intended 510 for the recipient. If the MSRP switch receives an success report 511 from the recipient of the private message, and the original request 512 had the Success-report header field present with a value of "yes", 513 the MSRP switch MUST create a success REPORT and MUST copy the 514 contents of the recipient's report to it. The REPORT MUST be sent to 515 the originator of the original SEND request. 517 An MSRP endpoint that receives a SEND request from an MSRP switch 518 containing a Message/CPIM wrapper SHOULD first inspect the To header 519 field of the Message/CPIM body. If the To header field is not set to 520 the chat room URI, then it is a private message. Then the MSRP 521 endpoint SHOULD inspect the From header field of the Message/CPIM 522 body to identify the sender. The From header field will include a 523 URI that identifies the sender. The endpoint might have also 524 received further identity information through a subscription to the 525 SIP conference event package [RFC4575]. 527 It is possible that a participant, identified by a SIP Address of 528 Record, joins a conference of instant messages from two or more 529 different SIP UAs. It is RECOMMENDED that the an MSRP switch can map 530 a participant or anonymous URI for two or more MSRP sessions. If the 531 policy of the server allows for this, the MSRP switch MUST copy all 532 messages intended for the recipient through each MSRP session. 534 7. Nicknames 536 A common characteristic of existing chat room services is that 537 participants have the ability to identify themselves with a nickname 538 to the rest of the participants of the conference. It is used for 539 easy reference of participants in the chat room, and can also provide 540 anonymous participants with a meaningful descriptive name. 542 Nicknames are a useful construct in many use cases, of which MSRP 543 chat is but one example. Nicknames are an alternate form of 544 identity, associated with a URI of which the participant is known to 545 the focus. It is not a 'display-name', but it is used somewhat like 546 a display name. A main difference is that a nickname is unique 547 inside a chat room to allow an unambiguous reference to a participant 548 in the chat. Nicknames may be long lived, or may be temporary. 549 Users also need to reserve a nickname prior to its utilization. 551 This memo specifies the nickname as a string. The nickname string 552 MUST be unambiguous within the scope of the chat room (conference 553 instance). This scope is similar to having a nickname unique inside 554 a chat room from Extensible Messaging and Presence Protocol 555 [RFC3920]. The chat room may have policies associated with 556 nicknames. It may not accept nickname strings at all, or a it may 557 provide a wider unambiguous scope like a domain or server, similar to 558 Internet Relay Chat (IRC) [RFC2810]. 560 7.1. Using Nicknames within a Conference 562 This memo provides a mechanism to reserve a nickname for a 563 participant for as long as the participants is logged into the chat 564 room. The mechanism is based on a NICKNAME MSRP method (see below) 565 and a new "Use-Nickname" header. Note that other mechanisms may 566 exists (for example, a web page reservation system), although they 567 are outside the scope of this document. 569 A conference participant who has established an MSRP session with an 570 MSRP switch, where the MSRP switch has indicated the support and 571 availability of nicknames with the 'nicknames' token in the 572 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP 573 switch. The NICKNAME request MUST include a new Use-Nickname header 574 that contains the nickname string that the participant wants to 575 reserve. 577 An MSRP switch that receives a NICKNAME request containing a nickname 578 in the Use-Nickname header field SHOULD first verify whether the 579 policy of the chat room allows the nickname functionality. If is not 580 allowed, the MSRP switch MUST answer with a 501 response. 582 If the policy of the chat room allows the usage of nicknames, the 583 MSRP switch SHOULD validate that the SIP AOR is entitled to reserve 584 the nickname. The participant's authenticated identity can be 585 derived after a successful HTTP Digest Authentication, included in a 586 trusted SIP P-Asserted-Identity header field, included in a valid SIP 587 Identity header field, or derived from any other present or future 588 SIP authentication mechanism. Once the MSRP switch has validated 589 that the participant is entitled to reserve the nickname, the MSRP 590 switch answers to the MSRP NICKNAME request with a 200 response. 592 The reservation of a nickname can fail, e.g. if the NICKNAME request 593 contains a malformed or non-existent Use-Nickname header field, or if 594 the same nickname has already been reserved by another participant in 595 the conference. The validation can also fail where the SIP AOR is 596 not entitled to reserve the nickname. In any of these cases the MSRP 597 switch MUST answer with a newly defined 423 response. The semantics 598 of the 423 response are: "Nickname usage failed; the nickname is not 599 allocated to this user". 601 As indicated earlier, this specification defines a new MSRP header 602 field: "Use-Nickname". The Use-Nickname header field carries a 603 nickname string, and SHOULD be included in the NICKNAME requests. 605 The syntax of the NICKNAME method and the "Use-Nickname" header field 606 is built upon the MSRP formal syntax [RFC4975] 608 ext-method =/ NICKNAMEm 609 NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps 610 ext-header =/ Use-Nickname 611 ; ext-header is specified in RFC 4975 612 Use-Nickname = "Use-Nickname" ":" nickname 613 nickname = quoted-string 615 7.2. Modifying a Nickname 617 Typically participants will reserve a nickname as soon as they join 618 the chat room. But it is also possible for participants to modify 619 their own nicknames and replace them it a new one at any time during 620 the duration of the MSRP session. Modification of the nickname is 621 not different from the initial reservation and usage of a nickname, 622 thus the NICKNAME method is used as described in Section 7.1. 624 If a NICKNAME request that attempts to modify the current nickname of 625 the user for some reason fails, the current nickname stays in effect. 626 A new nickname comes into effect and the old one is released only 627 after a NICKNAME request is accepted with a 200 response. 629 7.3. Removing a Nickname 631 If the participant no longer wants to be known by a nickname in the 632 conference, the participant can follow the method described in 633 Section 7.2. The nickname element of the Use-Nickname header MUST be 634 set to an empty quoted string. 636 7.4. Nicknames in the Conference Event Package 638 Typically the conference focus acts as a notifier of the SIP 639 conference event package [RFC4575]. The conference focus MAY notify 640 subscribers of the nickname reserved by a given participant. We 641 define an extension to the conference event package to include 642 nicknames. The extension adds a attribute to the 643 containing the nickname string. 645 TO BE DONE: include a formal definition of the 646 extension to the conference event package. 648 7.5. Nicknames not supported nor allowed 650 The participants SHOULD be notified of the URIs associated with the 651 other participants of the conference even if nicknames are provided. 652 The entity attribute in event notification framework being an SIP AOR 653 or anonymous URI. A client not supporting the extensions of this 654 memo will not render nicknames and can therefore can not be referred 655 to using nickname inside the chat room. The same would apply where a 656 chat room do not allow nicknames to be used. 658 8. The SDP 'chatroom' attribute 660 There are a handful of use cases where a participant would like to 661 learn the chat room capabilities supported by the MSRP switch and the 662 chat room. For example, a participant would like to learn if the 663 MSRP switch supports private messaging, otherwise, the participant 664 may send what he believes is a private instant message addressed to a 665 participant, but since the MSRP switch does not support the functions 666 specified in this memo, the message gets eventually distributed to 667 all the participants of the chat room. 669 The reverse case also exists. A participant, say Alice, whose user 670 agent does not support the extensions defined by this document joins 671 the chat room. The MSRP switch learns that Alice application does 672 not support private messaging nor nicknames. If another participant, 673 say Bob, sends a private message to Alice, the MSRP switch does not 674 distribute it to Alice, because Alice is not able to differentiate it 675 from a regular message sent to the whole roster. Further more, if 676 Alice replied to this message, she would do it to the whole roster. 677 Because of this, the MSRP switch keeps also track of users who do not 678 support the extensions defined in this document. 680 In another scenario, the policy of a chat room may indicate that 681 certain functions are not allowed. For example, the policy may 682 indicate that nicknames or private messages are not allowed. 684 In order to provide the user with a good chat room experience, we 685 define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a 686 media-level attribute that MAY be included in conjunction with and 687 MSRP media stream (i.e., when an m= line in SDP indicates "TCP/MSRP" 688 or "TCP/TLS/MSRP"). The 'chatroom' attribute indicates the 689 intersection of support and chat room local policy allowance for a 690 number of functions specified in this document. Specifically, we 691 provide the means for indicating support to use nicknames and private 692 messaging. 694 The 'chatroom' SDP attribute has the following syntax: 696 chatroom = chatroom-label ":" chat-token *(SP chat-token) 697 chatroom-label = "chatroom" 698 chat-token = (nicknames-token | private-msg-token | token) 699 nicknames-token = "nicknames" 700 private-msg-token = "private-messages" 702 A conference focus that includes the 'nicknames' token in the session 703 description is signaling that the MSRP switch supports and the chat 704 room allows to use the procedures specified in Section 7. A 705 conference focus that includes the 'private-messages' in the SDP 706 description is signaling that the MSRP switch supports and the chat 707 room allows to use the procedures specified in Section 6.2. 709 Example of the 'chatroom' attribute for an MSRP media stream that 710 indicates the acceptance of nicknames and private messages: 712 a=chatroom:nickname private-messages 714 9. Examples 716 9.1. Joining a chat room 718 Figure 5 presents a flow diagram where Alice joins a chat room by 719 sending an INVITE request. This INVITE request contains a session 720 description that includes the chatroom extensions defined in this 721 document. 723 Alice Conference focus 724 | | 725 |(1) (SIP) INVITE | 726 |----------------------->| 727 |(2) (SIP) 200 OK | 728 |<-----------------------| 729 |(3) (SIP) ACK | 730 |----------------------->| 731 | | 733 Figure 5: Flow diagram of a user joining a chat room 735 F1: Alice constructs an SDP description that includes an MSRP media 736 stream. She also indicates her support for the chatroom extensions 737 defined in this document. She sends the INVITE request to the chat 738 room server. 740 INVITE sip:chatroom22@chat.example.com SIP/2.0 741 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 742 Max-Forwards: 70 743 From: Alice ;tag=9fxced76sl 744 To: Chatroom 22 745 Call-ID: 3848276298220188511@atlanta.example.com 746 CSeq: 1 INVITE 747 Contact: 748 Content-Type: application/sdp 749 Content-Length: [length] 751 v=0 752 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com 753 s=- 754 c=IN IP4 atlanta.example.com 755 m=message 7654 TCP/MSRP * 756 a=accept-types:message/cpim text/plain text/html 757 a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 758 a=chatroom:nickname private-messages 760 Figure 6: INVITE request containing an SDP offer with chat room 761 extensions 763 F2: The chat room server accepts the session establishment. It 764 includes the 'isfocus' and other relevant feature tags in the Contact 765 header field of the response. The chat room server also builds an 766 SDP answer that also that forces the reception of messages wrapped in 767 message/cpim envelops. It also includes the the chatroom attribute 768 with the allowed extensions. 770 SIP/2.0 200 OK 771 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 772 ;received=192.0.2.101 773 From: Alice ;tag=9fxced76sl 774 To: Chatroom 22 ;tag=8321234356 775 Call-ID: 3848276298220188511@atlanta.example.com 776 CSeq: 1 INVITE 777 Contact: \ 778 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \ 779 ;automata;isfocus;message;event="conference" 780 Content-Type: application/sdp 781 Content-Length: [length] 783 v=0 784 o=chat 2890844527 2890844527 IN IP4 chat.example.com 785 s=- 786 c=IN IP4 chat.example.com 787 m=message 12763 TCP/MSRP * 788 a=accept-types:message/cpim 789 a=accept-wrapped-types:text/plain text/html * 790 a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 791 a=chatroom:nickname private-messages 793 Figure 7: 200 (OK) response including chat room extensions 795 F3: The session established is acknowledged (details not shown). 797 9.2. Setting up a nickname 799 Figure 8 shows an example of Alice setting up a nickname using the 800 conference as provider. Her first proposal is not accepted because 801 the proposed nickname is already in use. Her second proposal is 802 accepted. 804 Alice MSRP switch 805 | | 806 |(1) (MSRP) NICKNAME | 807 |----------------------->| 808 |(2) (MSRP) 423 | 809 |<-----------------------| 810 |(3) (MSRP) NICKNAME | 811 |----------------------->| 812 |(4) (MSRP) 200 | 813 |<-----------------------| 814 | | 816 Figure 8: Flow diagram of a user setting up her nickname 818 F1: Alice sends an MSRP NICKNAME request that contains her proposed 819 nicknames in the Set-Nickname header field. 821 MSRP d93kswow NICKNAME 822 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 823 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 824 Use-Nickname: "Alice the great" 825 -------d93kswow$ 827 Figure 9: MSRP NICKNAME request with an initial nickname proposal 829 F2: The MSRP switch analyzes the existing allocation of nicknames and 830 detects that the nickname "Alice is great" is already provided to 831 another participant by the conference. The MSRP switch answers with 832 a 423 response. 834 MSRP d93kswow 423 Nickname usage failed 835 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 836 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 837 -------d93kswow$ 839 Figure 10: MSRP 423 response 841 F3: Alice receives the response. She proposes a new nickname in a 842 second NICKNAME request. 844 MSRP 09swk2d NICKNAME 845 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 846 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 847 Use-Nickname: "Alice in wonderland" 848 -------09swk2d$ 850 Figure 11: MSRP NICKNAME request with a second nickname proposal 852 F4: The MSRP switch accepts the nickname proposal and answers with a 853 200 response. 855 MSRP 09swk2d 200 OK 856 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 857 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 858 -------09swk2d$ 860 Figure 12: MSRP NICKNAME request 862 9.3. Sending a regular message to the chat room 864 Figure 13 depicts a flow diagram where Alice is sending a regular 865 message addressed to the chat room. The MSRP switch distributes the 866 message to the rest of the participants. 868 Alice MSRP switch Bob Charlie 869 | | | | 870 | (1) (MSRP) SEND | | | 871 |--------------------->| (3) (MSRP) SEND | | 872 | (2) (MSRP) 200 |----------------------->| | 873 |<---------------------| (4) (MSRP) SEND | | 874 | |------------------------------->| 875 | | (5) (MSRP) 200 OK | | 876 | |<-----------------------| | 877 | | (6) (MSRP) 200 OK | | 878 | |<------------------------------ | 879 | | | | 880 | | | | 882 Figure 13: Sending a regular message to the chat room 884 F1: Alice builds a text message and wraps it in a CPIM message. She 885 addresses the CPIM message to the chat room. She encloses the result 886 in an MSRP SEND request and sends it to the MSRP switch via the 887 existing TCP connection. 889 MSRP 3490visdm SEND 890 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 891 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 892 Message-ID: 99s9s2 893 Byte-Range: 1-*/* 894 Content-Type: message/cpim 896 To: 897 From: 898 DateTime: 2007-03-02T15:02:31-03:00 899 Content-Type: text/plain 901 Hello guys, how are you today? 902 -------3490visdm$ 904 Figure 14: Instant message addressed to all participants in the chat 905 room 907 F2: The MSRP switch acknowledges the reception of the SEND request 908 with a 200 (OK) response. 910 MSRP 3490visdm 200 OK 911 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 912 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 913 Message-ID: 99s9s2 914 Byte-Range: 1-*/* 915 -------3490visdm$ 917 Figure 15: 200 (OK) response 919 F3: The MSRP switch creates a new MSRP SEND request that contains the 920 received message/cpim body and sends it to Bob. 922 MSRP 490ej23 SEND 923 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 924 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 925 Message-ID: 304sse2 926 Byte-Range: 1-*/* 927 Content-Type: message/cpim 929 To: 930 From: 931 DateTime: 2007-03-02T15:02:31-03:00 932 Content-Type: text/plain 934 Hello guys, how are you today? 935 -------490ej23$ 937 Figure 16: Instant message sent to all participants 939 The rest of the message flows are analogous to the previous. They 940 are not shown here. 942 9.4. Sending a private message to a participant 944 Figure 17 depicts a flow diagram where Alice is sending a private 945 message addressed to Bob's SIP AOR. The MSRP switch distributes the 946 message only to Bob. 948 Alice MSRP switch Bob Charlie 949 | | | | 950 | (1) (MSRP) SEND | | | 951 |--------------------->| (3) (MSRP) SEND | | 952 | (2) (MSRP) 200 |----------------------->| | 953 |<---------------------| (4) (MSRP) SEND | | 954 | |------------------------------->| 955 | | | | 956 | | | | 957 Figure 17: Sending a private message to Bob 959 F1: Alice builds a text message and wraps it in a CPIM message. She 960 addresses the CPIM message to the Bob's nickname, which she learned 961 from a notification in the conference event package. She encloses 962 the result in an MSRP SEND request and sends it to the MSRP switch 963 via the existing TCP connection. 965 MSRP 6959ssdf SEND 966 To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 967 From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 968 Message-ID: okj3kw 969 Byte-Range: 1-*/* 970 Content-Type: message/cpim 972 To: 973 From: 974 DateTime: 2007-03-02T15:02:31-03:00 975 Content-Type: text/plain 977 Hello Bob. 978 -------6959ssdf$ 980 Figure 18: Private instant message addressed to one participant 982 F2: The MSRP switch acknowledges the reception of the SEND request 983 with a 200 (OK) response. 985 MSRP 6959ssdfm 200 OK 986 To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp 987 From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp 988 Message-ID: okj3kw 989 Byte-Range: 1-*/* 990 -------6959ssdfm$ 992 Figure 19: 200 (OK) response 994 F3: The MSRP switch creates a new MSRP SEND request that contains the 995 received message/cpim body and sends it only to Bob. Bob can 996 distinguish the sender in the From header of the CPIM message. He 997 also identifies this as a private message due to the To CPIM header. 999 MSRP 9v9s2 SEND 1000 To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp 1001 From-Path: msrp://chat.example.com:5678/jofofo3;tcp 1002 Message-ID: d9fghe982 1003 Byte-Range: 1-*/* 1004 Content-Type: message/cpim 1006 To: 1007 From: 1008 DateTime: 2007-03-02T15:02:31-03:00 1009 Content-Type: text/plain 1011 Hello Bob. 1012 -------9v9s2$ 1014 Figure 20: Private instant message sent to Bob 1016 Flow F4 is not shown. 1018 9.5. Obtaining an anonymous URI 1020 Figure 21 presents a flow diagram where Alice registers her SIP AOR 1021 with the conference focus. The response will contain a temp-gruu 1022 which can be used as an anonymous URI when joining the conference. 1023 The temp-gruu is also used to send anonymous MSRP messages to and 1024 from the MSRP switch. 1026 Alice Conference focus 1027 | | 1028 |(1) (SIP) REGISTER | 1029 |----------------------->| 1030 |(2) (SIP) 200 OK | 1031 |<-----------------------| 1032 | | 1034 Figure 21: Flow diagram of registering an anonymous URI 1036 F1: Alice constructs an REGISTER including an instance id in her 1037 Contact header defined in draft-ietf-sip-gruu [I-D.ietf-sip-gruu]. 1039 REGISTER sip:chatroom22@chat.example.com SIP/2.0 1040 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1041 Max-Forwards: 70 1042 From: Alice ;tag=9fxced76sl 1043 To: Alice 1044 Supported: gruu 1045 Call-ID: 3848276298220188511@atlanta.example.com 1046 CSeq: 1 REGISTER 1047 Contact: \ 1048 ;+sip.instance="" 1049 Content-Length: 0 1051 Figure 22: REGISTER request containing a Contact header with an 1052 instance id 1054 F2: The chat room server accepts the registration returning a "pub- 1055 gruu" and a "temp-gruu". 1057 SIP/2.0 200 OK 1058 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 1059 ;received=192.0.2.101 1060 From: Alice ;tag=9fxced76sl 1061 To: Alice 1062 Call-ID: 3848276298220188511@atlanta.example.com 1063 CSeq: 1 REGISTER 1065 Contact: \ 1066 ;pub-gruu="sip:callee@example.com \ 1067 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" \ 1068 ;temp-gruu="sip:tgruu.7hatz6cn-098s-anonymous@chat.example.com;gr" \ 1069 ;+sip.instance="" 1071 Content-Length: 0 1073 Figure 23: 200 (OK) response including a temp-gruu in the Contact 1074 header 1076 10. IANA Considerations 1078 TBD. 1080 11. Security Considerations 1082 This document proposes extensions to the Message Session Relay 1083 Protocol [RFC4975]. Therefore, the security considerations of such 1084 document apply to this document as well. 1086 In general, messages sent to a multi-party session based messaging 1087 focus are not deem to expose any security threat. Nevertheless, if a 1088 participant wants to avoid eavesdropping from non authorized 1089 entities, it should send those messages a TLS [RFC4346] transport 1090 connection, as allowed by MSRP. 1092 12. Contributors 1094 This work would have never been possible without the fruitful 1095 discussions in the SIMPLE WG mailing list, specially with Brian Rosen 1096 (Neustar) and Paul Kyzivat (Cisco), who provided extensive review and 1097 improvements throughout the document. 1099 13. Acknowledgments 1101 The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach and 1102 Matt Lepinski for providing comments. 1104 14. References 1106 14.1. Normative References 1108 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1109 Requirement Levels", BCP 14, RFC 2119, March 1997. 1111 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1112 A., Peterson, J., Sparks, R., Handley, M., and E. 1113 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1114 June 2002. 1116 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1117 "Indicating User Agent Capabilities in the Session 1118 Initiation Protocol (SIP)", RFC 3840, August 2004. 1120 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1121 (CPIM)", RFC 3860, August 2004. 1123 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1124 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1126 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1127 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1129 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1130 Description Protocol", RFC 4566, July 2006. 1132 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1133 Initiation Protocol (SIP) Event Package for Conference 1134 State", RFC 4575, August 2006. 1136 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1137 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1139 [I-D.ietf-sip-gruu] 1140 Rosenberg, J., "Obtaining and Using Globally Routable User 1141 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1142 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 1143 October 2007. 1145 14.2. Informative References 1147 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1148 April 2000. 1150 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1151 with Session Description Protocol (SDP)", RFC 3264, 1152 June 2002. 1154 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1155 Protocol (XMPP): Core", RFC 3920, October 2004. 1157 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1158 RFC 3966, December 2004. 1160 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1161 Session Initiation Protocol (SIP)", RFC 4353, 1162 February 2006. 1164 [I-D.ietf-xcon-framework] 1165 Barnes, M., Boulton, C., and O. Levin, "A Framework for 1166 Centralized Conferencing", draft-ietf-xcon-framework-11 1167 (work in progress), April 2008. 1169 Authors' Addresses 1171 Aki Niemi 1172 Nokia 1173 P.O. Box 407 1174 NOKIA GROUP, FIN 00045 1175 Finland 1177 Phone: +358 50 389 1644 1178 Email: aki.niemi@nokia.com 1180 Miguel A. Garcia-Martin 1181 Nokia Siemens Networks 1182 P.O.Box 6 1183 Nokia Siemens Networks, FIN 02022 1184 Finland 1186 Email: miguel.garcia@nsn.com 1188 Geir A. Sandbakken (editor) 1189 TANDBERG 1190 N-1366 Lysaker 1191 Norway 1193 Phone: +47 67 125 125 1194 Email: geir.sandbakken@tandberg.com 1195 URI: http://www.tandberg.com 1197 Full Copyright Statement 1199 Copyright (C) The IETF Trust (2008). 1201 This document is subject to the rights, licenses and restrictions 1202 contained in BCP 78, and except as set forth therein, the authors 1203 retain all their rights. 1205 This document and the information contained herein are provided on an 1206 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1207 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1208 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1209 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1210 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1211 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1213 Intellectual Property 1215 The IETF takes no position regarding the validity or scope of any 1216 Intellectual Property Rights or other rights that might be claimed to 1217 pertain to the implementation or use of the technology described in 1218 this document or the extent to which any license under such rights 1219 might or might not be available; nor does it represent that it has 1220 made any independent effort to identify any such rights. Information 1221 on the procedures with respect to rights in RFC documents can be 1222 found in BCP 78 and BCP 79. 1224 Copies of IPR disclosures made to the IETF Secretariat and any 1225 assurances of licenses to be made available, or the result of an 1226 attempt made to obtain a general license or permission for the use of 1227 such proprietary rights by implementers or users of this 1228 specification can be obtained from the IETF on-line IPR repository at 1229 http://www.ietf.org/ipr. 1231 The IETF invites any interested party to bring to its attention any 1232 copyrights, patents or patent applications, or other proprietary 1233 rights that may cover technology that may be required to implement 1234 this standard. Please address the information to the IETF at 1235 ietf-ipr@ietf.org. 1237 Acknowledgment 1239 Funding for the RFC Editor function is provided by the IETF 1240 Administrative Support Activity (IASA).