idnits 2.17.1 draft-ivov-xmpp-cusax-05.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 (May 02, 2013) is 4005 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ivov-grouptextchat-purpose-00 == Outdated reference: A later version (-04) exists of draft-saintandre-impp-call-info-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov 3 Internet-Draft Jitsi 4 Intended status: Informational P. Saint-Andre 5 Expires: November 03, 2013 Cisco Systems, Inc. 6 E. Marocco 7 Telecom Italia 8 May 02, 2013 10 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP) 12 draft-ivov-xmpp-cusax-05 14 Abstract 16 This document describes suggested practices for combined use of the 17 Session Initiation Protocol (SIP) and the Extensible Messaging and 18 Presence Protocol (XMPP). Such practices aim to provide a single 19 fully featured real-time communication service by using complementary 20 subsets of features from each of the protocols. Typically such 21 subsets would include telephony capabilities from SIP and instant 22 messaging and presence capabilities from XMPP. This specification 23 does not define any new protocols or syntax for either SIP or XMPP. 24 However, implementing it may require modifying or at least 25 reconfiguring existing client and server-side software. Also, it is 26 not the purpose of this document to make recommendations as to 27 whether or not such combined use should be preferred to the 28 mechanisms provided natively by each protocol (for example, SIP's 29 SIMPLE or XMPP's Jingle). It merely aims to provide guidance to 30 those who are interested in such a combined use. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 03, 2013. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Client Bootstrap . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Server-Side Setup . . . . . . . . . . . . . . . . . . . . 7 70 3.2. Client-Side Discovery and Usability . . . . . . . . . . . 7 71 3.3. Indicating a Relation Between SIP and XMPP Accounts . . . 8 72 3.4. Matching Incoming SIP Calls to XMPP JIDs . . . . . . . . 9 73 4. Multi-Party Interactions . . . . . . . . . . . . . . . . . . 9 74 5. Federation . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 8. Informative References . . . . . . . . . . . . . . . . . . . 12 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Historically SIP [RFC3261] and XMPP [RFC6120] have often been 84 implemented and deployed with different purposes: from its very start 85 SIP's primary goal has been to provide a means of conducting 86 "Internet telephone calls". XMPP on the other hand, has, from its 87 Jabber days, been mostly used for instant messaging and presence 88 [RFC6121], as well as related services such as groupchat rooms 89 [XEP-0045]. 91 For various reasons, these trends have continued through the years 92 even after each of the protocols had been equipped to provide the 93 features it was initially lacking: 95 o Today, in the context of the SIMPLE working group, the IETF has 96 defined a number of protocols and protocol extensions that not 97 only allow for SIP to be used for regular instant messaging and 98 presence but that also provide mechanisms for elaborated features 99 such as multi-user chats, server-stored contact lists, file 100 transfer and others. 102 o Similarly, the XMPP community and the XMPP Standards Foundation 103 have worked on defining a number of XMPP Extension Protocols 104 (XEPs) that provide XMPP implementations with the means of 105 establishing end-to-end sessions. These extensions are often 106 jointly referred to as Jingle and arguably their most popular use 107 case is audio and video calling. 109 Despite these advances, SIP remains the protocol of choice for 110 telephony-like services, especially in enterprises where users are 111 accustomed to features such as voice mail, call park, call queues, 112 conference bridges and many others that are rarely (if at all) 113 available in Jingle-based software. XMPP implementations, on the 114 other hand, greatly outnumber and outperform those available for 115 instant messaging and presence extensions developed in the SIMPLE WG, 116 such as MSRP [RFC4975] and XCAP [RFC4825]. 118 For these reasons, in a number of cases adopters have found 119 themselves needing a set of features that are not offered by any 120 single-protocol solution but that separately exist in SIP and XMPP 121 products. The idea of seamlessly using both protocols together would 122 hence often appeal to service providers. Most often, such a service 123 would employ SIP exclusively for audio, video, and telephony services 124 and rely on XMPP for anything else varying from chat, contact list 125 management, and presence to whiteboarding and exchanging files. 126 Because these services and clients involve the combined use of SIP 127 and XMPP, we label them "CUSAX" for short. 129 +------------+ +-------------+ 130 | SIP Server | | XMPP Server | 131 +------------+ +-------------+ 132 \ / 133 media \ / instant messaging, 134 signaling \ / presence, etc. 135 \ / 136 +--------------+ 137 | CUSAX Client | 138 +--------------+ 140 Figure 1: Division of Responsibilities 142 This document explains how such hybrid offerings can be achieved with 143 a minimum of modifications to existing software while providing an 144 optimal user experience. It covers server discovery, determining a 145 SIP AOR while using XMPP, and determining an XMPP Jabber Identifier 146 ("JID") from incoming SIP requests. Most of the text here pertains 147 to client behavior but it also recommends certain server-side 148 configurations. 150 Note that this document is focused on coexistence of SIP and XMPP 151 functionality in end-user-oriented clients. By intent it does not 152 define methods for protocol-level mapping between SIP and XMPP, as 153 might be used within a server-side gateway between a SIP network and 154 an XMPP network (a separate series of documents has been produced 155 that defines such mappings). More generally, this document does not 156 describe service policies for inter-domain communication (often 157 called "federation") between service providers (e.g., how a service 158 provider that offers a combined SIP-XMPP service might communicate 159 with a SIP-only or XMPP-only service), nor does it describe the 160 reasons why a service provider might choose SIP or XMPP for various 161 features. 163 This document concentrates on use cases where the SIP services and 164 XMPP services are controlled by one and the same provider, since that 165 assumption greatly simplifies both client implementation and server- 166 side deployment (e.g., a single service provider can enforce common 167 or coordinated policies across both the SIP and XMPP aspects of a 168 CUSAX service, which is not possible if a SIP service is offered by 169 one provider and an XMPP service is offered by another). Since this 170 document is of an informational nature, it is not unreasonable for 171 clients to apply some of the guidelines here even in cases where 172 there is no established relationship between the SIP and the XMPP 173 services (for example, it is reasonable for a client to provide a way 174 for its users to easily start a call to a phone number recorded in a 175 vCard). However, the exact set of rules to follow in such cases is 176 left to application developers. 178 Finally, this document makes a further simplifying assumption by 179 discussing only the use of a single client, not use of and 180 coordination among multiple endpoints controlled by the same user 181 (e.g., user agents running simultaneously on a laptop computer, 182 tablet, and mobile phone). 184 2. Client Bootstrap 186 One of the main problems of using two distinct protocols when 187 providing one service is the impact on usability. Email services, 188 for example, have long been affected by the mixed use of SMTP for 189 outgoing mail and POP3 or IMAP for incoming mail. Although standard 190 service discovery methods (such as the proper DNS records) make it 191 possible for a user agent to locate the right host(s) at which to 192 connect, they do not provide the kind of detailed information that is 193 needed to actually configure the user agent for use with the service. 194 As a result, it is rather complicated for inexperienced users to 195 configure a mail client and start using it with a new service, and 196 Internet service providers often need to provide configuration 197 instructions for various mail clients. Client developers and 198 communication device manufacturers on the other hand often ship with 199 a number of wizards that enable users to easily set up a new account 200 for a number of popular email services. While this may improve the 201 situation to some extent, the user experience is still clearly sub- 202 optimal. 204 While it should be possible for CUSAX users to manually configure 205 their separate SIP and XMPP accounts, dual-stack SIP/XMPP clients 206 ought to provide means of online provisioning, typically by means of 207 a web-based service at an HTTP URI. While the specifics of such 208 mechanisms are outside the scope of this specification, they should 209 make it possible for a service provider to remotely configure the 210 clients based on minimal user input (e.g., only a user ID and 211 password). 213 Because many of the features that a CUSAX client would privilege in 214 one protocol would also be available in the other, clients should 215 make it possible for such features to be disabled for a specific 216 account. In particular, it is suggested that clients allow for audio 217 and video calling features to be disabled for XMPP accounts, and that 218 instant messaging and presence features should also be made optional 219 for SIP accounts. 221 The main advantage of this approach is that clients would be able to 222 continue to function properly and use the complete feature set of 223 standalone SIP and XMPP accounts. 225 Once clients have been provisioned, they need to independently log 226 into the SIP and XMPP accounts that make up the CUSAX "service" and 227 then maintain both these connections as displayed in Figure 2. 229 +--------------+ 230 | Provisioning |-----------+ 231 | Server | | 232 +--------------+ v 233 | +----------------+ 234 | | vCard Storage/ | 235 | | User Directory | 236 | +----------------+ 237 | / \ 238 | +------------+ +-------------+ 239 | | SIP Server | | XMPP Server | 240 | +------------+ +-------------+ 241 | \ / 242 | media \ / instant messaging, 243 | signaling \ / presence, etc. 244 | \ / 245 | +--------------+ 246 +---------------| CUSAX Client | 247 +--------------+ 249 Figure 2: Example Deployment 251 In order to improve the user experience, when reporting connection 252 status clients may also wish to present the XMPP connection as an 253 "instant messaging" or a "chat" account. Similarly they could also 254 depict the SIP connection as a "Voice and Video" or a "Telephony" 255 connection. The exact naming is of course entirely up to 256 implementers. The point is that, in cases where SIP and XMPP are 257 components of a service offered by a single provider, such 258 presentation could help users better understand why they are being 259 shown two different connections for what they perceive as a single 260 service. It could alleviate especially situations where one of these 261 connections is disrupted while the other one is still active. 262 Naturally, the developers of a CUSAX client or the providers of a 263 CUSAX service might decide not to accept such situations and force a 264 client to completely disconnect unless both aspects are successfully 265 connected. 267 Clients may also choose to delay their XMPP connection until they 268 have been successfully registered on SIP. This would help avoid the 269 situation where a user appears online to its contacts but calling it 270 would fail because their clients is still connecting to the SIP 271 aspect of their CUSAX service. 273 3. Operation 275 Once a CUSAX client has been provisioned and authorized to connect to 276 the corresponding SIP and XMPP services it would proceed by 277 retrieving its XMPP roster. 279 The client should use XMPP for all forms of communication with the 280 contacts from this roster, which will occur naturally because they 281 were retrieved through XMPP. Audio/video features however, are 282 disabled in the XMPP stack, so any form of communication based on 283 these features (e.g. direct calls, conferences, desktop streaming, 284 etc.) will happen over SIP. The rest of this section describes 285 deployment, discovery, usability and linking semantics that allow 286 CUSAX clients to fall back and seamlessly use SIP for these features. 288 3.1. Server-Side Setup 290 In order for CUSAX to function properly, XMPP service administrators 291 should make sure that at least one of the vCard [RFC6350] "tel" 292 fields for each contact is properly populated with a SIP URI or a 293 phone number when an XMPP protocol for vCard storage is used (e.g., 294 [XEP-0054] or [XEP-0292]). There are no limitations as to the form 295 of that number. For example while it is desirable to maintain a 296 certain consistency between SIP AORs and XMPP JIDs, that is by no 297 means required. It is quite important however that the phone number 298 or SIP AOR stored in the vCard be reachable through the SIP aspect of 299 this CUSAX service. 301 Administrators may also choose to include the "video" tel type 302 defined in [RFC6350] for accounts that would be capable of handling 303 video communication. 305 To ensure that the foregoing approach is always respected, service 306 providers might consider (1) preventing clients (and hence users) 307 from modifying the vCard "tel" fields or (2) applying some form of 308 validation before storing changes. Of course such validation would 309 be feasible mostly in cases where a single provider controls both the 310 XMPP and the SIP service since such providers would "know" (e.g., 311 based on use of a common user database for both services) what SIP 312 AOR corresponds to a given XMPP user (as indicated in Figure 2). 314 3.2. Client-Side Discovery and Usability 316 When rendering the roster for a particular XMPP account CUSAX clients 317 should make sure that users are presented with a "Call" option for 318 each roster entry that has a properly set "tel" field. This is the 319 case even if calling features have been disabled for that particular 320 XMPP account, as advised by this document. The usefulness of such a 321 feature is not limited to CUSAX. After all, numbers are entered in 322 vCards in order to be dialed and called. Hence, as long as an XMPP 323 client has any means of conducting a call it may wish to make it 324 possible for the user to easily dial any numbers that it learned 325 through whatever means. 327 Clients that have separate triggers (buttons) for audio and video 328 calls may choose to use the presence or absence of the "video" tel 329 type defined in [RFC6350] and enable or disable the possibility for 330 starting video calls accordingly. 332 In addition to discovering phone numbers from vCards, clients may 333 also check for alternative communication methods as advertised in 334 XMPP presence broadcasts and Personal Eventing Protocol nodes as 335 described in XEP-0152: Reachability Addresses [XEP-0152]. However, 336 these indications are merely hints, and a receiving client ought not 337 associate a SIP address and an XMPP address unless it has some way to 338 verify the association (e.g., the vCard of the XMPP account lists the 339 SIP address and the vCard of the SIP account lists the XMPP address, 340 or the association is made explicit in a record provided by a trusted 341 directory). Alternatively or in cases where vCard or directory data 342 is not available, a CUSAX client could take the user's own address 343 book as the canonical source for contact addresses. 345 3.3. Indicating a Relation Between SIP and XMPP Accounts 347 In order to improve usability, in cases where clients are provisioned 348 with only a single telephony-capable account they ought to initiate 349 calls immediately upon user request without asking users to indicate 350 an account that the call should go through. This way CUSAX users 351 (whose only account with calling capabilities is usually the SIP part 352 of their service) would have a better experience, since from the 353 user's perspective calls "just work at the click of a button". 355 In some cases however, clients will be configured with more than the 356 two XMPP and SIP accounts provisioned by the CUSAX provider. Users 357 are likely to add additional stand-alone XMPP or SIP accounts (or 358 accounts for other communications protocols), any of which might have 359 both telephony and instant messaging capabilities. Such situations 360 can introduce additional ambiguity since all of the telephony-capable 361 accounts could be used for calling the numbers the client has learned 362 from the vCards. 364 To avoid such confusion, client implementers and CUSAX service 365 providers may choose to indicate the existence of a special 366 relationship between the SIP and XMPP accounts of a CUSAX service. 367 For example, let's say that Alice's service provider has opened both 368 an XMPP account and a SIP account for her. During or after 369 provisioning, her client could indicate that alice@xmpp.example.com 370 has a CUSAX relation to alice@sip.example.com (i.e., that they are 371 two aspects of the same service). This way whenever Alice triggers a 372 call to a contact in her XMPP roster, the client would preferentially 373 initiate this call through her example.com SIP account even if other 374 possibilities exist (such as the XMPP account where the vCard was 375 obtained or a SIP account with another provider). 377 If, on the other hand, no relationship has been configured or 378 discovered between a SIP account and an XMPP account, and the client 379 is aware of multiple telephony-capable accounts, it ought to present 380 the user with the choice of reaching the contact through any of those 381 accounts. This includes the source XMPP account where the vCard was 382 obtained (in case its telephony capabilities are not disabled through 383 configuration or provisioning), in order to guarantee proper 384 operation for XMPP accounts that are not part of a CUSAX deployment. 386 3.4. Matching Incoming SIP Calls to XMPP JIDs 388 When receiving SIP calls, clients may wish to determine the identity 389 of the caller and a corresponding XMPP roster entry so that users 390 could revert to chatting or other forms of communication that require 391 XMPP. To do so clients could search their roster for an entry whose 392 vCard has a "tel" field matching the originator of the call. 394 In addition, in order to avoid the effort of iterating over an entire 395 roster and retrieving all vCards, CUSAX clients may use a SIP Call- 396 Info header whose 'purpose' header field parameter has a value of 397 "impp" as described in [I-D.saintandre-impp-call-info]. An example 398 follows. 400 Call-Info: ;purpose=impp 402 Note that the information from the Call-Info header should only be 403 used as a cue: the actual AOR-to-JID binding would still need to be 404 confirmed by a vCard entry or through some other trusted means (such 405 as an enterprise directory). If this confirmation succeeds the 406 client would not need to search the entire roster and retrieve all 407 vCards. Not performing the check might enable any caller (including 408 malicious ones) to employ someone else's identity and perform various 409 scams or Man-in-the-Middle attacks. 411 4. Multi-Party Interactions 413 CUSAX clients that support the SIP conferencing framework [RFC4353] 414 can detect when a call they are participating in is actually a 415 conference and can then subscribe for conference state updates as per 416 [RFC4575]. A regular SIP user agent would also use the same 417 conference URI for text communication with the Message Session Relay 418 Protocol (MSRP). However, given that SIP's instant messaging 419 capabilities would normally be disabled (or simply not supported) in 420 CUSAX deployments, an XMPP Multi-User Chat (MUC) [XEP-0045] 421 associated with the conference can be announced/discovered through 422 bearing the "grouptextchat" purpose 423 [I-D.ivov-grouptextchat-purpose]. Similarly, an XMPP MUC can 424 advertise the SIP URI of an associated service for audio/video 425 interactions using the 'audio-video-uri' field of the "muc#roominfo" 426 data form [XEP-0004] to include extended information [XEP-0128] about 427 the MUC room within XMPP service discovery [XEP-0030]; see [XEP-0045] 428 for an example. 430 Once a CUSAX client joins the MUC associated with a particular call 431 it should not rely on any synchronization between the two. Both the 432 SIP conference and the XMPP MUC would function independently, each 433 issuing and delivering its own state updates. It is hence possible 434 that that certain peers would temporarily or permanently be reachable 435 in only one of the two conferences. This would typically be the case 436 with single-stack clients that have only joined the SIP call or the 437 XMPP MUC. It is therefore important for CUSAX clients to provide a 438 clear indication to users as to the level of participation of the 439 various participants. In other words, a user needs to be able to 440 easily understand whether a certain participant can receive text 441 messages, audio/video, or both. 443 Of course, tighter integration between the XMPP MUC and the SIP 444 conference is also possible. Permissions, roles, kicks and bans that 445 are granted and performed in the MUC can easily be imitated by the 446 conference focus/mixer into the SIP call. If for example, a certain 447 MUC member is muted, the conference mixer can choose to also apply 448 the mute on the media stream corresponding to that participant. The 449 details and exact level of such integration is of course entirely up 450 to implementers and service providers. 452 The approach above describes one relatively lightweight possibility 453 of combining SIP and XMPP multi-party interaction semantics without 454 requiring tight integration between the two. As with the rest of 455 this specification, this approach is by no means normative. 456 Implementation and future specifications may define other methods or 457 provide other suggestions for improving the Unified Communications 458 user experience in cases of multi-user chats in conference calling. 460 5. Federation 462 In theory there are no technical reasons why federation would require 463 special behaviour from CUSAX clients. However, it is worth noting 464 that differences in administration policies may sometimes lead to 465 potentially confusing user experiences. 467 For example, let's say atlanta.example.com observes the CUSAX 468 policies described in this specification. All XMPP users at 469 atlanta.example.com are hence configured to have vCards that match 470 their SIP identities. Alice is therefore used to making free, high- 471 quality SIP calls to all the people in her roster. Alice can also 472 make calls to the PSTN by simply dialing numbers. She may even be 473 used to these calls being billed to her online account so she would 474 careful about how long they last. This is not a problem for her 475 since she can easily distinguish between a free SIP call (one that 476 she made by calling one her roster entries) from a paid PSTN call 477 that she dialed as a number. 479 Then Alice adds xmpp:bob@biloxi.example.com. The Biloxi domain only 480 has an XMPP service. There is no SIP server and Bob uses a regular, 481 XMPP-only client. Bob has however added his mobile number to his 482 vCard in order to make it easily accessible to his contacts. Alice's 483 client would pick up this number and make it possible for Alice to 484 start a call to Bob's mobile phone number. 486 This could be a problem because, other than the fact that Bob's 487 address is from a different domain, Alice would have no obvious and 488 straightforward cues telling her that this is in fact a call to the 489 PSTN. In addition to the potentially lower audio quality, Alice may 490 also end up incurring unexpected charges for such calls. 492 In order to avoid such issues, providers maintaining a CUSAX service 493 for the users in their domain may choose to provide additional cues 494 (e.g., a user interface warning or an an audio tone or message) 495 indicating that a call would incur charges. 497 A slightly less disturbing scenario, where a SIP service might only 498 allow communication with intra-domain numbers, would simply prevent 499 Alice from establishing a call with Bob's mobile. Providers should 500 hence make sure that calls to extra-domain numbers are flagged with 501 an appropriate audio or textual warning. 503 6. Security Considerations 505 Use of the same user agent with two different accounts providing 506 complementary features introduces the possibility of mismatches 507 between the security profiles of those accounts or features. For 508 example, the SIP aspect and XMPP aspect of the CUSAX service might 509 offer different authentication options (e.g., digest authentication 510 for SIP as specified in [RFC3261] and SCRAM authentication [RFC5802] 511 for XMPP as specified in [RFC6120]). Similarly, a CUSAX client might 512 successfully negotiate Transport Layer Security (TLS) [RFC5246] when 513 connecting to the XMPP aspect of the service but not when connecting 514 to the SIP aspect. Such mismatches could introduce the possibility 515 of downgrade attacks. User agent developers and service providers 516 ought to ensure that such mismatches are avoided as much as possible. 518 Refer to the specifications for the relevant SIP and XMPP features 519 for detailed security considerations applying to each "stack" in a 520 CUSAX client. 522 7. IANA Considerations 524 This document has no actions for the IANA. 526 8. Informative References 528 [I-D.ivov-grouptextchat-purpose] 529 Ivov, E., "A Group Text Chat Purpose for Conference and 530 Service URIs in the Session Initiation Protocol (SIP) 531 Event Package for Conference State", draft-ivov- 532 grouptextchat-purpose-00 (work in progress), April 2013. 534 [I-D.saintandre-impp-call-info] 535 Saint-Andre, P., "Instant Messaging and Presence Purpose 536 for the Call-Info Header in the Session Initiation 537 Protocol (SIP)", draft-saintandre-impp-call-info-02 (work 538 in progress), April 2013. 540 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 541 A., Peterson, J., Sparks, R., Handley, M., and E. 542 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 543 June 2002. 545 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 546 Session Initiation Protocol (SIP)", RFC 4353, February 547 2006. 549 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 550 Initiation Protocol (SIP) Event Package for Conference 551 State", RFC 4575, August 2006. 553 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 554 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 556 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 557 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 559 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 560 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 562 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 563 "Salted Challenge Response Authentication Mechanism 564 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 566 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 567 Protocol (XMPP): Core", RFC 6120, March 2011. 569 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 570 Protocol (XMPP): Instant Messaging and Presence", RFC 571 6121, March 2011. 573 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 574 August 2011. 576 [XEP-0004] 577 Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and 578 P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007. 580 [XEP-0030] 581 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 582 Andre, "Service Discovery", XSF XEP 0030, June 2008. 584 [XEP-0045] 585 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 586 2012. 588 [XEP-0054] 589 Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008. 591 [XEP-0128] 592 Saint-Andre, P., "Service Discovery Extensions", XSF XEP 593 0128, October 2004. 595 [XEP-0152] 596 Hildebrand, J. and P. Saint-Andre, "XEP-0152: Reachability 597 Addresses", XEP XEP-0152, February 2013. 599 [XEP-0292] 600 Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 601 0292, October 2011. 603 Appendix A. Acknowledgements 605 This draft is inspired by the "SIXPAC" work of Markus Isomaki and 606 Simo Veikkolainen. Markus also provided various suggestions for 607 improving the document. 609 The authors would also like to thank the following persons for their 610 reviews and suggestions: Sebastien Couture, Richard Brady, Olivier 611 Crete, Aaron Evans, Kevin Gallagher, Adrian Georgescu, Saul Ibarra 612 Corretge, David Laban, Murray Mar, Daniel Pocock, Travis Reitter, and 613 Gonzalo Salgueiro. 615 Authors' Addresses 617 Emil Ivov 618 Jitsi 619 Strasbourg 67000 620 France 622 Phone: +33-672-811-555 623 Email: emcho@jitsi.org 625 Peter Saint-Andre 626 Cisco Systems, Inc. 627 1899 Wynkoop Street, Suite 600 628 Denver, CO 80202 629 USA 631 Phone: +1-303-308-3282 632 Email: psaintan@cisco.com 634 Enrico Marocco 635 Telecom Italia 636 Via G. Reiss Romoli, 274 637 Turin 10148 638 Italy 640 Email: enrico.marocco@telecomitalia.it