idnits 2.17.1 draft-ietf-stox-presence-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 30, 2013) is 3860 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-stox-core-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track A. Houri 5 Expires: April 3, 2014 IBM 6 J. Hildebrand 7 Cisco Systems, Inc. 8 September 30, 2013 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Presence 12 draft-ietf-stox-presence-05 14 Abstract 16 This document defines a bi-directional protocol mapping for the 17 exchange of presence information between the Session Initiation 18 Protocol (SIP) and the Extensible Messaging and Presence Protocol 19 (XMPP). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 3, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2.1. Establishing . . . . . . . . . . . . . . . . . . . . . 4 61 3.2.2. Refreshing . . . . . . . . . . . . . . . . . . . . . . 7 62 3.2.3. Cancelling . . . . . . . . . . . . . . . . . . . . . . 7 63 3.3. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.3.1. Establishing . . . . . . . . . . . . . . . . . . . . . 8 65 3.3.2. Refreshing . . . . . . . . . . . . . . . . . . . . . . 10 66 3.3.3. Cancelling . . . . . . . . . . . . . . . . . . . . . . 12 67 4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.2. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.3. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 16 71 5. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 5.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 18 73 5.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 19 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 82 1. Introduction 84 In order to help ensure interworking between presence systems that 85 conform to the instant message / presence requirements [RFC2779], it 86 is important to clearly define protocol mappings between such 87 systems. Within the IETF, work has proceeded on two presence 88 technologies: 90 o Various extensions to the Session Initiation Protocol ([RFC3261]) 91 for instant messaging, as developed within the SIP for Instant 92 Messaging and Presence Leveraging Extensions (SIMPLE) Working 93 Group; the relevant specification for presence is [RFC3856] 95 o The Extensible Messaging and Presence Protocol (XMPP), which 96 consists of a formalization of the core XML streaming protocols 97 developed originally by the Jabber open-source community; the 98 relevant specifications are [RFC6120] for the XML streaming layer 99 and [RFC6121] for basic presence and instant messaging extensions 101 One approach to helping ensure interworking between these protocols 102 is to map each protocol to the abstract semantics described in 103 [RFC3860]; that is the approach taken by both [RFC3922] and 104 [I-D.ietf-simple-cpim-mapping]. The approach taken in this document 105 is to directly map semantics from one protocol to another (i.e., from 106 SIP/SIMPLE to XMPP and vice-versa). 108 The architectural assumptions underlying such direct mappings are 109 provided in [I-D.ietf-stox-core], including mapping of addresses and 110 error conditions. The mappings specified in this document cover 111 basic presence functionality. Mapping of more advanced functionality 112 (e.g., so-called "rich presence") is out of scope for this document. 114 SIP and XMPP differ significantly in their presence subscription 115 models, since SIP subscriptions are short-lived (requiring relatively 116 frequent refreshes even during a presence session) whereas XMPP 117 subscriptions last across presence sessions until they are explicitly 118 cancelled. This document provides suggestions for bridging the gap 119 between these very different models. 121 The discussion venue for this document is the mailing list of the 122 STOX WG; visit https://www.ietf.org/mailman/listinfo/stox for 123 subscription information and discussion archives. 125 2. Terminology 127 A number of terms used here are explained in [RFC3261], [RFC3856], 128 [RFC6120], and [RFC6121]. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 [RFC2119]. 135 3. Subscriptions 137 3.1. Overview 139 Both XMPP and presence-aware SIP systems enable entities (often but 140 not necessarily human users) to subscribe to the presence of other 141 entities. XMPP presence subscriptions are specified in [RFC6121]. 142 Presence subscriptions using a SIP event package for presence are 143 specified in [RFC3856]. 145 As described in [RFC6121], XMPP presence subscriptions are managed 146 using XMPP presence stanzas of type "subscribe", "subscribed", 147 "unsubscribe", and "unsubscribed". The main subscription states are 148 "none" (neither the user nor the contact is subscribed to the other's 149 presence information), "from" (the user has a subscription from the 150 contact), "to" (the user has a subscription to the contact's presence 151 information), and "both" (both user and contact are subscribed to 152 each other's presence information). 154 As described in [RFC3856], SIP presence subscriptions are managed 155 through the use of SIP SUBSCRIBE events sent from a SIP user agent to 156 an intended recipient who is most generally referenced by a Presence 157 URI of the form but who might be referenced by a 158 SIP or SIPS URI of the form or . 160 The subscription models underlying XMPP and SIP are quite different. 161 For instance, XMPP presence subscriptions are long-lived (indeed 162 permanent if not explicitly cancelled), whereas SIP presence 163 subscriptions are short-lived (the default time-to-live of a SIP 164 presence subscription is 3600 seconds, as specified in Section 6.4 of 165 [RFC3856]). These differences are addressed below. 167 3.2. XMPP to SIP 169 3.2.1. Establishing 171 An XMPP user (e.g., juliet@example.com) initiates a subscription by 172 sending a subscription request to another entity (e.g., 173 romeo@example.net), and the other entity (conventionally called a 174 "contact") either accepts or declines the request. If the contact 175 accepts the request, the user will have a subscription to the 176 contact's presence information until (1) the user unsubscribes or (2) 177 the contact cancels the subscription. The subscription request is 178 encapsulated in a presence stanza of type "subscribe": 180 Example 1: XMPP user subscribes to SIP contact: 182 | 186 Upon receiving such a presence stanza, the XMPP server to which 187 Juliet has connected needs to determine the identity of the 188 domainpart in the 'to' address, which it does by following the 189 procedures discussed in [I-D.ietf-stox-core]. Here we assume that 190 the XMPP server has determined the domain is serviced by a SIMPLE 191 server, that it contains or has available to it an XMPP-SIMPLE 192 gateway or connection manager (which enables it to speak natively to 193 SIMPLE servers), and that it hands off the presence stanza to the 194 XMPP-SIMPLE gateway. 196 The XMPP-SIMPLE gateway is then responsible for translating the XMPP 197 subscription request into a SIP SUBSCRIBE request from the XMPP user 198 to the SIP user: 200 Example 2: XMPP user subscribes to SIP contact (SIP transformation): 202 | SUBSCRIBE sip:romeo@example.net SIP/2.0 203 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk 204 | From: ;tag=ffd2 205 | Call-ID: l04th3s1p@example.com 206 | Event: presence 207 | Max-Forwards: 70 208 | CSeq: 123 SUBSCRIBE 209 | Contact: 210 | Accept: application/pidf+xml 211 | Expires: 3600 212 | Content-Length: 0 214 The SIP user then SHOULD send a response indicating acceptance of the 215 subscription request: 217 Example 3: SIP accepts subscription request: 219 | SIP/2.0 200 OK 220 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk 221 | From: ;tag=ffd2 222 | To: ;tag=j89d 223 | Call-ID: l04th3s1p@example.com 224 | CSeq: 234 SUBSCRIBE 225 | Contact: 226 | Expires: 3600 227 | Content-Length: 0 229 In accordance with [RFC6665], the XMPP-SIMPLE gateway SHOULD consider 230 the subscription state to be "neutral" until it receives a NOTIFY 231 message. Therefore the SIP user or SIP-XMPP gateway at the SIP 232 user's domain SHOULD immediately send a NOTIFY message containing a 233 "Subscription-State" header whose value contains the string "active" 234 (see Section 4). 236 Example 4: SIP user sends presence notification: 238 | NOTIFY sip:192.0.2.1 SIP/2.0 239 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 240 | From: ;tag=yt66 241 | To: ;tag=bi54 242 | Call-ID: l04th3s1p@example.com 243 | Event: presence 244 | Subscription-State: active;expires=499 245 | Max-Forwards: 70 246 | CSeq: 8775 NOTIFY 247 | Contact: 248 | Content-Type: application/pidf+xml 249 | Content-Length: 193 250 | 251 | 252 | 254 | 255 | 256 | open 257 | away 258 | 259 | 260 | 262 In response, the SIMPLE-XMPP gateway would send a 200 OK (not shown 263 here since it is not translated into an XMPP stanza). 265 Upon receiving the first NOTIFY with a subscription state of active, 266 the XMPP-SIMPLE gateway MUST generate a presence stanza of type 267 "subscribed": 269 Example 5: XMPP user receives acknowledgement from SIP contact: 271 | 275 As described under Section 4, the gateway MUST also generate a 276 presence notification to the XMPP user: 278 Example 6: XMPP user receives presence notification from SIP contact: 280 | 283 3.2.2. Refreshing 285 It is the responsibility of the XMPP-SIMPLE gateway to set the value 286 of the "Expires" header and to periodically renew the subscription on 287 the SIMPLE side of the gateway so that the subscription appears to be 288 permanent to the XMPP user (e.g., the XMPP-SIMPLE gateway SHOULD send 289 a new SUBSCRIBE request to the SIP user whenever the XMPP user sends 290 initial presence to its XMPP server, i.e., upon initiating a presence 291 session with the XMPP server). See the Security Considerations 292 (Section 7) of this document for important information and 293 requirements regarding the security implications of this 294 functionality. 296 3.2.3. Cancelling 298 At any time after subscribing, the XMPP user can unsubscribe from the 299 contact's presence. This is done by sending a presence stanza of 300 type "unsubscribe": 302 Example 7: XMPP user unsubscribes from SIP contact: 304 | 308 The XMPP-SIMPLE gateway is responsible for translating the 309 unsubscribe command into a SIP SUBSCRIBE request with the "Expires" 310 header set to a value of zero: 312 Example 8: XMPP user unsubscribes from SIP contact (SIP 313 transformation): 315 | SUBSCRIBE sip:romeo@example.net SIP/2.0 316 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk 317 | From: ;tag=j89d 318 | Call-ID: 1ckm32@example.com 319 | Event: presence 320 | Max-Forwards: 70 321 | CSeq: 789 SUBSCRIBE 322 | Contact: 323 | Accept: application/pidf+xml 324 | Expires: 0 325 | Content-Length: 0 327 Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway 328 SHOULD send a presence stanza of type "unsubscribed" to the XMPP 329 user: 331 Example 9: XMPP user receives unsubscribed notification: 333 | 337 3.3. SIP to XMPP 339 3.3.1. Establishing 341 A SIP user initiates a subscription to a contact's presence 342 information by sending a SIP SUBSCRIBE request to the contact. The 343 following is an example of such a request: 345 Example 10: SIP user subscribes to XMPP contact: 347 | SUBSCRIBE sip:juliet@example.com SIP/2.0 348 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk 349 | From: ;tag=xfg9 350 | Call-ID: 4wcm0n@example.net 351 | Event: presence 352 | Max-Forwards: 70 353 | CSeq: 263 SUBSCRIBE 354 | Contact: 355 | Accept: application/pidf+xml 356 | Content-Length: 0 358 Notice that the "Expires" header was not included in the SUBSCRIBE 359 request; this means that the default value of 3600 (i.e., 3600 360 seconds = 1 hour) applies. 362 Upon receiving the SUBSCRIBE, the SIP server needs to determine the 363 identity of the domain portion of the Request-URI or To header, which 364 it does by following the procedures discussed in 365 [I-D.ietf-stox-core]. Here we assume that the SIP server has 366 determined that the domain is serviced by an XMPP server, that it 367 contains or has available to it a SIP-to-XMPP gateway or connection 368 manager (which enables it to speak natively to XMPP servers), and 369 that it hands off the message to the gateway. 371 The SIP-to-XMPP gateway is then responsible for translating the 372 SUBSCRIBE into an XMPP subscription request from the SIP user to the 373 XMPP user: 375 Example 11: SIP user subscribes to XMPP contact (XMPP 376 transformation): 378 | 382 In accordance with [RFC6121], the XMPP user's server MUST deliver the 383 presence subscription request to the XMPP user (or, if a subscription 384 already exists in the XMPP user's roster, discard the subscribe 385 request). 387 If the XMPP user approves the subscription request, the XMPP server 388 then MUST return a presence stanza of type "subscribed" from the XMPP 389 user to the SIP user; if a subscription already exists, the XMPP 390 server SHOULD auto-reply with a presence stanza of type "subscribed". 391 In any case, if the SIMPLE-XMPP gateway receives a presence stanza of 392 type "subscribed" from the XMPP user, it SHOULD silently discard the 393 stanza. 395 If the XMPP user declines the subscription request, the XMPP server 396 then MUST return a presence stanza of type "unsubscribed" from the 397 XMPP user to the SIP user and the XMPP-SIMPLE gateway MUST transform 398 that stanza into an empty SIP NOTIFY message with a Subscription- 399 State of "terminated" and a reason of "rejected": 401 Example 12: SIP subscription request rejected: 403 | NOTIFY sip:192.0.2.2 SIP/2.0 404 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk 405 | From: ;tag=ur93 406 | To: ;tag=pq72 407 | Call-ID: 4wcm0n@example.net 408 | Event: presence 409 | Subscription-State: terminated;reason=rejected 410 | Max-Forwards: 70 411 | CSeq: 232 NOTIFY 412 | Contact: 413 | Content-Type: application/pidf+xml 414 | Content-Length: 0 416 3.3.2. Refreshing 418 For as long as a SIP user is online and interested in receiving 419 presence notifications from the XMPP users, the user's SIP user agent 420 is responsible for periodically refreshing the subscription by 421 sending an updated SUBSCRIBE request with an appropriate value for 422 the Expires header. In response, the SIMPLE-XMPP gateway MUST send a 423 SIP NOTIFY to the user agent (per [RFC6665]; if the gateway has 424 meaningful information about the availability state of the XMPP user 425 then the NOTIFY MUST communicate that information (e.g., by including 426 a PIDF body [RFC3863] with the relevant data), whereas if the gateway 427 does not have meaningful information about the availability state of 428 the XMPP user then the NOTIFY MUST be empty as allowed by [RFC6665]. 430 Once the SIP user goes offline at the end of a presence session, it 431 is the responsibility of the SIMPLE-XMPP gateway to properly handle 432 the difference between short-lived SIP presence subscriptions and 433 long-lived XMPP presence subscriptions. The gateway has two options 434 when the SIP user's subscription expires: 436 o Cancel the subscription (i.e., treat it as temporary) and send an 437 XMPP presence stanza of type "unsubscribe" to the XMPP contact; 438 this honors the SIP semantic but will seem rather odd to the XMPP 439 contact. 441 o Maintain the subscription (i.e., treat it as long-lived) and (1) 442 send a SIP NOTIFY request to the SIP user containing a PIDF 443 document specifying that the XMPP contact now has a basic status 444 of "closed", including a Subscription-State of "terminated" with a 445 reason of "timeout" and (2) send an XMPP presence stanza of type 446 "unavailable" to the XMPP contact; this violates the letter of the 447 SIP semantic but will seem more natural to the XMPP contact. 449 Which of these options the SIMPLE-XMPP gateway chooses is up to the 450 implementation. 452 If the implementation chooses the first option, the protocol 453 generated would be as follows: 455 Example 13: SIP subscription expires (treated as temporary by 456 gateway): 458 | 462 If the implementation chooses the second option, the protocol 463 generated would be as follows: 465 Example 14: SIP subscription expires (treated as long-lived by 466 gateway): 468 | NOTIFY sip:192.0.2.2 SIP/2.0 469 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk 470 | From: ;tag=ur93 471 | To: ;tag=pq72 472 | Call-ID: j4s0h4vny@example.com 473 | Event: presence 474 | Subscription-State: terminated;reason=timeout 475 | Max-Forwards: 70 476 | CSeq: 232 NOTIFY 477 | Contact: 478 | Content-Type: application/pidf+xml 479 | Content-Length: 194 480 | 481 | 482 | 484 | 485 | 486 | closed 487 | 488 | 489 | 491 Example 15: SIP subscription expires (treated as long-lived by 492 gateway): 494 | 498 3.3.3. Cancelling 500 At any time, the SIP user can cancel the subscription by sending a 501 SUBSCRIBE message whose "Expires" header is set to a value of zero 502 ("0"): 504 Example 16: SIP user cancels subscription: 506 | SUBSCRIBE sip:juliet@example.com SIP/2.0 507 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 508 | From: ;tag=yt66 509 | Call-ID: 1tsn1ce@example.net 510 | Event: presence 511 | Max-Forwards: 70 512 | CSeq: 8775 SUBSCRIBE 513 | Contact: 514 | Expires: 0 515 | Content-Length: 0 517 As above, upon receiving such a request, a SIMPLE-XMPP gateway is 518 responsible for doing one of the following: 520 o Cancel the subscription (i.e., treat it as temporary) and send an 521 XMPP presence stanza of type "unsubscribe" to the XMPP contact. 523 o Maintain the subscription (i.e., treat it as long-lived) and (1) 524 send a SIP NOTIFY request to the SIP user containing a PIDF 525 document specifying that the XMPP contact now has a basic status 526 of "closed", (2) send a SIP SUBSCRIBE request to the SIP user with 527 an "Expires" header set to a value of "0" (zero) when it receives 528 XMPP presence of type "unavailable" from the XMPP contact, and (3) 529 send an XMPP presence stanza of type "unavailable" to the XMPP 530 contact. 532 4. Notifications 534 4.1. Overview 536 Both XMPP and presence-aware SIP systems enable entities (often but 537 not necessarily human users) to send presence notifications to other 538 entities. At a minimum, the term "presence" refers to information 539 about an entity's availability for communication on a network (on/ 540 off), often supplemented by information that further specifies the 541 entity's communications context (e.g., "do not disturb"). Some 542 systems and protocols extend this notion even further and refer to 543 any relatively ephemeral information about an entity as a kind of 544 presence; categories of such "extended presence" include geographical 545 location (e.g., GPS coordinates), user mood (e.g., grumpy), user 546 activity (e.g., walking), and ambient environment (e.g., noisy). In 547 this document, we focus on the "least common denominator" of network 548 availability only, although future documents might address broader 549 notions of presence, including extended presence. 551 [RFC6121] defines how XMPP presence stanzas can indicate availability 552 (via absence of a 'type' attribute) or lack of availability (via a 553 'type' attribute with a value of "unavailable"). SIP presence using 554 a SIP event package for presence is specified in [RFC3856]. 556 As described in [RFC6121], presence information about an entity is 557 communicated by means of an XML stanza sent over an XML 558 stream. In this document we will assume that such a presence stanza 559 is sent from an XMPP client to an XMPP server over an XML stream 560 negotiated between the client and the server, and that the client is 561 controlled by a human user (again, this is a simplifying assumption 562 introduced for explanatory purposes only). In general, XMPP presence 563 is sent by the user to the user's server and then broadcasted to all 564 entities who are subscribed to the user's presence information. 566 As described in [RFC3856], presence information about an entity is 567 communicated by means of a SIP NOTIFY event sent from a SIP user 568 agent to an intended recipient who is most generally referenced by an 569 Presence URI of the form but who might be 570 referenced by a SIP or SIPS URI of the form or 571 . Here again we introduce the simplifying 572 assumption that the user agent is controlled by a human user. 574 This document addresses basic presence or network availability only, 575 not the various extensions to SIP and XMPP for "rich presence", such 576 as [RFC4480], [XEP-0107], and [XEP-0108]. 578 4.2. XMPP to SIP 580 When Juliet interacts with her XMPP client to modify her presence 581 information (or when her client automatically updates her presence 582 information, e.g. via an "auto-away" feature), her client generates 583 an XMPP stanza. The syntax of the stanza, 584 including required and optional elements and attributes, is defined 585 in [RFC6121]. The following is an example of such a stanza: 587 Example 17: XMPP user sends presence notification: 589 | 591 Upon receiving such a stanza, the XMPP server to which Juliet has 592 connected broadcasts it to all subscribers who are authorized to 593 receive presence notifications from Juliet (this is similar to the 594 SIP NOTIFY method). For each subscriber, broadcasting the presence 595 notification involves either delivering it to a local recipient (if 596 the hostname in the subscriber's address matches one of the hostnames 597 serviced by the XMPP server) or attempting to route it to the foreign 598 domain that services the hostname in the subscriber's address. Thus 599 the XMPP server needs to determine the identity of the domainpart in 600 the 'to' address, which it does by following the procedures discussed 601 in [I-D.ietf-stox-core]. Here we assume that the XMPP server has 602 determined the domain is serviced by a SIMPLE server, that it 603 contains or has available to it an XMPP-SIMPLE gateway or connection 604 manager (which enables it to speak natively to SIMPLE servers), and 605 that it hands off the presence stanza to the XMPP-SIMPLE gateway. 607 The XMPP-SIMPLE gateway is then responsible for translating the XMPP 608 presence stanza into a SIP NOTIFY request and included PIDF document 609 from the XMPP user to the SIP user. 611 Example 18: XMPP user sends presence notification (SIP 612 transformation): 614 | NOTIFY sip:192.0.2.2 SIP/2.0 615 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk 616 | From: ;tag=gh19 617 | To: ;tag=yt66 618 | Contact: ;gr=balcony 619 | Call-ID: j4s0h4vny@example.com 620 | Event: presence 621 | Subscription-State: active;expires=599 622 | Max-Forwards: 70 623 | CSeq: 157 NOTIFY 624 | Contact: 625 | Content-Type: application/pidf+xml 626 | Content-Length: 192 627 | 628 | 629 | 631 | 632 | 633 | open 634 | away 635 | 636 | 637 | 639 The mapping of XMPP syntax elements to SIP syntax elements SHOULD be 640 as shown in the following table. (Mappings for elements not 641 mentioned are undefined.) 643 Table 1: Presence syntax mapping from XMPP to SIP 645 +-----------------------------+---------------------------+ 646 | XMPP Element or Attribute | SIP Header or PIDF Data | 647 +-----------------------------+---------------------------+ 648 | stanza | "Event: presence" (1) | 649 | XMPP resource identifer | tuple 'id' attribute (2) | 650 | from | From | 651 | id | CSeq (3) | 652 | to | To | 653 | type | basic status (4) (5) | 654 | xml:lang | Content-Language | 655 | | priority for tuple (6) | 656 | | no mapping (7) | 657 | | | 658 +-----------------------------+---------------------------+ 660 Note the following regarding these mappings: 662 1. Only a presence stanza that lacks a 'type' attribute or whose 663 'type' attribute has a value of "unavailable" SHOULD be mapped by 664 an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are 665 the only presence stanzas that represent notifications. 666 2. The PIDF schema defines the tuple 'id' attribute as having a 667 datatype of "xs:ID"; because this datatype is more restrictive 668 than the "xs:string" datatype for XMPP resourceparts (in 669 particular, a number is not allowed as the first character of an 670 ID), it is RECOMMENDED to prepend the resourcepart with "ID-" or 671 some other alphabetic string when mapping from XMPP to SIP. 672 3. This mapping is OPTIONAL. 673 4. Because the lack of a 'type' attribute indicates that an XMPP 674 entity is available for communications, the gateway SHOULD map 675 that information to a PIDF status of "open". Because a 676 'type' attribute with a value of "unavailable" indicates that an 677 XMPP entity is not available communications, the gateway SHOULD 678 map that information to a PIDF status of "closed". 679 5. When the XMPP-SIMPLE gateway receives XMPP presence of type 680 "unavailable" from the XMPP contact, it SHOULD (1) send a SIP 681 NOTIFY request to the SIP user containing a PIDF document 682 specifying that the XMPP contact now has a basic status of 683 "closed" and (2) send a SIP SUBSCRIBE request to the SIP user 684 with an "Expires" header set to a value of "0" (zero). 685 6. The value of the XMPP element is an integer between 686 -128 and +127, whereas the the value of the PIDF 687 element's 'priority' attribute is a decimal number from zero to 688 one inclusive, with a maximum of three decimal places. If the 689 value of the XMPP element is negative, an XMPP-SIMPLE 690 gateway MUST NOT map the value. If an XMPP-SIMPLE gateway maps 691 positive values, it SHOULD treat XMPP priority 0 as PIDF priority 692 0 and XMPP priority 127 as PIDF priority 1, mapping intermediate 693 values appropriately so that they are unique (e.g., XMPP priority 694 1 to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015, 695 and so on up through mapping XMPP priority 126 to PIDF priority 696 0.992; note that this is an example only, and that the exact 697 mapping is up to the implementation). 698 7. Some implementations support custom extensions to encapsulate 699 this information; however, there is no need to standardize a PIDF 700 extension for this purpose, since PIDF is already extensible and 701 thus the element can be included directly, qualified by 702 the 'jabber:client' namespace in the PIDF XML. The examples in 703 this document illustrate this usage, which is RECOMMENDED. The 704 most useful values are likely "away" and "dnd", although note 705 that the latter value merely means "busy" and does not imply that 706 a server or client ought to block incoming traffic while the user 707 is in that state. 708 8. Some implementations support custom extensions to encapsulate 709 detailed information about availability; however, there is no 710 need to standardize a PIDF extension for this purpose, since PIDF 711 is already extensible and thus the element (qualified by 712 the 'jabber:client' namespace) can be included directly in the 713 PIDF XML. The examples in this document illustrate this usage, 714 which is RECOMMENDED. The most useful values are likely "away" 715 and "dnd", although note that the latter value merely means 716 "busy" and does not imply that a server or client ought to block 717 incoming traffic while the user is in that state. Naturally, a 718 gateway can choose to translate a custom extension into an 719 established value of the element [RFC6121], or translate 720 a element into a custom extension that the gateway knows 721 is supported by the user agent of the intended recipient. 722 Unfortunately, this behavior does not guarantee that information 723 will not be lost; to help prevent information loss, a gateway 724 ought to include both the element and the custom 725 extension if the gateway cannot suitably translate the custom 726 value into a value. 728 4.3. SIP to XMPP 730 When Romeo changes his presence, his SIP user agent generates a SIP 731 NOTIFY request for any active subscriptions. The syntax of the 732 NOTIFY request is defined in [RFC3856]. The following is an example 733 of such a request: 735 Example 19: SIP user sends presence notification: 737 | NOTIFY sip:192.0.2.1 SIP/2.0 738 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 739 | From: ;tag=yt66 740 | To: ;tag=bi54 741 | Contact: ;gr=orchard 742 | Call-ID: j0sj4sv1m@example.net 743 | Event: presence 744 | Subscription-State: active;expires=499 745 | Max-Forwards: 70 746 | CSeq: 8775 NOTIFY 747 | Contact: 748 | Content-Type: application/pidf+xml 749 | Content-Length: 193 750 | 751 | 752 | 754 | 755 | 756 | closed 757 | 758 | 759 | 761 Upon receiving the NOTIFY, the SIP server needs to determine the 762 identity of the domain portion of the Request-URI or To header, which 763 it does by following the procedures discussed in 764 [I-D.ietf-stox-core]. Here we assume that the SIP server has 765 determined that the domain is serviced by an XMPP server, that it 766 contains or has available to it a SIP-to-XMPP gateway or connection 767 manager (which enables it to speak natively to XMPP servers), and 768 that it hands off the message to the gateway. 770 The SIP-to-XMPP gateway is then responsible for translating the 771 NOTIFU into an XMPP presence stanza from the SIP user to the XMPP 772 user: 774 Example 20: SIP user sends presence notification (XMPP 775 transformation): 777 | 781 The mapping of SIP syntax elements to XMPP syntax elements SHOULD be 782 as shown in the following table. (Mappings for elements not 783 mentioned are undefined.) 785 Table 2: Presence syntax mapping from SIP to XMPP 787 +---------------------------+-----------------------------+ 788 | SIP Header or PIDF Data | XMPP Element or Attribute | 789 +---------------------------+-----------------------------+ 790 | basic status | type (1) | 791 | Content-Language | xml:lang | 792 | CSeq | id (2) | 793 | From | from | 794 | priority for tuple | (3) | 795 | To | to | 796 | | | 797 | | (4) | 798 +---------------------------+-----------------------------+ 800 Note the following regarding these mappings: 802 1. A PIDF basic status of "open" SHOULD be mapped to no 'type' 803 attribute, and a PIDF basic status of "closed" SHOULD be mapped 804 to a 'type' attribute whose value is "unavailable". 805 2. This mapping is OPTIONAL. 806 3. See the notes following Table 1 of this document regarding 807 mapping of presence priority. 808 4. If a SIP implementation supports the element (qualified 809 by the 'jabber:client' namespace) as a PIDF extension for 810 availability status as described in the notes following Table 1 811 of this document, the SIP-to-XMPP gateway is responsible for 812 including that element in the XMPP presence notification. 814 5. Requests 816 Both SIP and XMPP provide methods for requesting presence information 817 about another entity. 819 5.1. XMPP to SIP 821 In XMPP, a request for presence information is completed by sending a 822 presence stanza of type "probe": 824 Example 21: XMPP server sends presence probe on behalf of XMPP user: 826 | 829 Note: As described in [RFC6121], presence probes are used by XMPP 830 servers to request presence on behalf of XMPP users; XMPP clients are 831 discouraged from sending presence probes since retrieving presence is 832 a service that servers provide. 834 An XMPP-SIMPLE gateway would transform the presence probe into its 835 SIP equivalent, which is a SUBSCRIBE request with an Expires header 836 value of zero: 838 Example 22: Presence probe (SIP transformation): 840 | SUBSCRIBE sip:romeo@example.net SIP/2.0 841 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk 842 | From: ;tag=ffd2 843 | Call-ID: l04th3s1p@example.com 844 | Event: presence 845 | Max-Forwards: 70 846 | CSeq: 123 SUBSCRIBE 847 | Contact: 848 | Accept: application/pidf+xml 849 | Expires: 0 850 | Content-Length: 0 852 As described in [RFC3856], this cancels any subscription but causes a 853 NOTIFY to be sent to the subscriber, just as a presence probe does 854 (the transformation rules for presence notifications have been 855 previously described in this document). 857 5.2. SIP to XMPP 859 In SIP, a request for presence information is effectively completed 860 by sending a SUBSCRIBE with an Expires header value of zero: 862 Example 23: SIP user sends presence request: 864 | SUBSCRIBE sip:juliet@example.com SIP/2.0 865 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk 866 | From: ;tag=yt66 867 | Call-ID: 1tsn1ce@example.net 868 | Event: presence 869 | Max-Forwards: 70 870 | CSeq: 8775 SUBSCRIBE 871 | Contact: 872 | Expires: 0 873 | Content-Length: 0 875 When honoring the long-lived semantics of an XMPP presence 876 subscription, a SIMPLE-XMPP gateway SHOULD translate such a SIP 877 request into a presence stanza of type 'probe' if it does not already 878 have presence information about the subscribee: 880 Example 24: SIP user requests XMPP presence (XMPP transformation): 882 | 886 6. IANA Considerations 888 This document makes no requests of IANA. 890 7. Security Considerations 892 Detailed security considerations for presence protocols are given in 893 [RFC2779], for SIP-based presence in [RFC3856] (see also [RFC3261]), 894 and for XMPP-based presence in [RFC6121] (see also [RFC6120]). 896 The mismatch between long-lived XMPP presence subscriptions and 897 short-lived SIP presence subscriptions introduces the possibility of 898 an amplification attack launched from the XMPP network against a SIP 899 presence server. To help prevent such an attack, access to an XMPP- 900 SIMPLE gateway that is hosted on the XMPP network SHOULD be 901 restricted to XMPP users associated with a single domain or trust 902 realm (e.g., a gateway hosted at simple.example.com ought to allow 903 only users within the example.com domain to access the gateway, not 904 users within example.org, example.net, or any other domain); if a SIP 905 presence server receives communications through an XMPP-SIMPLE 906 gateway from users who are not associated with a domain that is so 907 related to the hostname of the gateway, it MAY (based on local 908 service provisioning) refuse to service such users or refuse to 909 communicate with the gateway. Furthermore, whenever an XMPP-SIMPLE 910 gateway seeks to refresh an XMPP user's long-lived subscription to a 911 SIP user's presence, it MUST first send an XMPP stanza of 912 type "probe" from the address of the gateway to the "bare JID" 913 (user@domain.tld) of the XMPP user, to which the user's XMPP server 914 MUST respond in accordance with [RFC6121]; however, the administrator 915 of an XMPP-SIMPLE gateway MAY (based on local service provisioning) 916 exempt "known good" XMPP servers from this check (e.g., the XMPP 917 server associated with the XMPP-SIMPLE gateway as described above). 919 8. References 920 8.1. Normative References 922 [I-D.ietf-stox-core] 923 Saint-Andre, P., Houri, A., and J. Hildebrand, 924 "Interworking between the Session Initiation Protocol 925 (SIP) and the Extensible Messaging and Presence Protocol 926 (XMPP): Core", draft-ietf-stox-core-06 (work in progress), 927 September 2013. 929 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 930 Requirement Levels", BCP 14, RFC 2119, March 1997. 932 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 933 A., Peterson, J., Sparks, R., Handley, M., and E. 934 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 935 June 2002. 937 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 938 Initiation Protocol (SIP)", RFC 3856, August 2004. 940 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 941 Protocol (XMPP): Core", RFC 6120, March 2011. 943 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 944 Protocol (XMPP): Instant Messaging and Presence", 945 RFC 6121, March 2011. 947 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 948 July 2012. 950 8.2. Informative References 952 [I-D.ietf-simple-cpim-mapping] 953 Rosenberg, J. and B. Campbell, "CPIM Mapping of SIMPLE 954 Presence and Instant Messaging", 955 draft-ietf-simple-cpim-mapping-01 (work in progress), 956 June 2002. 958 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 959 / Presence Protocol Requirements", RFC 2779, 960 February 2000. 962 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 963 (CPIM)", RFC 3860, August 2004. 965 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 966 W., and J. Peterson, "Presence Information Data Format 967 (PIDF)", RFC 3863, August 2004. 969 [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and 970 Presence Protocol (XMPP) to Common Presence and Instant 971 Messaging (CPIM)", RFC 3922, October 2004. 973 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 974 Rosenberg, "RPID: Rich Presence Extensions to the Presence 975 Information Data Format (PIDF)", RFC 4480, July 2006. 977 [XEP-0107] 978 Saint-Andre, P. and R. Meijer, "User Mood", XSF XEP 0107, 979 October 2008. 981 [XEP-0108] 982 Meijer, R. and P. Saint-Andre, "User Activity", XSF 983 XEP 0108, October 2008. 985 Appendix A. Acknowledgements 987 The authors wish to thank the following individuals for their 988 feedback: Chris Christou, Fabio Forno, Adrian Georgescu, Philipp 989 Hancke, Saul Ibarra Corretge, Markus Isomaki, Paul Kyzivat, Salvatore 990 Loreto, Michael Lundberg, Daniel-Constantin Mierla, and Tory Patnoe. 992 Some text in this document was borrowed from [RFC3922]. 994 Authors' Addresses 996 Peter Saint-Andre 997 Cisco Systems, Inc. 998 1899 Wynkoop Street, Suite 600 999 Denver, CO 80202 1000 USA 1002 Phone: +1-303-308-3282 1003 Email: psaintan@cisco.com 1005 Avshalom Houri 1006 IBM 1007 Rorberg Building, Pekris 3 1008 Rehovot 76123 1009 Israel 1011 Email: avshalom@il.ibm.com 1012 Joe Hildebrand 1013 Cisco Systems, Inc. 1014 1899 Wynkoop Street, Suite 600 1015 Denver, CO 80202 1016 USA 1018 Email: jhildebr@cisco.com