idnits 2.17.1 draft-saintandre-xmpp-simple-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1493. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1499. 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 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 7, 2007) is 6100 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: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1099 -- Looks like a reference, but probably isn't: '2' on line 1020 -- Looks like a reference, but probably isn't: '3' on line 1020 -- Looks like a reference, but probably isn't: '4' on line 1024 ** Obsolete normative reference: RFC 3265 (ref. 'SIP-EVENT') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3454 (ref. 'STRINGPREP') (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4395 (ref. 'URL-GUIDE') (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 3920 (ref. 'XMPP-CORE') (Obsoleted by RFC 6120) ** Obsolete normative reference: RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. 'IDNA') (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 14 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 XMPP Standards Foundation 4 Intended status: Informational A. Houri 5 Expires: February 8, 2008 IBM 6 J. Hildebrand 7 Jabber, Inc. 8 August 7, 2007 10 Basic Messaging and Presence Interworking between the Extensible 11 Messaging and Presence Protocol (XMPP) and Session Initiation Protocol 12 (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) 13 draft-saintandre-xmpp-simple-10 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 8, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document defines a bi-directional protocol mapping for use by 47 gateways that enable the exchange of presence information and single 48 instant messages between systems that implement the Extensible 49 Messaging and Presence Protocol (XMPP) and those that implement the 50 basic extensions to the Session Initiation Protocol (SIP) for instant 51 messaging and presence. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Architectural Assumptions . . . . . . . . . . . . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 7 61 2.3. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 8 62 3. Instant Messages . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.2. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.3. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 11 66 4. Presence Subscriptions . . . . . . . . . . . . . . . . . . . . 13 67 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 4.2. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.3. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 17 70 5. Presence Notifications . . . . . . . . . . . . . . . . . . . . 20 71 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 5.2. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 21 73 5.3. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 24 74 6. Content Types . . . . . . . . . . . . . . . . . . . . . . . . 26 75 6.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 26 76 6.2. Presence . . . . . . . . . . . . . . . . . . . . . . . . . 26 77 7. Error Conditions . . . . . . . . . . . . . . . . . . . . . . . 27 78 7.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 28 79 7.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 28 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 86 Intellectual Property and Copyright Statements . . . . . . . . . . 35 88 1. Introduction 90 In order to help ensure interworking between instant messaging and 91 presence systems that conform to the requirements of RFC 2779 92 [IMP-REQS], it is important to clearly define mappings between such 93 protocols. Within the IETF, work has proceeded on two such 94 protocols: 96 o Various extensions to the Session Initiation Protocol ([SIP]) for 97 instant messaging and presence, as developed within the SIP for 98 Instant Messaging and Presence Leveraging Extensions (SIMPLE) 99 Working Group; the relevant specifications are [SIP-PRES] for 100 presence and [SIP-IM] for instant messaging 101 o The Extensible Messaging and Presence Protocol (XMPP), which 102 consists of a formalization of the core XML streaming protocols 103 developed originally by the Jabber open-source community; the 104 relevant specifications are [XMPP-CORE] for the XML streaming 105 layer and [XMPP-IM] for basic presence and instant messaging 106 extensions 108 One approach to helping ensure interworking between these protocols 109 is to map each protocol to the abstract semantics described in [CPIM] 110 and [CPP]; that is the approach taken by [SIMPLE-CPIM] and 111 [XMPP-CPIM]. The approach taken in this document is to directly map 112 semantics from one protocol to another (i.e., from SIP/SIMPLE to XMPP 113 and vice-versa). 115 The mappings specified in this document cover several areas that 116 address basic instant messaging and presence functionality: 118 o Mapping of addresses 119 o Mapping of single instant messages 120 o Mapping of presence subscriptions 121 o Mapping of presence notifications 122 o Handling of content types 123 o Mapping of error conditions 125 Mapping of more advanced functionality is out of scope for this 126 document; however, the authors will attempt to address such mappings 127 in future documents devoted to one-to-one messaging sessions, multi- 128 user chat, extended presence, etc. 130 1.1. Architectural Assumptions 132 Protocol translation between XMPP and SIMPLE could occur in a number 133 of different entities, depending on the architecture of presence and 134 messaging deployments. For example, protocol translation could occur 135 within a multi-protocol server, within a multi-protocol client, or 136 within a gateway that acts as a dedicated protocol translator. 138 This document assumes that the protocol translation will occur within 139 a gateway. (This assumption not meant to discourage protocol 140 translation within multi-protocol clients or servers; instead, this 141 assumption is followed mainly to clarify the discussion and examples 142 so that the protocol translation principles can be more easily 143 understood and can be applied by client and server implementors with 144 appropriate modifications to the examples and terminology.) 145 Specifically, we assume that the protocol translation will occur 146 within an "XMPP-to-SIMPLE gateway" that translates XMPP syntax and 147 semantics on behalf of an XMPP service when communicating with SIMPLE 148 services and/or within a "SIMPLE-to-XMPP gateway" that translates SIP 149 syntax and semantics on behalf of a SIMPLE service when communicating 150 with XMPP services. 152 Although such a gateway could use the [CPIM] and [CPP] specifications 153 to define the common formats into which the protocols are translated 154 for purposes of interworking (as specified in [SIMPLE-CPIM] and 155 [XMPP-CPIM]), this document assumes that a gateway will translate 156 directly from one protocol to the other. We further assume that 157 protocol translation will occur within a gateway in the source 158 domain, so that messages and presence information generated by the 159 user of an XMPP service will be translated by a gateway within the 160 trust domain of that XMPP service, and messages and presence 161 information generated by the user of a SIMPLE service will be 162 translated by a gateway within the trust domain of that SIMPLE 163 service. 165 An architectural diagram for a typical gateway deployment is shown 166 below, where the entities have the following significance and the "#" 167 character is used to show the boundary of a trust domain: 169 o romeo@example.net -- a SIMPLE user. 170 o example.net -- a SIMPLE service. 171 o s2x.example.net -- a SIMPLE-to-XMPP gateway. 172 o juliet@example.com -- an XMPP user. 173 o example.com -- an XMPP service. 174 o x2s.example.com -- an XMPP-to-SIMPLE gateway. 176 ##################################################################### 177 # # # 178 # +-- s2x.example.net---#------------- example.com # 179 # | # | | # 180 # example.net -----------------#--- x2s.example.com | # 181 # | # | # 182 # | # | # 183 # romeo@example.net # juliet@example.com # 184 # # # 185 ##################################################################### 187 1.2. Terminology 189 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 190 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 191 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 192 interpreted as described in RFC 2119 [TERMS]. 194 2. Addresses 196 2.1. Overview 198 The address formats used to identify XMPP entities are different from 199 those used to identify SIP entities. The XMPP address format is 200 specified in [XMPP-CORE]; as specified in [XMPP-IM], instant 201 messaging and presence applications of XMPP must also support 'im:' 202 and 'pres:' URIs as specified in [CPIM] and [CPP] respectively, 203 although such support may simply involve leaving resolution of such 204 addresses up to an XMPP server. The SIP address format for instant 205 messaging is specified in [SIP-IM]; it may use either 'sip:' or 206 'sips:' URIs as specified in [SIP] or an 'im:' URI as specified in 207 [CPIM]. The SIP address format for presence is specified in 208 [SIP-PRES]; it may use either 'sip:' or 'sips:' URIs as specified in 209 [SIP] or a 'pres:' URI as specified in [CPP]. 211 In this document we describe mappings for addresses of the form 212 only, ignoring (for the purpose of address mapping) any 213 protocol-specific extensions such as XMPP resource identifiers or SIP 214 telephone numbers and passwords. In addition, we have ruled the 215 mapping of domain names as out of scope for now since that is a 216 matter for the Domain Name System; specifically, the issue for 217 interworking between SIP and XMPP relates to the translation of fully 218 internationalized domain names (which the SIP address format does not 219 allow, but which the XMPP address format does allow via [IDNA]) into 220 non-internationalized domain names. Therefore, in the following 221 sections we discuss local-part addresses only (these are called 222 variously "usernames", "instant inboxes", "presentities", and "node 223 identifiers" in the protocols at issue). 225 The sip:/sips:, im:/pres:, and XMPP address schemes allow different 226 sets of characters (although all three allow alphanumeric characters 227 and disallow both spaces and control characters). In some cases, 228 characters allowed in one scheme are disallowed in others; these 229 characters must be mapped appropriately in order to ensure 230 interworking across systems. 232 The local-part address in sip:/sips: URIs inherits from the 233 "userinfo" rule in [URI] with several changes; here we discuss the 234 SIP "user" rule only: 236 user = 1*( unreserved / escaped / user-unreserved ) 237 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 238 unreserved = alphanum / mark 239 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 240 / "(" / ")" 242 Here we make the simplifying assumption that the local-part address 243 in im:/pres: URIs inherits from the "dot-atom-text" rule in [RFC2822] 244 rather than the more complicated "local-part" rule: 246 dot-atom-text = 1*atext *("." 1*atext) 247 atext = ALPHA / DIGIT / ; Any character except controls, 248 "!" / "#" / ; SP, and specials. 249 "$" / "%" / ; Used for atoms 250 "&" / "'" / 251 "*" / "+" / 252 "-" / "/" / 253 "=" / "?" / 254 "^" / "_" / 255 "`" / "{" / 256 "|" / "}" / 257 "~" 259 The local-part address in XMPP addresses allows any US-ASCII 260 character except space, controls, and the " & ' / : < > @ characters. 262 Therefore, following table lists the allowed and disallowed 263 characters in the local-part addresses of each protocol (aside from 264 the alphanumeric, space, and control characters), in order by 265 hexadecimal character number (where the "A" row shows the allowed 266 characters and the "D" row shows the disallowed characters). 268 Table 1: Allowed and disallowed characters 270 +---+----------------------------------+ 271 | SIP/SIPS CHARACTERS | 272 +---+----------------------------------+ 273 | A | ! $ &'()*+,-./ ; = ? _ ~ | 274 | D | "# % : < > @[\]^ `{|} | 275 +---+----------------------------------+ 276 | IM/PRES CHARACTERS | 277 +---+----------------------------------+ 278 | A | ! #$%&' *+ - / = ? ^_`{|}~ | 279 | D | " () , . :;< > @[\] | 280 +---+----------------------------------+ 281 | XMPP CHARACTERS | 282 +---+----------------------------------+ 283 | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | 284 | D | " &' /: < > @ | 285 +---+----------------------------------+ 287 When transforming a local-part address from one scheme to another, an 288 application SHOULD proceed as follows: 290 1. Unescape any escaped characters in the source address (e.g., from 291 SIP to XMPP unescape "%2F" to "/" and from XMPP to SIP unescape 292 "\27" to "'"). 293 2. Leave unmodified any characters that are allowed in the 294 destination scheme. 295 3. Escape any characters that are allowed in the source scheme but 296 reserved in the destination scheme, as escaping is defined for 297 the destination scheme. In particular: 298 * Where the destination scheme is a URI (i.e., an im:, pres:, 299 sip:, or sips: URI), each reserved character MUST be percent- 300 encoded to "%hexhex" as specified in Section 2.6 of 301 [URL-GUIDE] (e.g., when transforming from XMPP to SIP, encode 302 "/" as "%2F"). 303 * Where the destination scheme is a native XMPP address, each 304 reserved character MUST be encoded to "\hexhex" as specified 305 in [XEP-0106] (e.g., when transforming from SIP to XMPP, 306 encode "'" as "\27"). 308 2.2. XMPP to SIP 310 The following is a high-level algorithm for mapping an XMPP address 311 to a sip:, sips:, im:, or pres: URI: 313 1. Split XMPP address into node identifier (local-part; mapping 314 described in remaining steps), domain identifier (hostname; 315 mapping is out of scope), and resource identifier (specifier for 316 particular device or connection; discard this for cross-system 317 interworking). 318 2. Apply Nodeprep profile of [STRINGPREP] (as specified in 319 [XMPP-CORE]) for canonicalization (OPTIONAL). 320 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" 321 respectively (this is consistent with [XEP-0106]). 322 4. Determine if the foreign domain supports im: and pres: URIs 323 (discovered via [SRV] lookup as specified in [XMPP-IM]), else 324 assume that the foreign domain supports sip:/sips: URIs. 325 5. If converting into im: or pres: URI, for each byte, if the byte 326 is in the set (),.;[\] (i.e., the partial complement from Row 3, 327 Column 2 of Table 3 above) or is a UTF-8 character outside the 328 US-ASCII range then transform that byte to %hexhex. If 329 converting into sip: or sips: URI, for each byte, if the byte is 330 in the set #%[\]^`{|} (i.e., the partial complement from Row 3, 331 Column 1 of Table 3 above) or is a UTF-8 character outside the 332 US-ASCII range then transform that byte to %hexhex. 333 6. Combine resulting local-part with mapped hostname to form 334 local@domain address. 335 7. Prepend with 'im:' scheme (for XMPP stanzas) or 336 'pres:' scheme (for XMPP stanzas) if foreign domain 337 supports these, else prepend with 'sip:' or 'sips:' scheme 338 according to local service policy. 340 2.3. SIP to XMPP 342 The following is a high-level algorithm for mapping a sip:, sips:, 343 im:, or pres: URI to an XMPP address: 345 1. Remove URI scheme. 346 2. Split at the first '@' character into local-part and hostname 347 (mapping the latter is out of scope). 348 3. Translate %hexhex to equivalent octets. 349 4. Treat result as a UTF-8 string. 350 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" 351 respectively in order to properly handle the characters 352 disallowed in XMPP addresses but allowed in sip:/sips: URIs and 353 im:/pres: URIs as shown in Column 3 of Table 3 above (this is 354 consistent with [XEP-0106]). 355 6. Apply Nodeprep profile of [STRINGPREP] (as specified in 356 [XMPP-CORE]) for canonicalization (OPTIONAL). 357 7. Recombine local-part with mapped hostname to form local@domain 358 address. 360 3. Instant Messages 361 3.1. Overview 363 Both XMPP and IM-aware SIP systems enable entities (often but not 364 necessarily human users) to send "instant messages" to other 365 entities. The term "instant message" usually refers to messages sent 366 between two entities for delivery in close to real time (rather than 367 messages that are stored and forwarded to the intended recipient upon 368 request). Generally there are three kinds of instant message: 370 o Single messages, which are sent from the sender to the recipient 371 outside the context of any one-to-one chat session or multi-user 372 text conference. 373 o Chat messages, which are sent from the sender to the recipient in 374 the context of a "messaging session" between the two entities. 375 o Groupchat messages, which are sent from a sender to multiple 376 recipients in the context of a text conference. 378 This document covers single messages only, since they form the 379 "lowest common denominator" for instant messaging on the Internet. 380 It is likely that future documents will address one-to-one chat 381 sessions and multi-user chat. 383 Instant messaging using XMPP message stanzas of type "normal" is 384 specified in [XMPP-IM]. Instant messaging using SIP requests of type 385 MESSAGE (often called "page-mode" messaging) is specified in 386 [SIP-IM]. 388 As described in [XMPP-IM], a single instant message is an XML 389 stanza of type "normal" sent over an XML stream (since 390 "normal" is the default for the 'type' attribute of the 391 stanza, the attribute is often omitted). In this document we will 392 assume that such a message is sent from an XMPP client to an XMPP 393 server over an XML stream negotiated between the client and the 394 server, and that the client is controlled by a human user (this is a 395 simplifying assumption introduced for explanatory purposes only; the 396 XMPP sender could be a bot-controlled client, a component such as a 397 workflow application, a server, etc.). Continuing the tradition of 398 Shakespeare examples in XMPP documentation, we will say that the XMPP 399 user has an XMPP address of . 401 As described in [SIP-IM], a single instant message is a SIP MESSAGE 402 request sent from a SIP user agent to an intended recipient who is 403 most generally referenced by an Instant Message URI of the form 404 but who may be referenced by a SIP or SIPS URI of 405 the form or Here again we 406 introduce the simplifying assumption that the user agent is 407 controlled by a human user, whom we shall dub . 409 3.2. XMPP to SIP 411 When Juliet wants to send an instant message to Romeo, she interacts 412 with her XMPP client, which generates an XMPP stanza. The 413 syntax of the stanza, including required and optional 414 elements and attributes, is defined in [XMPP-IM]. The following is 415 an example of such a stanza: 417 Example: XMPP user sends message: 419 | 421 | Art thou not Romeo, and a Montague? 422 | 424 Upon receiving such a stanza, the XMPP server to which Juliet has 425 connected either delivers it to a local recipient (if the hostname in 426 the 'to' attribute matches one of the hostnames serviced by the XMPP 427 server) or attempts to route it to the foreign domain that services 428 the hostname in the 'to' attribute. Naturally, in this document we 429 assume that the hostname in the 'to' attribute is an IM-aware SIP 430 service hosted by a separate server. As specified in [XMPP-IM], the 431 XMPP server needs to determine the identity of the foreign domain, 432 which it does by performing one or more [SRV] lookups. For message 433 stanzas, the order of lookups recommended by [XMPP-IM] is to first 434 try the "_xmpp-server" service as specified in [XMPP-CORE] and to 435 then try the "_im" service as specified in [IMP-SRV]. Here we assume 436 that the first lookup will fail but that the second lookup will 437 succeed and return a resolution "_im._simple.example.net.", since we 438 have already assumed that the example.net hostname is running a SIP 439 instant messaging service. (Note: The XMPP server may have 440 previously determined that the foreign domain is a SIMPLE server, in 441 which case it would not need to perform the SRV lookups; the caching 442 of such information is a matter of implementation and local service 443 policy, and is therefore out of scope for this document.) 445 Once the XMPP server has determined that the foreign domain is 446 serviced by a SIMPLE server, it must determine how to proceed. We 447 here assume that the XMPP server contains or has available to it an 448 XMPP-SIMPLE gateway. The XMPP server would then deliver the message 449 stanza to the XMPP-SIMPLE gateway. 451 The XMPP-SIMPLE gateway is then responsible for translating the XMPP 452 message stanza into a SIP MESSAGE request from the XMPP user to the 453 SIP user: 455 Example: XMPP user sends message (SIP transformation): 457 | MESSAGE sip:romeo@example.net SIP/2.0 458 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse 459 | Max-Forwards: 70 460 | From: sip:juliet@example.com;tag=49583 461 | To: sip:romeo@example.net 462 | Call-ID: Hr0zny9l3@example.com 463 | CSeq: 1 MESSAGE 464 | Content-Type: text/plain 465 | Content-Length: 35 466 | 467 | Art thou not Romeo, and a Montague? 469 The mapping of XMPP syntax elements to SIP syntax elements SHOULD be 470 as shown in the following table. (Mappings for elements not 471 mentioned are undefined.) 473 Table 4: Message syntax mapping from XMPP to SIP 475 +-----------------------------+--------------------------+ 476 | XMPP Element or Attribute | SIP Header or Contents | 477 +-----------------------------+--------------------------+ 478 | | body of MESSAGE | 479 | | Subject | 480 | | Call-ID | 481 | from | From | 482 | id | (no mapping) | 483 | to | To | 484 | type | (no mapping) | 485 | xml:lang | Content-Language | 486 +-----------------------------+--------------------------+ 488 3.3. SIP to XMPP 490 When Romeo wants to send an instant message to Juliet, he interacts 491 with his SIP user agent, which generates a SIP MESSAGE request. The 492 syntax of the MESSAGE request is defined in [SIP-IM]. The following 493 is an example of such a request: 495 Example: SIP user sends message: 497 | MESSAGE sip:juliet@example.com SIP/2.0 498 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677 499 | Max-Forwards: 70 500 | From: sip:romeo@example.net;tag=38594 501 | To: sip:juliet@example.com 502 | Call-ID: M4spr4vdu@example.net 503 | CSeq: 1 MESSAGE 504 | Content-Type: text/plain 505 | Content-Length: 44 506 | 507 | Neither, fair saint, if either thee dislike. 509 Section 5 of [SIP-IM] stipulates that a SIP User Agent presented with 510 an im: URI should resolve it to a sip: or sips: URI. Therefore we 511 assume that the To header of a request received by a SIMPLE-XMPP 512 gateway will contain a sip: or sips: URI. The gateway SHOULD resolve 513 that address to an im: URI for SIP MESSAGE requests, then follow the 514 rules in [IMP-SRV] regarding the "_im" SRV service for the target 515 domain contained in the To header. If SRV address resolution fails 516 for the "_im" service, the gateway MAY attempt a lookup for the 517 "_xmpp-server" service as specified in [XMPP-CORE] or MAY return an 518 error to the sender (the SIP "502 Bad Gateway" error seems most 519 appropriate; see Section 7 for details). If SRV address resolution 520 succeeds, the gateway is responsible for translating the request into 521 an XMPP message stanza from the SIP user to the XMPP user and 522 returning a SIP "200 OK" message to the sender: 524 Example: SIP user sends message (XMPP transformation): 526 | 528 | Neither, fair saint, if either thee dislike. 529 | 531 The mapping of SIP syntax elements to XMPP syntax elements SHOULD be 532 as shown in the following table. (Mappings for elements not 533 mentioned in the foregoing table are undefined.) 534 Table 5: Message syntax mapping from SIP to XMPP 536 +--------------------------+-----------------------------+ 537 | SIP Header or Contents | XMPP Element or Attribute | 538 +--------------------------+-----------------------------+ 539 | Call-ID | | 540 | Content-Language | xml:lang | 541 | CSeq | (no mapping) | 542 | From | from | 543 | Subject | | 544 | To | to | 545 | body of MESSAGE | | 546 +--------------------------+-----------------------------+ 548 Note: When transforming SIP page-mode messages, a SIMPLE-XMPP gateway 549 SHOULD specify no XMPP 'type' attribute or a 'type' attribute whose 550 value is "normal" (alternatively, the value of the 'type' attribute 551 MAY be "chat", although it SHOULD NOT be "headline" and MUST NOT be 552 "groupchat"). 554 Note: See the Content Types (Section 6) of this document regarding 555 handling of SIP message bodies that contain content types other than 556 plain text. 558 4. Presence Subscriptions 560 4.1. Overview 562 Both XMPP and presence-aware SIP systems enable entities (often but 563 not necessarily human users) to subscribe to the presence of other 564 entities. XMPP presence subscriptions are specified in [XMPP-IM]. 565 Presence subscriptions using a SIP event package for presence are 566 specified in [SIP-PRES]. 568 As described in [XMPP-IM], XMPP presence subscriptions are managed 569 using XMPP presence stanzas of type "subscribe", "subscribed", 570 "unsubscribe", and "unsubscribed". The main subscription states are 571 "none" (neither the user nor the contact is subscribed to the other's 572 presence information), "from" (the user has a subscription from the 573 contact), "to" (the user has a subscription to the contact's presence 574 information), and "both" (both user and contact are subscribed to 575 each other's presence information). 577 As described in [SIP-PRES], SIP presence subscriptions are managed 578 through the use of SIP SUBSCRIBE events sent from a SIP user agent to 579 an intended recipient who is most generally referenced by an Instant 580 Message URI of the form but who may be referenced 581 by a SIP or SIPS URI of the form or 582 . 584 The subscription models underlying XMPP and SIP are quite different. 585 For instance, XMPP presence subscriptions are long-lived (indeed 586 permanent if not explicitly cancelled), whereas SIP presence 587 subscriptions are short-lived (the default time to live of a SIP 588 presence subscription is 3600 seconds, as specified in Section 6.4 of 589 [SIP-PRES]). These differences are addressed below. 591 4.2. XMPP to SIP 593 4.2.1. Establishing 595 An XMPP user initiates a subscription by sending a subscription 596 request to another entity (conventionally called a "contact"), which 597 request the contact either accepts or declines. If the contact 598 accepts the request, the user will have a subscription to the 599 contact's presence information until (1) the user unsubscribes or (2) 600 the contact cancels the subscription. The subscription request is 601 encapsulated in a presence stanza of type "subscribe": 603 Example: XMPP user subscribes to SIP contact: 605 | 609 Upon receiving such a stanza, the XMPP server to which Juliet has 610 connected needs to determine the identity of the foreign domain, 611 which it does by performing one or more [SRV] lookups. For presence 612 stanzas, the order of lookups recommended by [XMPP-IM] is to first 613 try the "_xmpp-server" service as specified in [XMPP-CORE] and to 614 then try the "_pres" service as specified in [IMP-SRV]. Here we 615 assume that the first lookup will fail but that the second lookup 616 will succeed and return a resolution "_pres._simple.example.net.", 617 since we have already assumed that the example.net hostname is 618 running a SIP presence service. 620 Once the XMPP server has determined that the foreign domain is 621 serviced by a SIMPLE server, it must determine how to proceed. We 622 here assume that the XMPP server contains or has available to it an 623 XMPP-SIMPLE gateway. The XMPP server would then deliver the presence 624 stanza to the XMPP-SIMPLE gateway. 626 The XMPP-SIMPLE gateway is then responsible for translating the XMPP 627 subscription request into a SIP SUBSCRIBE request from the XMPP user 628 to the SIP user: 630 Example: XMPP user subscribes to SIP contact (SIP transformation): 632 | SUBSCRIBE sip:romeo@example.net SIP/2.0 633 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk 634 | From: ;tag=ffd2 635 | To: 636 | Call-ID: l04th3s1p@example.com 637 | Event: presence 638 | Max-Forwards: 70 639 | CSeq: 123 SUBSCRIBE 640 | Contact: 641 | Accept: application/pidf+xml 642 | Expires: 3600 643 | Content-Length: 0 645 The SIP user then SHOULD send a response indicating acceptance of the 646 subscription request: 648 Example: SIP accepts subscription request: 650 | SIP/2.0 200 OK 651 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk 652 | From: ;tag=ffd2 653 | To: ;tag=j89d 654 | Call-ID: l04th3s1p@example.com 655 | CSeq: 234 SUBSCRIBE 656 | Contact: 657 | Expires: 3600 658 | Content-Length: 0 660 In accordance with [SIP-EVENT], the XMPP-SIMPLE gateway should 661 consider the subscription state to be "neutral" until it receives a 662 NOTIFY message. Therefore the SIP user or SIP-XMPP gateway at the 663 SIP user's domain SHOULD immediately send a NOTIFY message containing 664 a "Subscription-State" header whose value contains the string 665 "active" (see Section 5). 667 Example: SIP user sends presence notification: 669 | NOTIFY sip:192.0.2.1 SIP/2.0 670 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 671 | From: ;tag=yt66 672 | To: ;tag=bi54 673 | Call-ID: l04th3s1p@example.com 674 | Event: presence 675 | Subscription-State: active;expires=499 676 | Max-Forwards: 70 677 | CSeq: 8775 NOTIFY 678 | Contact: 679 | Content-Type: application/pidf+xml 680 | Content-Length: 193 681 | 682 | 683 | 685 | 686 | 687 | open 688 | 689 | 690 | 692 Upon receiving the first NOTIFY with a subscription state of active, 693 the XMPP-SIMPLE gateway MUST generate a presence stanza of type 694 "subscribed": 696 Example: XMPP user receives acknowledgement from SIP contact: 698 | 702 For information about handling of the NOTIFY message, see Section 5. 704 4.2.2. Refreshing 706 It is the responsibility of the XMPP-SIMPLE gateway to set the value 707 of the "Expires" header and to periodically renew the subscription on 708 the SIMPLE side of the gateway so that the subscription appears to be 709 permanent to the XMPP user (e.g., the XMPP-SIMPLE gateway SHOULD send 710 a new SUBSCRIBE request to the SIP user whenever the XMPP user sends 711 initial presence to its XMPP server, i.e., upon initiating a presence 712 session with the XMPP server). See the Security Considerations 713 (Section 8) of this document for important information and 714 requirements regarding the security implications of this 715 functionality. 717 4.2.3. Cancelling 719 At any time after subscribing, the XMPP user may unsubscribe from the 720 contact's presence. This is done by sending a presence stanza of 721 type "unsubscribe": 723 Example: XMPP user unsubscribes from SIP contact: 725 | 729 The XMPP-SIMPLE gateway is responsible for translating the 730 unsubscribe command into a SIP SUBSCRIBE request with the "Expires" 731 header set to a value of zero: 733 Example: XMPP user unsubscribes from SIP contact (SIP 734 transformation): 736 | SUBSCRIBE sip:romeo@example.net SIP/2.0 737 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk 738 | From: ;tag=j89d 739 | To: ;tag=xfg9 740 | Call-ID: 1ckm32@example.com 741 | Event: presence 742 | Max-Forwards: 70 743 | CSeq: 789 SUBSCRIBE 744 | Contact: 745 | Accept: application/pidf+xml 746 | Expires: 0 747 | Content-Length: 0 749 Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway 750 SHOULD a presence stanza of type "unsubscribed" to the XMPP user: 752 Example: XMPP user receives unsubscribed notification: 754 | 758 4.3. SIP to XMPP 759 4.3.1. Establishing 761 A SIP user initiates a subscription to a contact's presence 762 information by sending a SIP SUBSCRIBE request to the contact. The 763 following is an example of such a request: 765 Example: SIP user subscribes to XMPP contact: 767 | SUBSCRIBE sip:juliet@example.com SIP/2.0 768 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk 769 | From: ;tag=xfg9 770 | To: ;tag=ur93 771 | Call-ID: 4wcm0n@example.net 772 | Event: presence 773 | Max-Forwards: 70 774 | CSeq: 263 SUBSCRIBE 775 | Contact: 776 | Accept: application/pidf+xml 777 | Content-Length: 0 779 Upon receiving such a request, a SIMPLE-XMPP gateway is responsible 780 for translating it into an XMPP subscription request from the SIP 781 user to the XMPP user: 783 Example: SIP user subscribes to XMPP contact (XMPP transformation): 785 | 789 Notice that the "Expires" header was not included in the SUBSCRIBE 790 request; this means that the default value of 3600 (i.e., 3600 791 seconds = 1 hour) applies. 793 4.3.2. Refreshing 795 It is the responsibility of the SIMPLE-XMPP gateway to properly 796 handle the difference between short-lived SIP presence subscriptions 797 and long-lived XMPP presence subscriptions. The gateway has two 798 options when the SIP user's subscription expires: 800 o Cancel the subscription (i.e., treat it as temporary) and send an 801 XMPP presence stanza of type "unsubscribe" to the XMPP contact; 802 this honors the SIP semantic but will seem rather odd to the XMPP 803 contact. 804 o Maintain the subscription (i.e., treat it as long-lived) and (1) 805 send a SIP NOTIFY request to the SIP user containing a PIDF 806 document specifying that the XMPP contact now has a basic status 807 of "closed", including a Subscription-State of "terminated" and 808 (2) send an XMPP presence stanza of type "unavailable" to the XMPP 809 contact; this violates the letter of the SIP semantic but will 810 seem more natural to the XMPP contact. 812 Which of these options the SIMPLE-XMPP gateway chooses is up to the 813 implementation. 815 If the implementation chooses the first option, the protocol 816 generated would be as follows: 818 Example: SIP subscription expires (treated as temporary by gateway): 820 | 824 If the implementation chooses the second option, the protocol 825 generated would be as follows: 827 Example: SIP subscription expires (treated as long-lived by gateway): 829 | NOTIFY sip:192.0.2.2 SIP/2.0 830 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk 831 | From: ;tag=ur93 832 | To: ;tag=pq72 833 | Call-ID: j4s0h4vny@example.com 834 | Event: presence 835 | Subscription-State: terminated;reason=timeout 836 | Max-Forwards: 70 837 | CSeq: 232 NOTIFY 838 | Contact: 839 | Content-Type: application/pidf+xml 840 | Content-Length: 194 841 | 842 | 843 | 845 | 846 | 847 | closed 848 | 849 | 850 | 851 Example: SIP subscription expires (treated as long-lived by gateway): 853 | 857 4.3.3. Cancelling 859 At any time, the SIP user may cancel the subscription by sending a 860 SUBSCRIBE message whose "Expires" header is set to a value of zero 861 ("0"): 863 Example: SIP user cancels subscription: 865 | SUBSCRIBE sip:192.0.2.1 SIP/2.0 866 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 867 | From: ;tag=yt66 868 | To: ;tag=bi54 869 | Call-ID: 1tsn1ce@example.net 870 | Event: presence 871 | Max-Forwards: 70 872 | CSeq: 8775 SUBSCRIBE 873 | Contact: 874 | Expires: 0 875 | Content-Length: 0 877 As above, upon receiving such a request, a SIMPLE-XMPP gateway is 878 responsible for doing one of the following: 880 o Cancel the subscription (i.e., treat it as temporary) and send an 881 XMPP presence stanza of type "unsubscribe" to the XMPP contact. 882 o Maintain the subscription (i.e., treat it as long-lived) and (1) 883 send a SIP NOTIFY request to the SIP user containing a PIDF 884 document specifying that the XMPP contact now has a basic status 885 of "closed", (2) send a SIP SUBSCRIBE request to the SIP user with 886 an "Expires" header set to a value of "0" (zero) when it receives 887 XMPP presence of type "unavailable" from the XMPP contact, and (3) 888 send an XMPP presence stanza of type "unavailable" to the XMPP 889 contact. 891 5. Presence Notifications 893 5.1. Overview 895 Both XMPP and presence-aware SIP systems enable entities (often but 896 not necessarily human users) to send presence notifications to other 897 entities. At a minimum, the term "presence" refers to information 898 about an entity's availability for communication on a network (on/ 899 off), often supplemented by information that further specifies the 900 entity's communications context (e.g., "do not disturb"). Some 901 systems and protocols extend this notion even further and refer to 902 any relatively ephemeral information about an entity as a kind of 903 presence; categories of such "extended presence" include geographical 904 location (e.g., GPS coordinates), user mood (e.g., grumpy), user 905 activity (e.g., walking), and ambient environment (e.g., noisy). In 906 this document, we focus on the "least common denominator" of network 907 availability only, although future documents may address broader 908 notions of presence, including extended presence. 910 Presence using XMPP presence stanzas of type "available" or 911 "unavailable" is specified in [XMPP-IM]. SIP presence using a SIP 912 event package for presence is specified in [SIP-PRES]. 914 As described in [XMPP-IM], presence information about an entity is 915 communicated by means of an XML stanza sent over an XML 916 stream. In this document we will assume that such a presence stanza 917 is sent from an XMPP client to an XMPP server over an XML stream 918 negotiated between the client and the server, and that the client is 919 controlled by a human user (again, this is a simplifying assumption 920 introduced for explanatory purposes only). In general, XMPP presence 921 is sent by the user to the user's server and then broadcasted to all 922 entities who are subscribed to the user's presence information. 924 As described in [SIP-PRES], presence information about an entity is 925 communicated by means of a SIP NOTIFY event sent from a SIP user 926 agent to an intended recipient who is most generally referenced by an 927 Instant Message URI of the form but who may be 928 referenced by a SIP or SIPS URI of the form or 929 . Here again we introduce the simplifying 930 assumption that the user agent is controlled by a human user. 932 5.2. XMPP to SIP 934 When Juliet interacts with her XMPP client to modify her presence 935 information (or when her client automatically updates her presence 936 information, e.g. via an "auto-away" feature), her client generates 937 an XMPP stanza. The syntax of the stanza, 938 including required and optional elements and attributes, is defined 939 in [XMPP-IM]. The following is an example of such a stanza: 941 Example: XMPP user sends presence notification: 943 | 945 Upon receiving such a stanza, the XMPP server to which Juliet has 946 connected broadcasts it to all subscribers who are authorized to 947 receive presence notifications from Juliet (this is similar to the 948 SIP NOTIFY method). For each subscriber, broadcasting the presence 949 notification involves either delivering it to a local recipient (if 950 the hostname in the subscriber's address matches one of the hostnames 951 serviced by the XMPP server) or attempting to route it to the foreign 952 domain that services the hostname in the subscriber's address. 953 Naturally, in this document we assume that the hostname is a SIP 954 presence service hosted by a separate server. As specified in 955 [XMPP-IM], the XMPP server needs to determine the identity of the 956 foreign domain, which it does by performing one or more [SRV] 957 lookups. For presence stanzas, the order of lookups recommended by 958 [XMPP-IM] is to first try the "_xmpp-server" service as specified in 959 [XMPP-CORE] and to then try the "_pres" service as specified in 960 [IMP-SRV]. Here we assume that the first lookup will fail but that 961 the second lookup will succeed and return a resolution 962 "_pres._simple.example.net.", since we have already assumed that the 963 example.net hostname is running a SIP presence service. (Note: The 964 XMPP server may have previously determined that the foreign domain is 965 a SIMPLE server, e.g., when it sent a SIP SUBSCRIBE to the SIP user 966 when Juliet sent initial presence to the XMPP server, in which case 967 it would not need to perform the SRV lookups; the caching of such 968 information is a matter of implementation and local service policy, 969 and is therefore out of scope for this document.) 971 Once the XMPP server has determined that the foreign domain is 972 serviced by a SIMPLE server, it must determine how to proceed. We 973 here assume that the XMPP server contains or has available to it an 974 XMPP-SIMPLE gateway. The XMPP server would then deliver the presence 975 stanza to the XMPP-SIMPLE gateway. 977 The XMPP-SIMPLE gateway is then responsible for translating the XMPP 978 presence stanza into a SIP NOTIFY request and included PIDF document 979 from the XMPP user to the SIP user. 981 Example: XMPP user sends presence notification (SIP transformation): 983 | NOTIFY sip:192.0.2.2 SIP/2.0 984 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk 985 | From: ;tag=gh19 986 | To: ;tag=yt66 987 | Call-ID: j4s0h4vny@example.com 988 | Event: presence 989 | Subscription-State: active;expires=599 990 | Max-Forwards: 70 991 | CSeq: 157 NOTIFY 992 | Contact: 993 | Content-Type: application/pidf+xml 994 | Content-Length: 192 995 | 996 | 997 | 999 | 1000 | 1001 | open 1002 | 1003 | 1004 | 1006 The mapping of XMPP syntax elements to SIP syntax elements SHOULD be 1007 as shown in the following table. (Mappings for elements not 1008 mentioned are undefined.) 1010 Table 6: Presence syntax mapping from XMPP to SIP 1012 +-----------------------------+---------------------------+ 1013 | XMPP Element or Attribute | SIP Header or PIDF Data | 1014 +-----------------------------+---------------------------+ 1015 | stanza | "Event: presence" [1] | 1016 | XMPP resource identifer | tuple 'id' attribute | 1017 | from | From | 1018 | id | Call-ID | 1019 | to | To | 1020 | type | basic status [2][3] | 1021 | xml:lang | Content-Language | 1022 | | PIDF priority for tuple | 1023 | | (no mapping) | 1024 | | note [4] | 1025 +-----------------------------+---------------------------+ 1027 Note the following regarding these mappings: 1029 1. Only a presence stanza that lacks a 'type' attribute or whose 1030 'type' attribute has a value of "unavailable" should be mapped by 1031 an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are 1032 the only presence stanzas that represent notifications. 1033 2. Because the lack of a 'type' attribute indicates that an XMPP 1034 entity is available for communications, the gateway SHOULD map 1035 that information to a PIDF status of "open". Because a 1036 'type' attribute with a value of "unavailable" indicates that an 1037 XMPP entity is not available for communications, the gateway 1038 SHOULD map that information to a PIDF status of 1039 "closed". 1040 3. When the XMPP-SIMPLE gateway receives XMPP presence of type 1041 "unavailable" from the XMPP contact, it SHOULD (1) send a SIP 1042 NOTIFY request to the SIP user containing a PIDF document 1043 specifying that the XMPP contact now has a basic status of 1044 "closed" and (2) send a SIP SUBSCRIBE request to the SIP user 1045 with an "Expires" header set to a value of "0" (zero). 1046 4. The character data of the XMPP element MAY be mapped to 1047 the character data of the PIDF element. 1049 5.3. SIP to XMPP 1051 When Romeo changes his presence, his SIP user agent generates a SIP 1052 NOTIFY request for any active subscriptions. The syntax of the 1053 NOTIFY request is defined in [SIP-PRES]. The following is an example 1054 of such a request: 1056 Example: SIP user sends presence notification: 1058 | NOTIFY sip:192.0.2.1 SIP/2.0 1059 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 1060 | From: ;tag=yt66 1061 | To: ;tag=bi54 1062 | Call-ID: j0sj4sv1m@example.net 1063 | Event: presence 1064 | Subscription-State: active;expires=499 1065 | Max-Forwards: 70 1066 | CSeq: 8775 NOTIFY 1067 | Contact: 1068 | Content-Type: application/pidf+xml 1069 | Content-Length: 193 1070 | 1071 | 1072 | 1074 | 1075 | 1076 | open 1077 | 1078 | 1079 | 1081 Upon receiving such a request, a SIMPLE-XMPP gateway is responsible 1082 for translating it into an XMPP presence stanza from the SIP user to 1083 the XMPP user: 1085 Example: SIP user sends presence notification (XMPP transformation): 1087 | 1091 The mapping of SIP syntax elements to XMPP syntax elements SHOULD be 1092 as shown in the following table. (Mappings for elements not 1093 mentioned are undefined.) 1094 Table 7: Presence syntax mapping from SIP to XMPP 1096 +---------------------------+-----------------------------+ 1097 | SIP Header or PIDF Data | XMPP Element or Attribute | 1098 +---------------------------+-----------------------------+ 1099 | basic status | type [1] | 1100 | Content-Language | xml:lang | 1101 | CSeq | id (OPTIONAL) | 1102 | From | from | 1103 | priority for tuple | | 1104 | To | to | 1105 | body of MESSAGE | | 1106 +---------------------------+-----------------------------+ 1108 Note the following regarding these mappings: 1110 1. A PIDF basic status of "open" SHOULD be mapped to no 'type' 1111 attribute, and a PIDF basic status of "closed" SHOULD be mapped 1112 to a 'type' attribute whose value is "unavailable". 1114 6. Content Types 1116 SIP requests of type MESSAGE may contain essentially any content type 1117 and SIP requests of type NOTIFY normally contain presence information 1118 encapsulated using the "application/pidf+xml" content type. The 1119 recommended procedures for SIMPLE-to-XMPP gateways to use in handling 1120 these content types are specified in the following sections. 1122 6.1. Messages 1124 A SIMPLE-to-XMPP gateway MUST process SIP messages that contain 1125 message bodies of type "text/plain" and MUST encapsulate such message 1126 bodies as the XML character data of the XMPP element. 1128 A SIMPLE-to-XMPP gateway SHOULD process SIP messages that contain 1129 message bodies of type "text/html"; if so, a gateway MUST transform 1130 the "text/html" content into XHTML content that conforms to the XHTML 1131 1.0 Integration Set specified in [XEP-0071]. 1133 A SIMPLE-to-XMPP gateway MAY process SIP messages that contain 1134 message bodies of types other than "text/plain" and "text/html" but 1135 handling of such content types is a matter of implementation. 1137 6.2. Presence 1139 The "application/pidf+xml' content type is specified in [PIDF]. The 1140 Presence Information Data Format defines a common data format for 1141 presence protocols that conform to the Common Profile for Presence 1142 ([CPP]), enabling presence information to be transferred across CPP- 1143 compliant protocol boundaries without modification, with attendant 1144 benefits for end-to-end encryption and performance. Because the 1145 syntax for the "application/pidf+xml" content type is Extensible 1146 Markup Language ([XML]), it is straightforward to send PIDF data over 1147 the Extensible Messaging and Presence Protocol ([XMPP-CORE]), since 1148 XMPP is simply an XML streaming protocol. 1150 In addition to following the syntax mappings specified in Section 5, 1151 a SIMPLE-to-XMPP gateway MAY encapsulate PIDF data within an 1152 "extended namespace" contained in an XMPP presence stanza. The 1153 RECOMMENDED method is to include the PIDF element as a 1154 child of the XMPP stanza. Although it may appear that 1155 this would be potentially confusing, the inclusion of the 1156 'urn:ietf:params:xml:ns:pidf' namespace ensures that PIDF data is 1157 kept separate from XMPP presence data (in accordance with 1158 [XML-NAMES]). The following is a simple example of encapsulating 1159 PIDF data within an "extended namespace" in XMPP: 1161 A basic example of PIDF over XMPP: 1163 1164 dnd 1165 Wooing Juliet 1166 1168 1169 1170 open 1171 1172 1173 1174 1176 7. Error Conditions 1178 SIP response codes are specified in [SIP] and XMPP error conditions 1179 are specified in [XMPP-CORE]. 1181 7.1. XMPP to SIP 1183 Table 8: Mapping of XMPP error conditions to SIP response codes 1185 +------------------------------+---------------------+ 1186 | XMPP Error Condition | SIP Response Code | 1187 +------------------------------+---------------------+ 1188 | | 400 | 1189 | | 400 | 1190 | | 501 | 1191 | | 403 | 1192 | | 410 | 1193 | | 500 | 1194 | | 404 | 1195 | | 484 | 1196 | | 406 | 1197 | | 405 | 1198 | | 401 | 1199 | | 402 | 1200 | | 480 | 1201 | | 300 | 1202 | | 407 | 1203 | | 502 | 1204 | | 504 | 1205 | | 500 | 1206 | | 503 | 1207 | | 407 | 1208 | | 400 | 1209 | | 491 | 1210 +------------------------------+---------------------+ 1212 7.2. SIP to XMPP 1214 The mapping of SIP response codes to XMPP error conditions SHOULD be 1215 as follows (note that XMPP does not include 100-series or 200-series 1216 response codes, only error conditions): 1218 Table 9: Mapping of SIP response codes to XMPP error conditions 1219 +---------------------+------------------------------+ 1220 | SIP Response Code | XMPP Error Condition | 1221 +---------------------+------------------------------+ 1222 | 300 | | 1223 | 301 | | 1224 | 302 | | 1225 | 305 | | 1226 | 380 | | 1227 | 400 | | 1228 | 401 | | 1229 | 402 | | 1230 | 403 | | 1231 | 404 | | 1232 | 405 | | 1233 | 406 | | 1234 | 407 | | 1235 | 408 | | 1236 | 410 | | 1237 | 413 | | 1238 | 414 | | 1239 | 415 | | 1240 | 416 | | 1241 | 420 | | 1242 | 421 | | 1243 | 423 | | 1244 | 480 | | 1245 | 481 | | 1246 | 482 | | 1247 | 483 | | 1248 | 484 | | 1249 | 485 | | 1250 | 486 | | 1251 | 487 | | 1252 | 488 | | 1253 | 491 | | 1254 | 493 | | 1255 | 500 | | 1256 | 501 | | 1257 | 502 | | 1258 | 503 | | 1259 | 504 | | 1260 | 505 | | 1261 | 513 | | 1262 | 600 | | 1263 | 603 | | 1264 | 604 | | 1265 | 606 | | 1266 +---------------------+------------------------------+ 1268 8. Security Considerations 1270 Detailed security considerations for instant messaging and presence 1271 protocols are given in [IMP-REQS], specifically in Sections 5.1 1272 through 5.4. Detailed security considerations for XMPP are given in 1273 [XMPP-CORE]. Detailed security considerations for SIP-based 1274 messaging are given in [SIP-IM] and for SIP-based presence are given 1275 in [SIP-PRES] (see also the security considerations for the Session 1276 Initiation Protocol given in [SIP]). 1278 This document specifies methods for exchanging instant messages and 1279 presence information through a gateway that translates between SIP 1280 and XMPP. Such a gateway MUST be compliant with the minimum security 1281 requirements of the instant messaging and presence protocols for 1282 which it translates (i.e., SIP and XMPP). The introduction of 1283 gateways to the security model of instant messaging and presence 1284 specified in [IMP-REQS] introduces some new risks. In particular, 1285 end-to-end security properties (especially confidentiality and 1286 integrity) between instant messaging and presence user agents that 1287 interface through a SIMPLE-XMPP gateway can be provided only if 1288 common formats are supported. Specification of those common formats 1289 is out of scope for this document, although it is recommended to use 1290 [MSGFMT] for instant messages and [PIDF] for presence. 1292 [IMP-REQS] requires that conformant technologies shall include 1293 methods for blocking communications from unwanted addresses. Such 1294 blocking is the responsibility of conformant technology (e.g., XMPP 1295 or SIP) and is out of scope for this memo. 1297 The mismatch between long-lived XMPP presence subscriptions and 1298 short-lived SIP presence subscriptions introduces the possibility of 1299 an amplification attack launched from the XMPP network against a SIP 1300 presence server. To help prevent such an attack, access to an XMPP- 1301 SIMPLE gateway that is hosted on the XMPP network SHOULD be 1302 restricted to XMPP users associated with a single domain or trust 1303 realm (e.g., a gateway hosted at simple.example.com should allow only 1304 users within the example.com domain to access the gateway, not users 1305 within example.org, example.net, or any other domain); if a SIP 1306 presence server receives communications through an XMPP-SIMPLE 1307 gateway from users who are not associated with a domain that is so 1308 related to the hostname of the gateway, it MAY (based on local 1309 service provisioning) refuse to service such users or refuse to 1310 communicate with the gateway. Furthermore, whenever an XMPP-SIMPLE 1311 gateway seeks to refresh an XMPP user's long-lived subscription to a 1312 SIP user's presence, it MUST first send an XMPP stanza of 1313 type "probe" from the address of the gateway to the "bare JID" 1314 (user@domain.tld) of the XMPP user, to which the user's XMPP server 1315 MUST respond in accordance with [XMPP-IM]; however, the administrator 1316 of an XMPP-SIMPLE gateway MAY (based on local service provisioning) 1317 exempt "known good" XMPP servers from this check (e.g., the XMPP 1318 server associated with the XMPP-SIMPLE gateway as described above). 1320 9. Acknowledgements 1322 The authors wish to thank Nathaniel Borenstein and Rohan Mahy for 1323 suggestions and encouragement; Daniel-Constantin Mierla for earlier 1324 work on SIMPLE-XMPP interworking; Jack Erwin, Tory Patnoe, and 1325 Sandeep Sharma for feedback based on implementation experience; and 1326 Dave Cridland, Johann Daigremont, Alan Johnston, Benny Prijono, and 1327 Adam Roach for their helpful comments. 1329 10. References 1331 10.1. Normative References 1333 [IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging 1334 and Presence", RFC 3861, August 2004. 1336 [PIDF] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 1337 W., and J. Peterson, "Presence Information Data Format 1338 (PIDF)", RFC 3863, August 2004. 1340 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1341 A., Peterson, J., Sparks, R., Handley, M., and E. 1342 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1343 June 2002. 1345 [SIP-EVENT] 1346 Roach, A., "Session Initiation Protocol (SIP)-Specific 1347 Event Notification", RFC 3265, June 2002. 1349 [SIP-IM] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1350 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1351 for Instant Messaging", RFC 3428, December 2002. 1353 [SIP-PRES] 1354 Rosenberg, J., "A Presence Event Package for the Session 1355 Initiation Protocol (SIP)", RFC 3856, August 2004. 1357 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1358 specifying the location of services (DNS SRV)", RFC 2782, 1359 February 2000. 1361 [STRINGPREP] 1362 Hoffman, P. and M. Blanchet, "Preparation of 1363 Internationalized Strings ("STRINGPREP")", RFC 3454, 1364 December 2002. 1366 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 1367 Requirement Levels", BCP 14, RFC 2119, March 1997. 1369 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1370 Resource Identifier (URI): Generic Syntax", STD 66, 1371 RFC 3986, January 2005. 1373 [URL-GUIDE] 1374 Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 1375 Registration Procedures for New URI Schemes", RFC 4395, 1376 February 2006. 1378 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 1379 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- 1380 xml, October 2000, . 1382 [XML-NAMES] 1383 Bray, T., Hollander, D., and A. Layman, "Namespaces in 1384 XML", W3C REC-xml-names, January 1999, 1385 . 1387 [XMPP-CORE] 1388 Saint-Andre, P., "Extensible Messaging and Presence 1389 Protocol (XMPP): Core", RFC 3920, October 2004. 1391 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 1392 Protocol (XMPP): Instant Messaging and Presence", 1393 RFC 3921, October 2004. 1395 10.2. Informative References 1397 [CPIM] Peterson, J., "Common Profile for Instant Messaging 1398 (CPIM)", RFC 3860, August 2004. 1400 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 1401 RFC 3859, August 2004. 1403 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 1404 "Internationalizing Domain Names in Applications (IDNA)", 1405 RFC 3490, March 2003. 1407 [IMP-REQS] 1408 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 1409 / Presence Protocol Requirements", RFC 2779, 1410 February 2000. 1412 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1413 April 2001. 1415 [XEP-0071] 1416 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, January 2006. 1418 [XEP-0106] 1419 Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF 1420 XEP 0106, May 2005. 1422 [MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant 1423 Messaging (CPIM): Message Format", RFC 3862, August 2004. 1425 [SIMPLE-CPIM] 1426 Rosenberg, J. and B. Campbell, "CPIM Mapping of SIMPLE 1427 Presence and Instant Messaging", 1428 draft-ietf-simple-cpim-mapping-01 (work in progress), 1429 June 2002. 1431 [XMPP-CPIM] 1432 Saint-Andre, P., "Mapping the Extensible Messaging and 1433 Presence Protocol (XMPP) to Common Presence and Instant 1434 Messaging (CPIM)", RFC 3922, October 2004. 1436 Authors' Addresses 1438 Peter Saint-Andre 1439 XMPP Standards Foundation 1440 P.O. Box 1641 1441 Denver, CO 80201 1442 USA 1444 Email: stpeter@jabber.org 1446 Avshalom Houri 1447 IBM 1448 Building 18/D, Kiryat Weizmann Science Park 1449 Rehovot 76123 1450 Israel 1452 Email: avshalom@il.ibm.com 1453 Joe Hildebrand 1454 Jabber, Inc. 1455 1899 Wynkoop Street, Suite 600 1456 Denver, CO 80202 1457 USA 1459 Email: jhildebrand@jabber.com 1461 Full Copyright Statement 1463 Copyright (C) The IETF Trust (2007). 1465 This document is subject to the rights, licenses and restrictions 1466 contained in BCP 78, and except as set forth therein, the authors 1467 retain all their rights. 1469 This document and the information contained herein are provided on an 1470 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1471 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1472 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1473 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1474 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1475 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1477 Intellectual Property 1479 The IETF takes no position regarding the validity or scope of any 1480 Intellectual Property Rights or other rights that might be claimed to 1481 pertain to the implementation or use of the technology described in 1482 this document or the extent to which any license under such rights 1483 might or might not be available; nor does it represent that it has 1484 made any independent effort to identify any such rights. Information 1485 on the procedures with respect to rights in RFC documents can be 1486 found in BCP 78 and BCP 79. 1488 Copies of IPR disclosures made to the IETF Secretariat and any 1489 assurances of licenses to be made available, or the result of an 1490 attempt made to obtain a general license or permission for the use of 1491 such proprietary rights by implementers or users of this 1492 specification can be obtained from the IETF on-line IPR repository at 1493 http://www.ietf.org/ipr. 1495 The IETF invites any interested party to bring to its attention any 1496 copyrights, patents or patent applications, or other proprietary 1497 rights that may cover technology that may be required to implement 1498 this standard. Please address the information to the IETF at 1499 ietf-ipr@ietf.org. 1501 Acknowledgment 1503 Funding for the RFC Editor function is provided by the IETF 1504 Administrative Support Activity (IASA).