idnits 2.17.1 draft-saintandre-sip-xmpp-im-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 5528 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-saintandre-sip-xmpp-core-01 ** Obsolete normative reference: RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) ** Obsolete normative reference: RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) Summary: 4 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 P. Saint-Andre 3 Internet-Draft Cisco 4 Intended status: Informational A. Houri 5 Expires: September 9, 2009 IBM 6 J. Hildebrand 7 Cisco 8 March 8, 2009 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging 12 draft-saintandre-sip-xmpp-im-01 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 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 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 9, 2009. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document defines a bi-directional protocol mapping for the 60 exchange of single instant messages between the Session Initiation 61 Protocol (SIP) and the Extensible Messaging and Presence Protocol 62 (XMPP). 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Instant Messages . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.3. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Content Types . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 75 5.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 In order to help ensure interworking between instant messaging 81 systems that conform to the requirements of RFC 2779 [IMP-REQS], it 82 is important to clearly define protocol mappings between such 83 systems. Within the IETF, work has proceeded on two instant 84 messaging technologies: 86 o Various extensions to the Session Initiation Protocol ([SIP]) for 87 instant messaging, as developed within the SIP for Instant 88 Messaging and Presence Leveraging Extensions (SIMPLE) Working 89 Group; the relevant specification for instant messaging is 90 [SIP-IM] 91 o The Extensible Messaging and Presence Protocol (XMPP), which 92 consists of a formalization of the core XML streaming protocols 93 developed originally by the Jabber open-source community; the 94 relevant specifications are [XMPP] for the XML streaming layer and 95 [XMPP-IM] for basic presence and instant messaging extensions 97 One approach to helping ensure interworking between these protocols 98 is to map each protocol to the abstract semantics described in 99 [CPIM]; that is the approach taken by [SIMPLE-CPIM] and [XMPP-CPIM]. 100 The approach taken in this document is to directly map semantics from 101 one protocol to another (i.e., from SIP/SIMPLE to XMPP and vice- 102 versa). 104 The architectural assumptions underlying such direct mappings are 105 provided in [SIP-XMPP], including mapping of addresses and error 106 condisions. The mappings specified in this document cover basic 107 instant messaging functionality, i.e., the exchange of a single 108 instant message between a SIP user and an XMPP user in either 109 direction. Mapping of more advanced functionality is out of scope 110 for this document, but other documents in this "series" cover such 111 topics. 113 Note: The capitalized key words "MUST", "MUST NOT", "REQUIRED", 114 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 115 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 116 interpreted as described in RFC 2119 [TERMS]. 118 2. Instant Messages 120 2.1. Overview 122 Both XMPP and IM-aware SIP systems enable entities (often but not 123 necessarily human users) to send "instant messages" to other 124 entities. The term "instant message" usually refers to messages sent 125 between two entities for delivery in close to real time (rather than 126 messages that are stored and forwarded to the intended recipient upon 127 request). Generally there are three kinds of instant message: 129 o Single messages, which are sent from the sender to the recipient 130 outside the context of any one-to-one chat session or multi-user 131 text conference. 132 o Chat messages, which are sent from the sender to the recipient in 133 the context of a "messaging session" between the two entities. 134 o Groupchat messages, which are sent from a sender to multiple 135 recipients in the context of a text conference. 137 This document covers single messages only, since they form the 138 "lowest common denominator" for instant messaging on the Internet. 139 It is likely that future documents will address one-to-one chat 140 sessions and multi-user chat. 142 Instant messaging using XMPP message stanzas of type "normal" is 143 specified in [XMPP-IM]. Instant messaging using SIP requests of type 144 MESSAGE (often called "page-mode" messaging) is specified in 145 [SIP-IM]. 147 As described in [XMPP-IM], a single instant message is an XML 148 stanza of type "normal" sent over an XML stream (since 149 "normal" is the default for the 'type' attribute of the 150 stanza, the attribute is often omitted). In this document we will 151 assume that such a message is sent from an XMPP client to an XMPP 152 server over an XML stream negotiated between the client and the 153 server, and that the client is controlled by a human user (this is a 154 simplifying assumption introduced for explanatory purposes only; the 155 XMPP sender could be a bot-controlled client, a component such as a 156 workflow application, a server, etc.). Continuing the tradition of 157 Shakespeare examples in XMPP documentation, we will say that the XMPP 158 user has an XMPP address of . 160 As described in [SIP-IM], a single instant message is a SIP MESSAGE 161 request sent from a SIP user agent to an intended recipient who is 162 most generally referenced by an Instant Message URI of the form 163 but who may be referenced by a SIP or SIPS URI of 164 the form or Here again we 165 introduce the simplifying assumption that the user agent is 166 controlled by a human user, whom we shall dub . 168 2.2. XMPP to SIP 170 When Juliet wants to send an instant message to Romeo, she interacts 171 with her XMPP client, which generates an XMPP stanza. The 172 syntax of the stanza, including required and optional 173 elements and attributes, is defined in [XMPP-IM]. The following is 174 an example of such a stanza: 176 Example: XMPP user sends message: 178 | 180 | Art thou not Romeo, and a Montague? 181 | 183 Upon receiving such a stanza, the XMPP server to which Juliet has 184 connected either delivers it to a local recipient (if the hostname in 185 the 'to' attribute matches one of the hostnames serviced by the XMPP 186 server) or attempts to route it to the foreign domain that services 187 the hostname in the 'to' attribute. Naturally, in this document we 188 assume that the hostname in the 'to' attribute is an IM-aware SIP 189 service hosted by a separate server. As specified in [XMPP-IM], the 190 XMPP server needs to determine the identity of the foreign domain, 191 which it does by performing one or more [SRV] lookups. For message 192 stanzas, the order of lookups recommended by [XMPP-IM] is to first 193 try the "_xmpp-server" service as specified in [XMPP] and to then try 194 the "_im" service as specified in [IMP-SRV]. Here we assume that the 195 first lookup will fail but that the second lookup will succeed and 196 return a resolution "_im._simple.example.net.", since we have already 197 assumed that the example.net hostname is running a SIP instant 198 messaging service. (Note: The XMPP server may have previously 199 determined that the foreign domain is a SIMPLE server, in which case 200 it would not need to perform the SRV lookups; the caching of such 201 information is a matter of implementation and local service policy, 202 and is therefore out of scope for this document.) 204 Once the XMPP server has determined that the foreign domain is 205 serviced by a SIMPLE server, it must determine how to proceed. We 206 here assume that the XMPP server contains or has available to it an 207 XMPP-SIMPLE gateway. The XMPP server would then deliver the message 208 stanza to the XMPP-SIMPLE gateway. 210 The XMPP-SIMPLE gateway is then responsible for translating the XMPP 211 message stanza into a SIP MESSAGE request from the XMPP user to the 212 SIP user: 214 Example: XMPP user sends message (SIP transformation): 216 | MESSAGE sip:romeo@example.net SIP/2.0 217 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse 218 | Max-Forwards: 70 219 | From: sip:juliet@example.com;tag=49583 220 | To: sip:romeo@example.net 221 | Call-ID: Hr0zny9l3@example.com 222 | CSeq: 1 MESSAGE 223 | Content-Type: text/plain 224 | Content-Length: 35 225 | 226 | Art thou not Romeo, and a Montague? 228 The mapping of XMPP syntax elements to SIP syntax elements SHOULD be 229 as shown in the following table. (Mappings for elements not 230 mentioned are undefined.) 232 Table 4: Message syntax mapping from XMPP to SIP 234 +-----------------------------+--------------------------+ 235 | XMPP Element or Attribute | SIP Header or Contents | 236 +-----------------------------+--------------------------+ 237 | | body of MESSAGE | 238 | | Subject | 239 | | Call-ID | 240 | from | From | 241 | id | (no mapping) | 242 | to | To | 243 | type | (no mapping) | 244 | xml:lang | Content-Language | 245 +-----------------------------+--------------------------+ 247 2.3. SIP to XMPP 249 When Romeo wants to send an instant message to Juliet, he interacts 250 with his SIP user agent, which generates a SIP MESSAGE request. The 251 syntax of the MESSAGE request is defined in [SIP-IM]. The following 252 is an example of such a request: 254 Example: SIP user sends message: 256 | MESSAGE sip:juliet@example.com SIP/2.0 257 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677 258 | Max-Forwards: 70 259 | From: sip:romeo@example.net;tag=38594 260 | To: sip:juliet@example.com 261 | Call-ID: M4spr4vdu@example.net 262 | CSeq: 1 MESSAGE 263 | Content-Type: text/plain 264 | Content-Length: 44 265 | 266 | Neither, fair saint, if either thee dislike. 268 Section 5 of [SIP-IM] stipulates that a SIP User Agent presented with 269 an im: URI should resolve it to a sip: or sips: URI. Therefore we 270 assume that the To header of a request received by a SIMPLE-XMPP 271 gateway will contain a sip: or sips: URI. The gateway SHOULD resolve 272 that address to an im: URI for SIP MESSAGE requests, then follow the 273 rules in [IMP-SRV] regarding the "_im" SRV service for the target 274 domain contained in the To header. If SRV address resolution fails 275 for the "_im" service, the gateway MAY attempt a lookup for the 276 "_xmpp-server" service as specified in [XMPP] or MAY return an error 277 to the sender (the SIP "502 Bad Gateway" error seems most 278 appropriate; see [SIP-XMPP] for details). If SRV address resolution 279 succeeds, the gateway is responsible for translating the request into 280 an XMPP message stanza from the SIP user to the XMPP user and 281 returning a SIP "200 OK" message to the sender: 283 Example: SIP user sends message (XMPP transformation): 285 | 287 | Neither, fair saint, if either thee dislike. 288 | 290 The mapping of SIP syntax elements to XMPP syntax elements SHOULD be 291 as shown in the following table. (Mappings for elements not 292 mentioned in the foregoing table are undefined.) 293 Table 5: Message syntax mapping from SIP to XMPP 295 +--------------------------+-----------------------------+ 296 | SIP Header or Contents | XMPP Element or Attribute | 297 +--------------------------+-----------------------------+ 298 | Call-ID | | 299 | Content-Language | xml:lang | 300 | CSeq | (no mapping) | 301 | From | from | 302 | Subject | | 303 | To | to | 304 | body of MESSAGE | | 305 +--------------------------+-----------------------------+ 307 Note: When transforming SIP page-mode messages, a SIMPLE-XMPP gateway 308 SHOULD specify no XMPP 'type' attribute or a 'type' attribute whose 309 value is "normal" (alternatively, the value of the 'type' attribute 310 MAY be "chat", although it SHOULD NOT be "headline" and MUST NOT be 311 "groupchat"). 313 Note: See the Content Types (Section 3) of this document regarding 314 handling of SIP message bodies that contain content types other than 315 plain text. 317 3. Content Types 319 SIP requests of type MESSAGE may contain essentially any content 320 type. The recommended procedures for SIMPLE-to-XMPP gateways to use 321 in handling these content types are as follows. 323 A SIMPLE-to-XMPP gateway MUST process SIP messages that contain 324 message bodies of type "text/plain" and MUST encapsulate such message 325 bodies as the XML character data of the XMPP element. 327 A SIMPLE-to-XMPP gateway SHOULD process SIP messages that contain 328 message bodies of type "text/html"; if so, a gateway MUST transform 329 the "text/html" content into XHTML content that conforms to the XHTML 330 1.0 Integration Set specified in [XEP-0071]. 332 A SIMPLE-to-XMPP gateway MAY process SIP messages that contain 333 message bodies of types other than "text/plain" and "text/html" but 334 handling of such content types is a matter of implementation. 336 4. Security Considerations 338 Detailed security considerations for instant messaging protocols are 339 given in [IMP-REQS], for SIP-based instant messaging in [SIP-IM] (see 340 also [SIP]), and for XMPP-based instant messaging in [XMPP-IM] (see 341 also [XMPP]). 343 This document specifies methods for exchanging instant messages 344 information through a gateway that translates between SIP and XMPP. 345 Such a gateway MUST be compliant with the minimum security 346 requirements of the instant messaging protocols for which it 347 translates (i.e., SIP and XMPP). The addition of gateways to the 348 security model of instant messaging specified in [IMP-REQS] 349 introduces some new risks. In particular, end-to-end security 350 properties (especially confidentiality and integrity) between instant 351 messaging user agents that interface through a SIMPLE-XMPP gateway 352 can be provided only if common formats are supported. Specification 353 of those common formats is out of scope for this document, although 354 it is recommended to use [MSGFMT] for instant messages. 356 [IMP-REQS] requires that conformant technologies shall include 357 methods for blocking communications from unwanted addresses. Such 358 blocking is the responsibility of conformant technology (e.g., XMPP 359 or SIP) and is out of scope for this memo. 361 5. References 363 5.1. Normative References 365 [IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging 366 and Presence", RFC 3861, August 2004. 368 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 369 A., Peterson, J., Sparks, R., Handley, M., and E. 370 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 371 June 2002. 373 [SIP-IM] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 374 and D. Gurle, "Session Initiation Protocol (SIP) Extension 375 for Instant Messaging", RFC 3428, December 2002. 377 [SIP-XMPP] 378 Saint-Andre, P., Houri, A., and J. Hildebrand, 379 "Interworking between the Session Initiation Protocol 380 (SIP) and the Extensible Messaging and Presence Protocol 381 (XMPP): Core", draft-saintandre-sip-xmpp-core-01 (work in 382 progress), March 2009. 384 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 385 specifying the location of services (DNS SRV)", RFC 2782, 386 February 2000. 388 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 392 Protocol (XMPP): Core", RFC 3920, October 2004. 394 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 395 Protocol (XMPP): Instant Messaging and Presence", 396 RFC 3921, October 2004. 398 5.2. Informative References 400 [CPIM] Peterson, J., "Common Profile for Instant Messaging 401 (CPIM)", RFC 3860, August 2004. 403 [IMP-REQS] 404 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 405 / Presence Protocol Requirements", RFC 2779, 406 February 2000. 408 [MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant 409 Messaging (CPIM): Message Format", RFC 3862, August 2004. 411 [SIMPLE-CPIM] 412 Rosenberg, J. and B. Campbell, "CPIM Mapping of SIMPLE 413 Presence and Instant Messaging", 414 draft-ietf-simple-cpim-mapping-01 (work in progress), 415 June 2002. 417 [XEP-0071] 418 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, January 2006. 420 [XMPP-CPIM] 421 Saint-Andre, P., "Mapping the Extensible Messaging and 422 Presence Protocol (XMPP) to Common Presence and Instant 423 Messaging (CPIM)", RFC 3922, October 2004. 425 Authors' Addresses 427 Peter Saint-Andre 428 Cisco 430 Email: psaintan@cisco.com 431 Avshalom Houri 432 IBM 433 Building 18/D, Kiryat Weizmann Science Park 434 Rehovot 76123 435 Israel 437 Email: avshalom@il.ibm.com 439 Joe Hildebrand 440 Cisco 442 Email: jhildebr@cisco.com