idnits 2.17.1 draft-ivov-xmpp-cusax-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 4435 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MSRP' is mentioned on line 107, but not defined == Missing Reference: 'XCAP' is mentioned on line 107, but not defined == Missing Reference: 'VCARD' is mentioned on line 188, but not defined == Unused Reference: 'RFC3264' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'RFC3489' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'RFC3711' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'RFC4474' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC4787' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'RFC5245' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC5751' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'RFC5766' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC5853' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'RFC6189' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'XEP-0177' is defined on line 310, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 8 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: BCP E. Marocco, Ed. 5 Expires: September 6, 2012 Telecom Italia 6 March 5, 2012 8 Combined Use of the Session Initiation Protocol (SIP) and the 9 eXtensible Messaging and Presence Protocol (CUSAX) 10 draft-ivov-xmpp-cusax-00 12 Abstract 14 This document describes current practices for combined use of the 15 Session Initiation Protocol (SIP) and the eXtensible Messaging and 16 Presence Protocol (XMPP). Such practices aim to provide a single 17 fully featured real-time communication service by using complimenting 18 subsets of features from each of the protocols. Typically such 19 subsets would include telephony oriented from SIP and instant 20 messaging and presence capabilities from XMPP. This specification 21 does not define any new protocols or syntax for neither SIP nor XMPP. 22 However, implementing it may require modifying or at least 23 reconfiguring existing client and server-side software. Also, it is 24 not the purpose of this document to make recommendations as to 25 whether or not such combined us should be preferred to the mechanisms 26 provided natively by each protocol like for example SIP's SIMPLE or 27 XMPP's Jingle. It merely aims to provide guidance to those who are 28 interested in such a combined use. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 6, 2012. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Client Bootstrap . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Historically SIP [RFC3261] and XMPP [RFC6120] have often been 77 implemented and deployed with different purposes: from its very start 78 SIP's primary goal has been to provide a means of conducting 79 "Internet telephone calls". XMPP on the other hand, has from its 80 Jabber days been mostly used for its instant messaging and presence 81 capabilities. 83 For various reasons, these trends have continued through the years 84 even after each of the protocols had been equipped to provide the 85 features it was initially lacking. 87 Today, in the context of the SIMPLE working group, the IETF has 88 defined a number of protocols and protocol extensions that not only 89 allow for SIP to be used for regular instant messaging and presence 90 but that also provide mechanisms for elaborated features such as 91 multi-user chats, server-stored contact lists, file transfer and 92 others. 94 Similarly, the XMPP community and the XMPP Standards Foundation have 95 worked on defining a number of XMPP Extension Protocols (XEPs) that 96 provide XMPP implementations with the means of establishing end-to- 97 end sessions. These extensions are often jointly referred to as 98 Jingle and their arguably most popular use case are audio and video 99 calls. 101 Yet, despite these advances SIP remains the protocol of choice for 102 telephony-like services, especially in enterprises where users are 103 accustomed to features such as voice mail, call park, call queues, 104 conference bridges and many others that are rarely (if at all) 105 available in Jingle servers. XMPP implementations on the other hand, 106 greatly outnumber and outperform those available for protocols 107 recommended by SIMPLE, such as [MSRP] and [XCAP]. 109 For these reasons in a number of cases, adopters may find themselves 110 needing a set of features that are not offered by any single-protocol 111 solution but that separately exist in SIP and XMPP products. The 112 idea of seamlessly using both protocols together would hence often 113 appeal to service providers. 115 Most often such combined use would employ SIP exclusively for audio, 116 video and telephony services and it would rely on XMPP for anything 117 else varying from chat, roster management and presence to exchanging 118 files. 120 This document explains how the above could be achieved with a minimum 121 amount of modifications on existing software while providing an 122 optimal user experience. It tries to cover points such as server 123 discovery, determining a SIP AOR while using XMPP and an XMPP JID 124 from incoming SIP requests. Most of the text here pertains to client 125 behavior but it also recommends certain server-side configurations. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Client Bootstrap 135 One of the main problems of using two distinct protocols when 136 providing one service is how it affects usability. E-mail services 137 for example have long been affected by the mixed use of SMTP on for 138 outgoing mail and POP3 and IMAP for incoming, making it rather 139 complicated for inexperienced users to configure a mail client and 140 start using it with a new service. As a result mailing list services 141 often need to provide configuration instructions for various mail 142 clients. Client developers and communications device manufacturers 143 on the other hand often ship with a number of wizards that allow to 144 easily set up a new account for a number of popular e-mail services. 145 While this may improve the situation to some extent, user experience 146 is still clearly sub-optimal. 148 While it should be possible for CUSAX users to manually configure 149 their separate SIP and XMPP accounts, it is RECOMMENDED that dual 150 stack SIP/XMPP clients provide means of online provisioning. While 151 the specifics of such mechanisms are not in the scope of this 152 specification, they should make it possible for service providers to 153 remotely configure the clients based on minimal user input (e.g. user 154 id and password). 156 Given that many of the features that CUSAX would privilege in one 157 protocol would also be available in the other, clients should make it 158 possible for such features to be disabled for a specific account. 159 Specifically it is RECOMMENDED that clients allow for audio/video 160 calling features to be disabled for XMPP accounts. Additionally 161 instant messaging and presence features MAY also be made optional for 162 SIP accounts. 164 The main advantage of the above would be that clients would be able 165 to continue to function properly and use the complete feature set of 166 stand-alone SIP and XMPP accounts. 168 Once client bootstrap has completed, clients SHOULD log independently 169 to the SIP and XMPP accounts that make up the CUSAX service and 170 should maintain both these connections. In order to improve user 171 experience, when reporting connection status clients may also wish to 172 present the CUSAX XMPP connection as an "instant messaging" or a 173 "chat" account. Similarly they could also depict the SIP CUSAX 174 connection as a "Voice and Video" or a "Telephony" connection. The 175 exact naming is of course entirely up to implementors. The point is 176 that such presentation could help users better understand why they 177 are being shown two different connections for a single service. It 178 could even alleviate especially situations where one of these 179 connections is disrupted while the other one is successfully 180 maintained. 182 4. Operation 184 Once a CUSAX client has been provisioned/configured to connect to the 185 corresponding SIP and XMPP services it would proceed by retrieving 186 its XMPP roster. In order for CUSAX to function properly, XMPP 187 service administrators should make sure that at least one of the 188 [VCARD] "tel" fields for each contact is properly populated with a 189 SIP URI or a phone number. There are no limitations as to the form 190 of that number (e.g. it does not need to respect any equivalence with 191 the XMPP JID). It SHOULD however be reachable through the SIP 192 counterpart of this CUSAX service. 194 In order to make sure that the above is always respected, service 195 maintainers MAY prevent clients (and hence users) from modifying the 196 VCARD "tel" fields or they MAY apply some form of validation before 197 recording changes. 199 When rendering the XMPP roaster CUSAX clients should make sure that 200 users are presented with a "Call" option for each roster entry that 201 has a properly set "tel" field even if calling has been disabled for 202 that particular XMPP account. The usefulness of such a feature is 203 not limited to CUSAX. After all, numbers are entered in VCARDs in 204 order to be dialed and called. Hence, as long as an XMPP client is 205 equipped with accounts that have calling features it may wish to 206 present the user with the option of using these accounts to reach 207 numbers from an XMPP VCARD. In order to improve usability, in cases 208 where clients are provisioned with only a single telephony capable 209 account they SHOULD do so immediately upon user request without 210 asking for confirmation. This way CUSAX users whose only account 211 with calling capabilities would often be the SIP part of their 212 service would be having better user experience. If on the other 213 hand, the CUSAX client is aware of multiple telephony-capable 214 accounts, it SHOULD present the user with the choice of reaching the 215 phone number through any of them (including the source XMPP account 216 where the VCARD was obtained) in order to guarantee proper operation 217 for XMPP accounts that are not part of a CUSAX deployment. 219 The client should use XMPP for all other forms of communication with 220 the contacts from its roster so it should and this should occur 221 naturally given that they were retrieved through XMPP. 223 When receiving SIP calls, clients may wish to determine the identity 224 of the caller and bind it to a roster entry so that users could 225 revert to chatting or other forms of communication that require XMPP. 226 To do so clients could search their roster for an entry whose VCARD 227 has a "tel" field matching the originator of the call. 229 An alternate mechanism would be for CUSAX clients to add to their SIP 230 invite requests a contact header containing their XMPP JID, but at 231 this point we are not really sure if that's ' such a good idea. 232 (After all Contact headers carry URIs and JIDs are not URIs). 234 5. Security Considerations 236 TBD 238 6. Acknowledgements 240 This draft is inspired by work from Markus Isomaki and Simo 241 Veikkolainen. 243 7. References 245 7.1. Normative References 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 250 7.2. Informative References 252 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 253 A., Peterson, J., Sparks, R., Handley, M., and E. 254 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 255 June 2002. 257 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 258 with Session Description Protocol (SDP)", RFC 3264, 259 June 2002. 261 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 262 "STUN - Simple Traversal of User Datagram Protocol (UDP) 263 Through Network Address Translators (NATs)", RFC 3489, 264 March 2003. 266 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 267 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 268 RFC 3711, March 2004. 270 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 271 Authenticated Identity Management in the Session 272 Initiation Protocol (SIP)", RFC 4474, August 2006. 274 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 275 Description Protocol", RFC 4566, July 2006. 277 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 278 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 279 RFC 4787, January 2007. 281 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 282 (ICE): A Protocol for Network Address Translator (NAT) 283 Traversal for Offer/Answer Protocols", RFC 5245, 284 April 2010. 286 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 287 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 288 October 2008. 290 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 291 Mail Extensions (S/MIME) Version 3.2 Message 292 Specification", RFC 5751, January 2010. 294 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 295 Relays around NAT (TURN): Relay Extensions to Session 296 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 298 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 299 A., and M. Bhatia, "Requirements from Session Initiation 300 Protocol (SIP) Session Border Control (SBC) Deployments", 301 RFC 5853, April 2010. 303 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 304 Protocol (XMPP): Core", RFC 6120, March 2011. 306 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 307 Path Key Agreement for Unicast Secure RTP", RFC 6189, 308 April 2011. 310 [XEP-0177] 311 Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan, 312 "XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177, 313 December 2009. 315 Authors' Addresses 317 Emil Ivov 318 Jitsi 319 Strasbourg 67000 320 France 322 Email: emcho@jitsi.org 324 Enrico Marocco (editor) 325 Telecom Italia 326 Via G. Reiss Romoli, 274 327 Turin 10148 328 Italy 330 Email: enrico.marocco@telecomitalia.it