idnits 2.17.1 draft-ietf-stox-groupchat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2013) is 3863 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) == Outdated reference: A later version (-19) exists of draft-ietf-precis-nickname-06 == Outdated reference: A later version (-11) exists of draft-ietf-stox-core-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0045' -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 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 P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track S. Ibarra 5 Expires: April 1, 2014 AG Projects 6 S. Loreto 7 Ericsson 8 September 28, 2013 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Groupchat 12 draft-ietf-stox-groupchat-01 14 Abstract 16 This document defines a bidirectional protocol mapping for the 17 exchange of instant messages in the context of a multiparty chat 18 session among users of the Session Initiation Protocol (SIP) and 19 users of the Extensible Messaging and Presence Protocol (XMPP). 20 Specifically, this document defines a mapping between the SIP-based 21 Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat 22 (MUC) extension. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 1, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. XMPP MUC to MSRP Multi-party Messaging Session . . . . . . . . 3 61 3.1. Enter Room . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Set Nickname . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.3. Conference Subscription . . . . . . . . . . . . . . . . . 8 64 3.4. Presence Broadcast . . . . . . . . . . . . . . . . . . . . 9 65 3.5. Exchange Messages . . . . . . . . . . . . . . . . . . . . 12 66 3.5.1. Send a Message to All Occupants . . . . . . . . . . . 12 67 3.5.2. Send a Private Message . . . . . . . . . . . . . . . . 14 68 3.6. Change Nickname . . . . . . . . . . . . . . . . . . . . . 15 69 3.7. Invite Another User to a Room . . . . . . . . . . . . . . 16 70 3.8. Exit Room . . . . . . . . . . . . . . . . . . . . . . . . 18 71 4. MSRP Multi-party Messaging Session to XMPP MUC . . . . . . . . 18 72 4.1. Enter Room (Includes Set Nickname) . . . . . . . . . . . . 20 73 4.2. Presence Broadcast . . . . . . . . . . . . . . . . . . . . 23 74 4.3. Exchange Messages . . . . . . . . . . . . . . . . . . . . 26 75 4.3.1. Send a Message to All Occupants . . . . . . . . . . . 26 76 4.3.2. Send a Private Message . . . . . . . . . . . . . . . . 27 77 4.4. Change Nickname . . . . . . . . . . . . . . . . . . . . . 29 78 4.5. Invite Another User to a Room . . . . . . . . . . . . . . 30 79 4.6. Exit Room . . . . . . . . . . . . . . . . . . . . . . . . 31 80 5. Handling of Nicknames and Display Names . . . . . . . . . . . 31 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 33 86 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 89 1. Introduction 91 Both the Session Initiation Protocol (SIP) [RFC3261] and the 92 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] can be 93 used for the purpose of multiparty text chat over the Internet. To 94 ensure interworking between these technologies, it is important to 95 define bidirectional protocol mappings. 97 The architectural assumptions underlying such protocol mappings are 98 provided in [I-D.ietf-stox-core], including mapping of addresses and 99 error conditions. This document specifies mappings for multiparty 100 text chat sessions (often called "groupchat"); specifically, this 101 document defines a mapping between the XMPP Multi-User Chat (MUC) 102 extension [XEP-0045] and SIP-based multiparty chat using Message 103 Session Relay Protocol [RFC4975] as specified in 104 [I-D.ietf-simple-chat]. 106 Both MUC and MSRP contain a large set of features, such as the 107 ability to administer rooms, kick and ban users, reserve a nickname 108 within a room, change room subject, enable room moderation, and 109 destroy the room. This document covers only a basic subset of 110 groupchat features: joining a room, establishing or changing (but not 111 permanently registering) a room nickname, modifying presence 112 information within the room, sending a message to all participants, 113 sending a private message to a single participant, inviting another 114 user to the room, and leaving the room. Future documents might 115 define mappings for additional features beyond this set. 117 The discussion venue for this document is the mailing list of the 118 STOX WG; visit https://www.ietf.org/mailman/listinfo/stox for 119 subscription information and discussion archives. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119]. 128 A number of technical terms used here are defined in [RFC3261], 129 [RFC4975], [RFC6120], and [XEP-0045]. The term "JID" is short for 130 "Jabber ID". 132 3. XMPP MUC to MSRP Multi-party Messaging Session 134 This section describes how to map an XMPP MUC session to an MSRP 135 Multi-party Messaging session. The following diagram outlines the 136 overall protocol flow of a sample session, which includes some 137 optional exchanges (such as sending messages, changing nickname, and 138 inviting another user). 140 XMPP User Gateway MSRP Conference 141 | | | 142 |(X1) (XMPP) Enter room | | 143 |------------------------->| | 144 | |(X2) (SIP) INVITE | 145 | |------------------------->| 146 | |(X3) (SIP) 200 OK | 147 | |<-------------------------| 148 | |(X4) (SIP) ACK | 149 | |------------------------->| 150 | |(X5) (MSRP) NICKNAME | 151 | |------------------------->| 152 | |(X6) (MSRP) 200 OK | 153 | |<-------------------------| 154 | |(X7) (SIP) SUBSCRIBE | 155 | |------------------------->| 156 | | Event:conference | 157 | | | 158 | |(X8) (SIP) 200 OK | 159 | |<-------------------------| 160 | |(X9) (SIP) NOTIFY | 161 | |<-------------------------| 162 | |(X10) (SIP) 200 OK | 163 | |------------------------->| 164 |(X11) (XMPP) Presence | | 165 |<-------------------------| | 166 |(X12) (XMPP) Subject | | 167 |<-------------------------| | 168 | | | 169 |(X13) (XMPP) Groupchat message | 170 |------------------------->| | 171 | |(X14) (MSRP) SEND | 172 | |------------------------->| 173 | |(X15) (MSRP) 200 OK | 174 | |<-------------------------| 175 |(X16) (XMPP) Groupchat message | 176 |<-------------------------| | 177 | | | 178 |(X17) (XMPP) Private message | 179 |------------------------->| | 180 | |(X18) (MSRP) SEND | 181 | |------------------------->| 182 | |(X19) (MSRP) 200 OK | 183 | |<-------------------------| 184 | | | 185 |(X20) (XMPP) Change nick | | 186 |------------------------->| | 187 | |(X21) (MSRP) NICKNAME | 188 | |------------------------->| 189 | |(X22) (MSRP) 425 Error | 190 | |<-------------------------| 191 | | | 192 |(X23) (XMPP) Presence Error 193 |<-------------------------| | 194 | | | 195 |(X24) (XMPP) Message stanza to invite participant | 196 |------------------------->| | 197 | |(X25) (SIP) REFER | 198 | |------------------------->| 199 | |(X26) (SIP) 200 OK | 200 | |<-------------------------| 201 | |(X27) (SIP) NOTIFY | 202 | |<-------------------------| 203 . . . 204 . . . 205 |(X28) (XMPP) Exit room | | 206 |------------------------->| | 207 | |(X29) (SIP) BYE | 208 | |------------------------->| 209 | |(X30) (SIP) 200 OK | 210 | |<-------------------------| 211 |(X31) (XMPP) Presence unavailable 212 |<-------------------------| | 214 Detailed protocol flows and mappings are provided in the following 215 sections. 217 3.1. Enter Room 219 As defined in the XMPP Multi-User Chat (MUC) specification 220 [XEP-0045], when an XMPP user (say, "juliet@example.com") wants to 221 join a groupchat room (say, "verona@chat.example.org"), she sends a 222 directed stanza [RFC6121] to that chat room. In her 223 request she also specifies the nickname she wants to use within the 224 room (say, "JuliC"); in XMPP this room nickname is the resourcepart 225 of an occupant JID (thus "verona@chat.example.org/JuliC"). The 226 joining client signals its ability to speak the multi-user chat 227 protocol by including in the initial presence stanza an empty 228 element qualified by the 'http://jabber.org/protocol/muc' namespace. 230 Example 1: Juliet enters room (X1) 232 | 234 | 235 | 237 Upon receiving such a presence stanza, the XMPP server to which 238 Juliet has connected needs to determine the identity of the 239 domainpart in the 'to' address, which it does by following the 240 procedures discussed in [I-D.ietf-stox-core]. Here we assume that 241 the XMPP server has determined the domain is serviced by a SIMPLE 242 server, that it contains or has available to it an XMPP-SIMPLE 243 gateway or connection manager (which enables it to speak natively to 244 SIMPLE servers), and that it hands off the presence stanza to the 245 XMPP-SIMPLE gateway. 247 Because a multi-user chat service accepts the presence stanza shown 248 above as a request to enter a room, the XMPP-to-SIP gateway 249 transforms it into a SIP INVITE request. 251 Example 2: SIP mapping of room join (X2) 253 | INVITE sip:verona@chat.example.org SIP/2.0 254 | To: 255 | From: "Juliet" 256 | Contact: ;gr=balcony 257 | Call-ID: 711609sa 258 | Content-Type: application/sdp 259 | Content-Length: 182 260 | 261 | c=IN IP4 x2s.example.org 262 | m=message 7654 TCP/MSRP * 263 | a=accept-types:text/cpim 264 | a=accept-wrapped-types:text/plain text/html 265 | a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp 266 | a=chatroom 268 Here the Session Description Protocol offer specifies the MSRP-aware 269 XMPP-to-SIP gateway on the XMPP side as well as other particulars of 270 the session. 272 There is no direct mapping for the MSRP URIs. In fact MSRP URIs 273 identify a session of instant messages at a particular device; 274 they are ephemeral and have no meaning outside the scope of that 275 session. The authority component of the MSRP URI MUST contain the 276 XMPP-to-SIP gateway hostname or numeric IP address and an explicit 277 port number. 279 As specified in [I-D.ietf-stox-core], the mapping of XMPP syntax 280 elements to SIP and [RFC4566] syntax elements is as shown in the 281 following table. 283 Table 1: Message syntax mapping from XMPP to SIP/SDP 285 +-----------------------------+-----------------------------+ 286 | XMPP Element or Attribute | SIP Header or SDP Contents | 287 +-----------------------------+-----------------------------+ 288 | from | From | 289 | | Call-ID | 290 | to (without the /nick) | To | 291 +-----------------------------+-----------------------------+ 293 Here we assume that the MSRP conference server accepts the session 294 establishment. It includes the 'isfocus' and other relevant feature 295 tags in the Contact header field of the response. The MSRP 296 conference server also includes an answer session description that 297 acknowledges the choice of media and contains the extensions 298 specified in [I-D.ietf-simple-chat]. 300 Example 3: Chat room accepts session establishment (X3) 302 | SIP/2.0 200 OK 303 | From: 304 | To: "Juliet" ;tag=786 305 | Call-ID: 711609sa 306 | Contact: ;isfocus 307 | Content-Type: application/sdp 308 | Content-Length: 214 309 | 310 | c=IN IP4 example.org 311 | m=message 12763 TCP/MSRP * 312 | a=chatroom:nickname private-messages 313 | a=accept-types:message/cpim 314 | a=accept-wrapped-types:text/plain text/html 315 | a=path:msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 317 Upon receiving such a response, the SIMPLE server or associated SIP- 318 to-XMPP gateway sends a SIP ACK to the MSRP conference server on 319 behalf of the joining user. 321 Example 4: Gateway sends ACK to MSRP conference server (X4) 323 | ACK sip:verona@chat.example.org SIP/2.0 324 | To: ;tag=087js 325 | From: "Juliet" ;tag=786 326 | Call-ID: 711609sa 328 3.2. Set Nickname 330 If the chat room server accepted the session, the SIMPLE server or 331 associated SIP-to-XMPP gateway MUST set up the nickname as received 332 in the presence stanza (i.e., the resourcepart of the 'to' address, 333 such "JuliC" in "verona@chat.example.org/JuliC"). The nickname is 334 set up using the extension specified in [I-D.ietf-simple-chat]. 336 Example 5: Gateway sets up nickname (X5) 338 | MSRP a786hjs2 NICKNAME 339 | To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 340 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 341 | Use-Nickname: "JuliC" 342 | -------a786hjs2 344 The MSRP conference server analyzes the existing allocation of 345 nicknames, accepts the nickname proposal, and answers with a 200 346 response. 348 Example 6: MSRP conference accepts nickname proposal (X6) 350 | MSRP a786hjs2 200 OK 351 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 352 | From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 353 | -------a786hjs2 355 This section assumes that the nickname request is successful. The 356 error flow resulting from a nickname conflict is described under 357 Section 3.6. 359 3.3. Conference Subscription 361 If the nickname request is successful, the XMPP-to-SIP gateway then 362 formally subscribes to the MSRP conference on behalf of the XMPP 363 user. 365 Example 7: Gateway subscribes to the MSRP conference (X7) 367 | SUBSCRIBE sip:verona@chat.example.org SIP/2.0 368 | To: 369 | From: "Juliet" 370 | Contact: ;gr=balcony 371 | Call-ID: hsuKZGkjQewg6IJI8.PD5rRAvbuTYLR- 372 | Event: conference 373 | Expires: 600 374 | Accept: application/conference-info+xml 375 | Allow-Events: conference 376 | Content-Length: 0 378 The conference server will accept or reject the request based on 379 local policy. 381 Example 8: MSRP conference server accepts subscription request (X8) 383 | SIP/2.0 200 OK 384 | To: 385 | From: "Juliet" 386 | Call-ID: hsuKZGkjQewg6IJI8.PD5rRAvbuTYLR- 387 | Contact: ;isfocus 388 | Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, 389 | CANCEL, UPDATE, MESSAGE, REFER 390 | Expires: 600 391 | Content-Length: 0 393 3.4. Presence Broadcast 395 If the MSRP conference service accepts the request to enter a room, 396 the XMPP user expects to receive back presence information from all 397 the existing occupants of the room. So the XMPP-to-SIP gateway MUST 398 subscribe to the Conference Event package [RFC4575] on the MSRP 399 conference server. When the subscription is completed the MSRP 400 conference server sends to the XMPP-to-SIP gateway a NOTIFY 401 containing the presence information of all the existing occupants, 402 represented using the [RFC4575] format. 404 Example 9: MSRP conference sends presence information (X9) 406 | NOTIFY sip:verona@chat.example.org SIP/2.0 407 | To: "Juliet" ;gr=balcony 408 | From: ;tag=a3343df32 409 | Call-ID: k3l43id034ksereree 410 | Event: conference 411 | Subscription-State: active;expires=3600 412 | Content-Type: application/conference-info+xml 413 | Content-Length: ... 414 | 415 | 417 | 418 | Today in Verona 419 | 420 | 421 | tel:+18882934234 422 | 423 | 424 | 425 | 426 | 428 | Romeo 429 | 430 | participant 431 | 432 | 433 | 435 | Ben 436 | 437 | participant 438 | 439 | 440 | 442 | JuliC 443 | 444 | participant 445 | 446 | 447 | 448 | 450 The following table shows the syntax mapping from the RFC 4575 451 payload to the XMPP participant list. (Mappings for elements not 452 mentioned are undefined.) 454 Table 2: Participant list mapping 456 +--------------------------------+-----------------------------+ 457 | RFC 4575 Element | XMPP Element or Attribute | 458 +--------------------------------+-----------------------------+ 459 | conference-info entity | room JID | 460 | conference subject | room subject | 461 | user entity | participant bare JID | 462 | user display-text / nickname | participant nickname | 463 | endpoint entity | participant full JID | 464 +--------------------------------+-----------------------------+ 466 Upon receiving such a response, the SIP-to-XMPP gateway MUST send a 467 200 OK to the MSRP conference server and translate the participant 468 list into a series of XMPP presence stanzas. 470 Example 10: XMPP mapping of chatroom presence (F11) 472 | 474 | 475 | 476 | 477 | 479 | 481 | 482 | 483 | 484 | 486 | 488 | 489 | 490 | 491 | 492 | 494 If the NOTIFY included a subject, the gateway converts that into a 495 separate XMPP message. 497 Example 11: XMPP mapping of chatroom subject (F12) 499 | 502 | Today in Verona 503 | 505 The mapping of SIP and [RFC4575] payload syntax elements to XMPP 506 syntax elements is as shown in the following table. (Mappings for 507 elements not mentioned are undefined.) 509 Table 3: Message syntax mapping from SIP to XMPP 511 +---------------------------------+-----------------------------+ 512 | SIP Header or RFC4575 Contents | XMPP Element or Attribute | 513 +---------------------------------+-----------------------------+ 514 | | from | 515 | Call-ID | thread | 516 | To + / | to | 517 | roles | role | 518 | 'none' | affiliation | 519 +---------------------------------+-----------------------------+ 521 3.5. Exchange Messages 523 Once the user has joined the chatroom, the user can exchange an 524 unbounded number of messages, both public and private. 526 The mapping of XMPP syntax elements to MSRP syntax elements is as 527 shown in the following table. (Mappings for elements not mentioned 528 are undefined.) 530 Table 4: Message syntax mapping from XMPP Message to MSRP 532 +-----------------------------+-----------------------------+ 533 | XMPP Element or Attribute | CPIM Header | 534 +-----------------------------+-----------------------------+ 535 | to | To | 536 | from | From | 537 | | body of the SEND request | 538 +-----------------------------+-----------------------------+ 540 3.5.1. Send a Message to All Occupants 542 When Juliet wants to sends a message to all other occupants in the 543 room, she sends a message of type "groupchat" to the 544 itself (in our example, ). 546 The following examples show an exchange of a public message. 548 Example 12: Juliet sends message to all occupants (X13) 550 | 554 | Who knows where Romeo is? 555 | 557 Upon receiving such a message, the XMPP-to-SIP gateway MUST translate 558 it into an MSRP SEND message. 560 Example 13: Gateway maps XMPP message to MSRP (X14) 562 | MSRP a786hjs2 SEND 563 | To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 564 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 565 | Message-ID: 87652491 566 | Byte-Range: 1-*/* 567 | Content-Type: message/cpim 568 | 569 | To: 570 | From: "Juliet" 571 | DateTime: 2008-10-15T15:02:31-03:00 572 | Content-Type: text/plain 573 | 574 | Who knows where Romeo is? 575 | -------a786hjs2$ 577 Upon receiving the SEND request, if the request either contains a 578 Failure-Report header field value of "yes" or does not contain a 579 Failure-Report header at all, the MSRP conference server MUST 580 immediately generate and send a response. 582 Example 14: MSRP conference returns 200 OK (X15) 584 | MSRP d93kswow 200 OK 585 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 586 | From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 587 | -------d93kswow$ 589 Since an XMPP MUC room could be moderated and an XMPP user cannot be 590 sure whether her message has been accepted or not without receiving 591 it back from the server, [XEP-0045] states that the sender needs to 592 receive the same message it has generated. So in this scenario the 593 XMPP-to-SIP gateway has to reflect the message back to the sender. 595 This prodedure only applies to XMPP endpoints. 597 Example 15: Gateway reflects message to XMPP user (X16) 599 | 603 | Who knows where Romeo is? 604 | 606 3.5.2. Send a Private Message 608 Since each occupant has a unique JID, Juliet can send a "private 609 message" to a selected occupant through the service by sending a 610 message to the user's occupant JID. The XMPP message type SHOULD be 611 "chat" and MUST NOT be "groupchat", but MAY be left unspecified. 613 If the XMPP-to-SIP gateway has support for private messaging it MUST 614 advertise that fact by adding a "private-messages" value to the 615 a=chatroom SDP attribute it sends to the MSRP conference server, as 616 specified in [I-D.ietf-simple-chat]. 618 | a=chatroom:nickname private-messages 620 The following examples show an exchange of a private message. 622 Example 16: Juliet sends private message (X17) 624 | 628 | O Romeo, Romeo! wherefore art thou Romeo? 629 | 631 Upon receiving such a message, the XMPP-to-SIP gateway MUST translate 632 it into an MSRP SEND message. 634 Example 17: Gateway maps private message from XMPP to MSRP (X18) 636 | MSRP a786hjs2 SEND 637 | To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 638 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 639 | Message-ID: 87652491 640 | Byte-Range: 1-*/* 641 | Content-Type: message/cpim 642 | 643 | To: ;gr=Romeo 644 | From: ;gr=balcony 645 | DateTime: 2008-10-15T15:02:31-03:00 646 | Content-Type: text/plain 647 | 648 | O Romeo, Romeo! wherefore art thou Romeo? 649 | -------a786hjs2$ 651 After acknowledging the message by sending a SIP 200 OK (step X19, 652 not shown), the MSRP conference server is responsible for sending the 653 message to the intended recipient (not shown in the protocol flow). 654 When doing so, it MUST modify the "From" header to the sender's 655 address within the chatroom. 657 Example 18: MSRP conference sends private message to SIP user 659 | MSRP a786hjs2 SEND 660 | To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 661 | From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 662 | Message-ID: 87652491 663 | Byte-Range: 1-*/* 664 | Content-Type: message/cpim 665 | 666 | To: 667 | From: ;gr=JuliC 668 | DateTime: 2008-10-15T15:02:31-03:00 669 | Content-Type: text/plain 670 | 671 | O Romeo, Romeo! wherefore art thou Romeo? 672 | -------a786hjs2$ 674 3.6. Change Nickname 676 The XMPP user might want to change her nickname. She can do so by 677 sending an updated presence stanza to the room, containing a new 678 nickname. 680 Example 19: Juliet changes her nickname (X20) 682 | 685 So far we have assumed that the requested nickname did not conflict 686 with any existing nicknames. The following text describes the 687 handling of a nickname conflict. 689 The MSRP conference server analyzes the existing allocation of 690 nicknames, and detects that the nickname proposal is already provided 691 to another participant. In this case the MSRP conference server 692 answers with a 425 response. 694 Example 20: MSRP conference does not accept nickname proposal (X22) 696 | MSRP a786hjs2 425 Nickname usage failed 697 | To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp 698 | From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp 699 | -------a786hjs2 701 Upon receiving such a response, the SIP-to-XMPP gateway SHOULD 702 translate it into an XMPP presence stanza of type "error" specifying 703 a error condition (which implies that the XMPP client 704 will then need to choose another nickname and repeat the process of 705 joining). 707 Example 21: Conflict error for nickname (X23) 709 | 712 | 713 | 714 | 715 | 716 | 718 Alternatively, the gateway might generate a new nickname request on 719 behalf of the XMPP user, thus shielding the XMPP client from handling 720 the conflict error. 722 3.7. Invite Another User to a Room 724 In XMPP there are two methods for inviting another user to a room: 725 direct invitations [XEP-0249] (sent directly from the user's real JID 726 outside the room to the invitee's real JID) and mediated invitations 727 (sent through the room from the user's occupant JID to the invitee's 728 JID). In this document we cover mediated invitations only. 730 For example, if Juliet decides to invite Benvolio to the room, she 731 sends a message stanza with an invite and Benvolio's JID (which could 732 be his real JID or an occupant JID in another room). 734 Example 22: Juliet invites Benvolio to the room (X24) 736 | 739 | 740 | 741 | 742 | 744 The SIP-to-XMPP gateway then sends a SIP REFER request to the MSRP 745 conference server indicating who needs to be invited in the Refer-To 746 header, as per [RFC4579] (sec 5.5) 748 Example 23: SIP mapping of invite (X25) 750 | REFER sip:verona@chat.example.com SIP/2.0 751 | To: 752 | From: "Juliet" ;tag=5534562 753 | Call-ID: 849392fklgl43 754 | Contact: ;gr=balcony 755 | Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 756 | Accept: message/sipfrag 757 | Refer-To: 758 | Supported: replaces 759 | Content-Length: 0 761 The MSRP conference server then acknowledges the SIP REFER request 762 with a 200 OK response (step X25, not shown). 764 The progress of the invitation will be tracked by the received NOTIFY 765 requests as per [RFC3515]. 767 Example 24: Progress notification for invitation (X27) 769 | NOTIFY sip:juliet@example.com SIP/2.0 770 | To: ;tag=5534562 771 | From: ;tag=18747389 772 | Call-ID: 849392fklgl43 773 | Max-Forwards: 70 774 | Event: refer 775 | Subscription-State: active;expires=60 776 | Contact: ;isfocus 777 | Content-Type: message/sipfrag;version=2.0 778 | Content-Length: ... 780 3.8. Exit Room 782 If Juliet decides to exit the chatroom, her client sends a directed 783 presence stanza of type "unavailable" to the occupant JID she is 784 currently using in the room (here ). 786 Example 25: Juliet exits room (X28) 788 | 792 Upon receiving such a stanza, the XMPP-to-SIP gateway terminates the 793 SIP session by sending a SIP BYE to the MSRP conference server and 794 the MSRP conference server responds with a 200 OK (steps X29 and X30, 795 not shown). 797 Juliet MAY include a custom exit message in the presence stanza of 798 type "unavailable", in which case it SHOULD be broadcasted to other 799 participants using the methods described above. 801 Example 26: Juliet exits the chatroom (F31) 803 | 806 | Time to go! 807 | 809 4. MSRP Multi-party Messaging Session to XMPP MUC 811 This section describes how to map a Multi-party Instant Message (IM) 812 MSRP session to an XMPP Multi-User Chat (MUC) session. As before, 813 the following diagram outlines the overall protocol flow of a sample 814 session, which includes some optional exchanges (such as sending 815 messages, changing nickname, and inviting another user). 817 SIP User Gateway XMPP MUC 818 | | | 819 |(S1)(SIP) INVITE | | 820 |------------------------>| | 821 |(S2) (SIP) 200 OK | | 822 |<------------------------| | 823 |(S3) (SIP) ACK | | 824 |------------------------>| | 825 |(S4) (MSRP) NICKNAME | | 826 |------------------------>| | 827 | |(S5)(XMPP) Enter room | 828 | |-------------------------->| 829 |(S6) (MSRP) 200 OK | | 830 |<------------------------| | 831 | |(S7)(XMPP) (XMPP) Presence | 832 | |<--------------------------| 833 | | | 834 |(S8)(SIP) SUBSCRIBE | | 835 |------------------------>| | 836 | Event:conference | | 837 | | | 838 |(S9) (SIP) 200 OK | | 839 |<------------------------| | 840 |(S10) (SIP) NOTIFY | | 841 |<------------------------| | 842 |(S11) (SIP) 200 OK | | 843 |------------------------>| | 844 | |(S12)(XMPP) (XMPP) Subject | 845 | |<--------------------------| 846 | | | 847 |(S13)(MSRP) SEND | | 848 |------------------------>| | 849 | |(S14)(XMPP) Chat message | 850 |(S15)(MSRP) 200 OK |-------------------------->| 851 |<------------------------|(S16)(XMPP) Chat message | 852 | |<--------------------------| 853 |(S17)(MSRP) SEND | | 854 |<------------------------| | 855 |(S18)(MSRP) 200 OK | | 856 |------------------------>| | 857 | | | 858 |(S19)(MSRP) SEND | | 859 |------------------------>| | 860 | |(S20)(XMPP) Private message| 861 | |-------------------------->| 862 |(S21)(MSRP) 200 OK | | 863 |<------------------------| | 864 | | | 865 |(S22)(MSRP) NICKNAME | | 866 |------------------------>|(S24)(XMPP) Presence | 867 | |-------------------------->| 868 | |(S25)(XMPP) Presence Error | 869 | |<--------------------------| 870 |(S26)(MSRP) 425 Error | | 871 |<------------------------| | 872 | | | 873 |(S27)(SIP) REFER | | 874 |------------------------>| | 875 | | | 876 |(S28)(SIP) 200 OK | | 877 |<------------------------| | 878 | | | 879 |(S29)(SIP) NOTIFY | | 880 |<------------------------| | 881 | | | 882 | |(S30)(XMPP) Message stanza | 883 | | to invite participant | 884 | |-------------------------->| 885 . . . 886 . . . 887 | | | 888 |(S31)(SIP) BYE | | 889 |------------------------>| | 890 | |(S32)(XMPP) Exiting a room | 891 | |-------------------------->| 892 |(S33)(SIP) 200 OK | | 893 |<------------------------| | 895 If the XMPP presence stanza is received before the SIP SUBSCRIBE 896 dialog is established for the "conference" event, then the server 897 SHOULD cache the participant list until the subscription is 898 established and delivered in a SIP NOTIFY request. 900 4.1. Enter Room (Includes Set Nickname) 902 When the SIP user ("Romeo") wants to join a groupchat room 903 ("Verona"), he first has to start the SIP session by sending out a 904 SIP INVITE request containing an offered session description that 905 includes an MSRP media line accompanied by a mandatory "path" and 906 "chatroom" attributes. The MSRP media line is also accompanied by an 907 "accept-types" attribute specifing support for a Message/CPIM top 908 level wrapper for the MSRP message. 910 Example 27: SIP user starts session (S1) 912 | INVITE sip:verona@chat.example.org SIP/2.0 913 | To: 914 | From: "Romeo" 915 | Contact: ;gr=orchard 916 | Call-ID: 742510no 917 | Content-Type: application/sdp 918 | Content-Length: 163 919 | 920 | c=IN IP4 s2x.example.net 921 | m=message 7313 TCP/MSRP * 922 | a=accept-types:message/cpim text/plain text/html 923 | a=accept-wrapped-types:text/plain text/html 924 | a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp 925 | a=chatroom 927 Upon receiving the INVITE, the SIP-to-XMPP gateway needs to determine 928 the identity of the remote domain, which it does by following the 929 procedures discussed in [I-D.ietf-stox-core]. Here we assume that 930 the gateway server has determined that the remote domain is serviced 931 by an XMPP server, that it contains or has available to it a SIP-to- 932 XMPP gateway or connection manager (which enables it to speak 933 natively to XMPP servers), and that it hands off the message to the 934 gateway. If this succeeds, the gateway SHOULD answer successfuly 935 with a SIP 200 OK (S2, not shown). 937 Implementations MAY wait until the nickname is set with an MSRP 938 NICKNAME chunk before joining the XMPP MUC or MAY choose a temporary 939 nickname (such as the SIP From header display name) and use it to 940 join the room. 942 Example 28: SIP user acks session (S3) 944 | SIP/2.0 200 OK 945 | To: 946 | From: "Romeo" 947 | Contact: ;isfocus 948 | Call-ID: 742510no 949 | Content-Type: application/sdp 950 | 951 | c=IN IP4 x2s.example.com 952 | m=message 8763 TCP/MSRP * 953 | a=accept-types:message/cpim text/plain text/html 954 | a=accept-wrapped-types:text/plain text/html 955 | a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 956 | a=chatroom:nickname private-messages 957 The SIP user then requests a nickname. 959 Example 29: MSRP user sets up nickname (S4) 961 | MSRP a786hjs2 NICKNAME 962 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 963 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 964 | Use-Nickname: "Romeo" 965 | -------a786hjs2 967 Upon receiving the MSRP NICKNAME request, the SIP-to-XMPP gateway is 968 responsible for generating an XMPP presence stanza and sending it to 969 the chatroom. 971 Example 30: Romeo enters XMPP chatroom (S5) 973 | 975 | 976 | 978 If the room does not already contain another user with the requested 979 nickname, the service accepts the access request. Thus if the 980 gateway does not receive any stanza of type "error" specifying a 981 error condition within a reasonable amount of time (e.g., 982 5 seconds), it MUST answer the MSRP nickname proposal with a 200 OK 983 response (S6). 985 Example 31: Acknowledgement of join (S6) 987 | MSRP a786hjs2 200 OK 988 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 989 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 990 | -------a786hjs2 992 Once the nickname has been set the user subscribes to the conference 993 event. 995 Example 32: User subscribes to the conference event (S8) 997 | SUBSCRIBE sip:verona@chat.example.org SIP/2.0 998 | To: 999 | From: "Romeo" 1000 | Contact: ;gr=orchard 1001 | Call-ID: hsuKZGkjQewg6IJI8.PD5rRAvbuTYLR- 1002 | Event: conference 1003 | Expires: 600 1004 | Accept: application/conference-info+xml 1005 | Allow-Events: conference 1006 | Content-Length: 0 1008 The gateway will accept or reject the request based on local policy. 1010 Example 33: Gateway accepts subscription (S9) 1012 | SIP/2.0 200 OK 1013 | To: 1014 | From: "Romeo" 1015 | Call-ID: hsuKZGkjQewg6IJI8.PD5rRAvbuTYLR- 1016 | Contact: ;isfocus 1017 | Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, 1018 | CANCEL, UPDATE, MESSAGE, REFER 1019 | Expires: 600 1020 | Content-Length: 0 1022 4.2. Presence Broadcast 1024 If the multi-user chat service is able to add the SIP user to the 1025 room, it sends presence from all the existing occupants' room JIDs to 1026 the new occupant's full JID, including extended presence information 1027 about roles in an element. 1029 Example 34: XMPP service sends presence from existing occupants to 1030 new occupant (S7) 1032 | 1034 | 1035 | 1036 | 1037 | 1038 | 1040 | 1042 | 1043 | 1044 | 1045 | 1047 | 1049 | 1050 | 1051 | 1052 | 1054 Upon receiving these presence stanzas, if the MSRP conference server 1055 has already completed the subscription to the Conference Event 1056 package [RFC4575], the XMPP-to-SIP gateway MUST translate them into a 1057 SIP NOTIFY request containing the participant list (represented in 1058 the conference-info format specified in [RFC4575]). 1060 Example 35: MSRP mapping of XMPP participant presence (S10) 1062 | NOTIFY sip:romeo@example.com SIP/2.0 1063 | To: ;tag=43524545 1064 | From: ;tag=a3343df32 1065 | Call-ID: k3l43id034ksererff 1066 | Event: conference 1067 | Subscription-State: active;expires=3600 1068 | Content-Type: application/conference-info+xml 1069 | Content-Length: ... 1070 | 1071 | 1073 | 1074 | Today in Verona 1075 | 1076 | 1077 | tel:+18882934234 1078 | sip:verona@chat.example.org 1079 | 1080 | 1081 | 1082 | 1083 | 1085 | JuliC 1086 | 1087 | participant 1088 | 1089 | 1090 | 1092 | Ben 1093 | 1094 | participant 1095 | 1096 | 1097 | 1099 Because the "room roster" is communicated in XMPP by means of 1100 multiple presence stanzas (one for each participant) whereas the 1101 participant list is communicated in SIP by means of a single 1102 conference-info document, the SIP-to-XMPP gateway will need to keep 1103 track of the user's SIP URI and the mapping of that URI into an XMPP 1104 address; then, based on that mapping, it will need to determine when 1105 it has received a complete room roster from the MUC room, i.e., when 1106 it has received the in-room presence of the SIP user (which according 1107 to XEP-0045 is the last presence stanza received in the initial batch 1108 sent after joining). Once that happens, the SIP-to-XMPP gateway can 1109 construct the conference-info document containing the complete 1110 participant list and send that to the SIP user. 1112 4.3. Exchange Messages 1114 Once the user has joined the chat room, the user can exchange an 1115 unbounded number of messages, both public and private. 1117 The mapping of MSRP syntax elements to XMPP syntax elements SHOULD be 1118 as shown in the following table. (Mappings for elements not 1119 mentioned are undefined.) 1121 Table 5: Message syntax mapping from MSRP Message to XMPP 1123 +-----------------------------+-----------------------------+ 1124 | CPIM Header |XMPP Element or Attribute | 1125 +-----------------------------+-----------------------------+ 1126 | To | to | 1127 | From | from | 1128 | body of the SEND request | | 1129 +-----------------------------+-----------------------------+ 1131 4.3.1. Send a Message to All Occupants 1133 When Romeo wants to send a message to all other occupants in the 1134 room, he sends an MSRP SEND request to itself (i.e., 1135 in our example). 1137 The following examples show an exchange of a public message. 1139 Example 36: Romeo sends a message to the chat room (S13) 1141 | MSRP a786hjs2 SEND 1142 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1143 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1144 | Message-ID: 87652492 1145 | Byte-Range: 1-*/* 1146 | Content-Type: message/cpim 1147 | 1148 | To: 1149 | From: "Romeo" ;gr=orchard 1150 | DateTime: 2008-10-15T15:02:31-03:00 1151 | Content-Type: text/plain 1152 | 1153 | Romeo is here! 1154 | -------a786hjs2$ 1155 Upon receiving the SEND request, if the request either contains a 1156 Failure-Report header field value of "yes" or does not contain a 1157 Failure-Report header at all, the SIP-to-XMPP gateway MUST 1158 immediately translate it into an XMPP message stanza (S14) and then 1159 generate and send an MSRP response (S15). 1161 Example 37: XMPP mapping of message (S14) 1163 | 1167 | Romeo is here! 1168 | 1170 Example 38: MSRP response to public message (S15) 1172 | MSRP d93kswow 200 OK 1173 | To-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1174 | From-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1175 | -------d93kswow$ 1177 Note well that the XMPP MUC room will reflect the sender's message 1178 back to all users, including the sender. In MSRP this reflected 1179 message is unnecessary. Therefore gateways are advised to maintain a 1180 cache and if the same stanza is received within a reasonable amount 1181 of time, assume is the reflected message and ignore it. 1183 4.3.2. Send a Private Message 1185 Romeo can send a "private message" to a selected occupant via the 1186 chat room service by sending a message to the occupant's room 1187 nickname. 1189 The following examples show an exchange of a private message. 1191 Example 39: Romeo sends a private message (S19) 1193 | MSRP a786hjs2 SEND 1194 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1195 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1196 | Message-ID: 87652492 1197 | Byte-Range: 1-*/* 1198 | Content-Type: message/cpim 1199 | 1200 | To: ;gr=JuliC 1201 | From: "Romeo" ;gr=orchard 1202 | DateTime: 2008-10-15T15:02:31-03:00 1203 | Content-Type: text/plain 1204 | 1205 | I am here!!! 1206 | -------a786hjs2$ 1208 The MSRP conference is responsible for transforming the "From" 1209 address into an in-room address. 1211 Example 40: MSRP handling of private message 1213 | MSRP a786hjs2 SEND 1214 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1215 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1216 | Message-ID: 87652492 1217 | Byte-Range: 1-*/* 1218 | Content-Type: message/cpim 1219 | 1220 | To: ;gr=JuliC 1221 | From: ;gr=Romeo 1222 | DateTime: 2008-10-15T15:02:31-03:00 1223 | Content-Type: text/plain 1224 | 1225 | I am here!!! 1226 | -------a786hjs2$ 1228 Once the MSRP conference sends that message to the gateway, the 1229 gateway is responsible for translating it into XMPP syntax. 1231 Example 41: XMPP mapping of private message (S20) 1233 | 1237 | I am here!!! 1238 | 1240 4.4. Change Nickname 1242 If Romeo decides to change his nickname within the room, he MUST send 1243 a new MSRP NICKNAME request. In fact modification of the nickname in 1244 MSRP is not different from the initial reservation and usage of a 1245 nickname. 1247 Example 42: MSRP user changes nickname (S22) 1249 | MSRP a786hjs2 NICKNAME 1250 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1251 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1252 | Use-Nickname: "montecchi" 1253 | -------a786hjs2 1255 Upon receiving such a message, the SIP-to-XMPP gateway MUST translate 1256 it into an XMPP presence stanza. 1258 Example 43: XMPP mapping of nickname change (S24) 1260 | 1263 The XMPP server will analyze the nickname allocation and determine if 1264 the requested nickname is available. In case the nickname is not 1265 available or not usable, the server will generate a presence stanza 1266 of type "error" specifying a error condition. 1268 Example 44: XMPP conflict error for nickname (S25) 1270 | 1273 | 1274 | 1275 | 1276 | 1277 | 1279 Upon receiving this stanza, the XMPP-SIP gateway will reply to the 1280 NICKNAME request with code 425 1282 Example 45: Gateway translates XMPP nickname conflict to MSRP error 1283 code (S26) 1285 | MSRP a786hjs2 425 Nickname usage failed 1286 | To-Path: msrp://s2x.example.net:7313/ansp71weztas;tcp 1287 | From-Path: msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp 1288 | -------a786hjs2 1290 4.5. Invite Another User to a Room 1292 If a SIP user wants to invite another user to join the conference he 1293 will send a REFER request indicating who needs to be invited in the 1294 Refer-To header, as per Section 5.5 of [RFC4579]. 1296 Example 46: Inviting a XMPP participant (S27) 1298 | REFER sip:verona@chat.example.org SIP/2.0 1299 | To: 1300 | From: "Romeo" ;tag=5534562 1301 | Call-ID: 849392fklgl43 1302 | Contact: ;gr=orchard 1303 | Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 1304 | Accept: message/sipfrag 1305 | Refer-To: 1306 | Supported: replaces 1307 | Content-Length: 0 1309 The XMPP-SIP gateway then acknowledges the SIP REFER request with a 1310 200 OK response (step S28, not shown). 1312 The gateway will then send a NOTIFY requests as per [RFC3515] 1313 indicating that the invitation is is progress. Since there is no way 1314 know the progress of the invitation until the user has joined, 1315 implementations are advised to terminate the REFER dialog 1316 subscription with the first NOTIFY, with a status code of 100 Trying. 1318 Example 47: Progress notification for invitation (S29) 1320 | NOTIFY sip:romeo@example.com SIP/2.0 1321 | To: ;tag=5534562 1322 | From: ;tag=18747389 1323 | Call-ID: 849392fklgl43 1324 | Event: refer 1325 | Subscription-State: terminated;reason=noresource 1326 | Contact: ;isfocus 1327 | Content-Type: message/sipfrag;version=2.0 1328 | Content-Length: 20 1329 | 1330 | SIP/2.0 100 Trying 1332 4.6. Exit Room 1334 If Romeo decides to exit the chat room, his client sends a SIP BYE to 1335 the chat room. 1337 Example 48: Romeo terminates session (S27) 1339 | BYE sip:verona@chat.example.org SIP/2.0 1340 | Max-Forwards: 70 1341 | From: "Romeo" ;tag=786 1342 | To: ;tag=534 1343 | Call-ID: 742510no 1344 | Cseq: 1 BYE 1345 | Content-Length: 0 1347 Upon receiving the SIP BYE, the SIP-to-XMPP gateway translates it 1348 into a presence stanza (F19) and sends it to the XMPP MUC room 1349 service. Then the SIP-to-XMPP gateway responds with a 200 OK to the 1350 MSRP user. 1352 Example 49: Romeo exits chatroom (S28) 1354 | 1358 5. Handling of Nicknames and Display Names 1360 Fundamental rules for mapping addresses between XMPP and SIP are 1361 provided in [I-D.ietf-stox-core]. However, chatrooms include a more 1362 specialized, unique identifier for each participant in a room, called 1363 a nickname. Implementations are strongly encouraged to apply the 1364 rules for preparation and comparison of nicknames specified in 1365 [I-D.ietf-precis-nickname]. 1367 In addition to nicknames, some groupchat implementations also include 1368 display names (which might or might not be different from users' 1369 nicknames). A display name need not be unique within the context of 1370 a room but instead simply provides a user-friendly name for a 1371 participant. 1373 In SIP, the nickname is the value of the XCON 'nickname' attribute of 1374 the element [RFC6501] and the display name is the XML 1375 character data of the conference-info element 1376 [RFC4575]. In XMPP, the nickname is the value of the resourcepart of 1377 the occupant JID [XEP-0045] and the display name is the XML character 1378 data of the element [XEP-0172]. 1380 In practice, the element is treated as canonical in 1381 SIP implementations, and the element is rarely used in XMPP 1382 implementations. Therefore, for display purposes SIP implementations 1383 ought to use the element (not the XCON 'nickname' 1384 attribute) and XMPP implementations ought to use the resourcepart of 1385 the occupant JID (not the character data of the element). 1387 If there is a conflict between the SIP nickname and the XMPP 1388 nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is responsible for 1389 adjusting the nickname to avoid the conflict and for informing the 1390 SIP or XMPP client of the unique nickname used to join the chatroom. 1392 6. IANA Considerations 1394 This document requests no actions of the IANA. 1396 7. Security Considerations 1398 The security considerations of [RFC3261], [RFC4975], [RFC6120], 1399 [I-D.ietf-stox-core], [I-D.ietf-simple-chat], and [XEP-0045] apply. 1401 8. References 1403 8.1. Normative References 1405 [I-D.ietf-precis-nickname] 1406 Saint-Andre, P., "Preparation and Comparison of 1407 Nicknames", draft-ietf-precis-nickname-06 (work in 1408 progress), July 2013. 1410 [I-D.ietf-simple-chat] 1411 Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- 1412 party Instant Message (IM) Sessions Using the Message 1413 Session Relay Protocol (MSRP)", draft-ietf-simple-chat-18 1414 (work in progress), January 2013. 1416 [I-D.ietf-stox-core] 1417 Saint-Andre, P., Houri, A., and J. Hildebrand, 1418 "Interworking between the Session Initiation Protocol 1419 (SIP) and the Extensible Messaging and Presence Protocol 1420 (XMPP): Core", draft-ietf-stox-core-05 (work in progress), 1421 September 2013. 1423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1424 Requirement Levels", BCP 14, RFC 2119, March 1997. 1426 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1427 A., Peterson, J., Sparks, R., Handley, M., and E. 1428 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1429 June 2002. 1431 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 1432 (SIP) Call Control - Conferencing for User Agents", 1433 RFC 4579, August 2006. 1435 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1436 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1438 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1439 Protocol (XMPP): Core", RFC 6120, March 2011. 1441 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1442 Protocol (XMPP): Instant Messaging and Presence", 1443 RFC 6121, March 2011. 1445 [XEP-0045] 1446 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 1447 July 2008. 1449 8.2. Informative References 1451 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1452 Method", RFC 3515, April 2003. 1454 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1455 Description Protocol", RFC 4566, July 2006. 1457 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1458 Initiation Protocol (SIP) Event Package for Conference 1459 State", RFC 4575, August 2006. 1461 [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 1462 "Conference Information Data Model for Centralized 1463 Conferencing (XCON)", RFC 6501, March 2012. 1465 [XEP-0172] 1466 Saint-Andre, P. and V. Mercier, "User Nickname", XSF 1467 XEP 0172, March 2012. 1469 [XEP-0249] 1470 Saint-Andre, P., "Direct MUC Invitations", XSF XEP 0249, 1471 September 2011. 1473 Appendix A. Acknowledgements 1475 Special thanks to Fabio Forno for his co-authorship of an early 1476 version of this document. 1478 Thanks also to Philipp Hancke for his detailed feedback. 1480 Some text in this document was borrowed from [I-D.ietf-stox-core] and 1481 from [XEP-0045]. 1483 Authors' Addresses 1485 Peter Saint-Andre 1486 Cisco Systems, Inc. 1487 1899 Wynkoop Street, Suite 600 1488 Denver, CO 80202 1489 USA 1491 Phone: +1-303-308-3282 1492 Email: psaintan@cisco.com 1494 Saul Ibarra Corretge 1495 AG Projects 1496 Dr. Leijdsstraat 92 1497 Haarlem 2021RK 1498 The Netherlands 1500 Email: saul@ag-projects.com 1502 Salvatore Loreto 1503 Ericsson 1504 Hirsalantie 11 1505 Jorvas 02420 1506 Finland 1508 Email: Salvatore.Loreto@ericsson.com