idnits 2.17.1
draft-ietf-stox-7248bis-14.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (November 3, 2016) is 2730 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)
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Filament
4 Obsoletes: 7248 (if approved) November 3, 2016
5 Intended status: Standards Track
6 Expires: May 7, 2017
8 Interworking between the Session Initiation Protocol (SIP) and the
9 Extensible Messaging and Presence Protocol (XMPP): Presence
10 draft-ietf-stox-7248bis-14
12 Abstract
14 This document defines a bidirectional protocol mapping for the
15 exchange of presence information between the Session Initiation
16 Protocol (SIP) and the Extensible Messaging and Presence Protocol
17 (XMPP). This document obsoletes RFC 7248.
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at http://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on May 7, 2017.
36 Copyright Notice
38 Copyright (c) 2016 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
54 2. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 4
55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
56 4. Architectural Assumptions . . . . . . . . . . . . . . . . . . 5
57 5. Presence Authorizations . . . . . . . . . . . . . . . . . . . 5
58 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
59 5.2. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 6
60 5.2.1. Requesting a Presence Authorization . . . . . . . . . 6
61 5.2.2. Refreshing a Notification Dialog . . . . . . . . . . 10
62 5.2.3. Cancelling a Presence Authorization . . . . . . . . . 11
63 5.3. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 14
64 5.3.1. Requesting a Presence Authorization . . . . . . . . . 14
65 5.3.2. Refreshing a Notification Dialog . . . . . . . . . . 18
66 5.3.3. Cancelling a Presence Authorization . . . . . . . . . 18
67 6. Notifications of Presence Information . . . . . . . . . . . . 19
68 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19
69 6.2. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 20
70 6.3. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 24
71 7. Polling for Presence Information . . . . . . . . . . . . . . 26
72 7.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 26
73 7.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 27
74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
75 9. Privacy and Security Considerations . . . . . . . . . . . . . 27
76 9.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 28
77 9.2. Presence Leaks . . . . . . . . . . . . . . . . . . . . . 28
78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
79 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
80 10.2. Informative References . . . . . . . . . . . . . . . . . 30
81 Appendix A. Changes from RFC 7248 . . . . . . . . . . . . . . . 31
82 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 32
83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
85 1. Introduction
87 Presence is information about the availability of an entity (such as
88 network availability or availability for communication). Presence
89 features in both SIP and XMPP involve several aspects:
91 o A long-lived authorization for a user to receive notifications
92 about a contact's presence across presence and notification
93 sessions; such an authorization is formally requested by the user,
94 approved (or not) by the contact, and often associated with a
95 record in an address list or "buddy list".
97 o An ephemeral presence session, during which the contact is online
98 (i.e., available for interaction) and after which the contact is
99 offline again.
101 o An ephemeral notification session, during which the user requests
102 presence notifications from the contact (these are implicit in
103 XMPP, but explicit in SIP where they are managed by means of
104 notification dialogs).
106 o Notifications that are sent from the contact to the user for the
107 life of either the contact's presence session or the user's
108 notification session.
110 Although specifications for both SIP and XMPP use the term
111 "subscription", they do so in different ways. In SIP, a
112 "subscription" is the specific mechanism whereby a subscriber (or an
113 entity acting on the subscriber's behalf, such as a server) requests
114 presence notifications from the contact over a relatively short
115 period of time, renewed as necessary to keep receiving presence
116 notifications during a presence session. By contrast, in XMPP a
117 "subscription" is essentially shorthand for a long-lived presence
118 authorization. To prevent confusion, this document uses the term
119 "notification dialog" for a SIP subscription and the term "presence
120 authorization" for an XMPP subscription.
122 In order to help ensure interworking between presence systems that
123 conform to the instant message / presence requirements [RFC2779], it
124 is important to clearly define protocol mappings between such
125 systems. Within the IETF, work has proceeded on two presence
126 technologies:
128 o Various extensions to the Session Initiation Protocol ([RFC3261])
129 for presence, in particular [RFC3856]
131 o The Extensible Messaging and Presence Protocol (XMPP), which
132 consists of a formalization of the core XML streaming protocols
133 developed originally by the Jabber open-source community; the
134 relevant specifications are [RFC6120] for the XML streaming layer
135 and [RFC6121] for basic presence and instant-messaging extensions
137 One approach to helping ensure interworking between these protocols
138 is to map each protocol to the abstract semantics described in
139 [RFC3860]; however, apparently that approach has never been
140 implemented. The approach taken in this document is to directly map
141 semantics from one protocol to another (i.e., from SIP/SIMPLE (SIP
142 for Instant Messaging and Presence Leveraging Extensions) to XMPP and
143 vice versa), because that is how existing systems solve the
144 interworking problem.
146 The architectural assumptions underlying such direct mappings are
147 provided in [RFC7247], including mapping of addresses and error
148 conditions. The mappings specified in this document cover basic
149 presence functionality. Mapping of more advanced functionality
150 (e.g., so-called "rich presence") is out of scope for this document.
152 This document obsoletes RFC 7248.
154 2. Intended Audience
156 The documents in this series (which include [RFC7247], [RFC7572],
157 [RFC7573], and [RFC7702]) are intended for use by software developers
158 who have an existing system based on one of these technologies (e.g.,
159 SIP) and would like to enable communication from that existing system
160 to systems based on the other technology (e.g., XMPP). We assume
161 that readers are familiar with the core specifications for both SIP
162 [RFC3261] and XMPP [RFC6120], with the base document for this series
163 [RFC7247], and with the following presence-related specifications:
165 o "A Presence Event Package for the Session Initiation Protocol"
166 [RFC3856]
168 o "Presence Information Data Format (PIDF)" [RFC3863]
170 o "Extensible Messaging and Presence Protocol (XMPP): Instant
171 Messaging and Presence" [RFC6121]
173 o "SIP-Specific Event Notification" [RFC6665]
175 3. Terminology
177 A number of terms used here (user, contact, notification, etc.) are
178 explained in [RFC3261], [RFC3856], [RFC3857], [RFC6120], and
179 [RFC6121]. This document uses some, but not all, of the presence-
180 related terms defined in the Model for Presence and Instant Messaging
181 [RFC2778]. In particular, the term "presence session" is used as
182 described in [RFC6121] to mean a delimited time period in which an
183 endpoint is online and available for communications.
185 In flow diagrams, SIP traffic is shown using arrows such as "***>",
186 whereas XMPP traffic is shown using arrows such as "...>". As in
187 [RFC7247], the terms "SIP to XMPP Gateway" and "XMPP to SIP Gateway"
188 are abbreviated as "S2X GW" and "X2S GW", respectively.
190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
192 "OPTIONAL" in this document are to be interpreted as described in
193 [RFC2119].
195 4. Architectural Assumptions
197 The fundamental architectural assumptions underlying SIP-XMPP
198 interworking are described in [RFC7247].
200 Note that, in SIP, there are two ways that presence services can be
201 deployed on the server side:
203 1. Under this model, described most fully in [RFC3857], a dedicated
204 SIP Presence Server handles events related to the presence event
205 package. Instead of forwarding a SUBSCRIBE message to the SIP
206 user, the Presence Server would inform the user of subscription
207 activity using the 'presence.winfo' event package. The SIP User
208 Agent would then authorize the subscribing contact through some
209 interaction with the Presence Server (for instance using XCAP
210 [RFC4825]). Therefore, presence updates from the SIP User Agent
211 would not be sent as NOTIFY messages to the XMPP user but as
212 PUBLISH messages to the Presence Server, which would then
213 generate NOTIFY messages to all active subscribers.
215 2. Under this model, a SIP Presence Server acts in proxy mode and
216 merely passes through the SUBSCRIBE and NOTIFY messages to the
217 SIP User Agent.
219 Because the behavior of the XMPP-to-SIP gateway is not changed by the
220 SIP architectural model that is used, the diagrams and protocol flows
221 in this document cover both options by labeling the end entity a "SIP
222 User Agent or Presence Server".
224 5. Presence Authorizations
226 5.1. Overview
228 Both XMPP and presence-aware SIP systems enable entities (often, but
229 not necessarily, human users) to subscribe to the presence of other
230 entities. XMPP presence is specified in [RFC6121]. Presence using a
231 SIP event package is specified in [RFC3856].
233 As described in [RFC6121], XMPP presence authorizations are managed
234 using XMPP stanzas of type "subscribe", "subscribed",
235 "unsubscribe", and "unsubscribed". The main states are:
237 o "none" (neither the user nor the contact is subscribed to the
238 other's presence information)
240 o "from" (the contact will receive presence notifications from the
241 user)
243 o "to" (the contact will send presence notifications to the user)
245 o "both" (both user and contact will receive each other's presence
246 notifications)
248 As described in [RFC3856], in SIP the subscriber does not explicitly
249 request the creation or removal of presence authorizations. Rather,
250 the authorizations are triggered by subscription activity. When a
251 SIP user receives an initial SIP SUBSCRIBE event from a contact, the
252 recipient's SIP User Agent or presence server notifies the user to
253 make an authorization policy decision. This decision is recorded in
254 the User Agent or in a Presence Server, so that in the future any
255 notification dialogs from the contact are automatically approved.
256 (Note that addresses for SIP users and contacts are most generally
257 referenced by a Presence URI of the form but might
258 be referenced by a SIP or SIPS (Session Initiation Protocol Secure)
259 URI of the form or ; because in
260 practice 'pres' URIs are rarely used, the examples in this document
261 use 'sip' URIs.)
263 In both SIP and XMPP, presence authorizations are long-lived (indeed
264 permanent if not explicitly cancelled). In SIP, by default a
265 notification session is typically short-lived unless explicitly
266 extended (the default time-to-live of a SIP notification dialog is
267 3600 seconds, as specified in Section 6.4 of [RFC3856], so that a
268 notification dialog needs to be explicitly refreshed in order for a
269 user's notification session to last as long as the contact's presence
270 session). In XMPP, a user's notification session with a contact is
271 almost always automatically handled by the user's server based on the
272 user's presence state (see [RFC6121] for details).
274 5.2. XMPP to SIP
276 5.2.1. Requesting a Presence Authorization
278 The following diagram illustrates the protocol flow necessary to
279 establish an authorization for an XMPP user to a receive presence
280 notifications from a SIP contact, as further explained in the text
281 and examples after the diagram.
283 XMPP XMPP SIP SIP UA or
284 Client Server Proxy Presence Server
285 | + X2S GW | |
286 | | | |
287 | (F1) XMPP | | |
288 | subscribe | | |
289 |...........>| | |
290 | | (F2) SIP | |
291 | | SUBSCRIBE | |
292 | |***********>| |
293 | | | (F3) SIP |
294 | | | SUBSCRIBE |
295 | | |***********>|
296 | | | (F4) SIP |
297 | | | 200 OK |
298 | | |<***********|
299 | | (F5) SIP | |
300 | | 200 OK | |
301 | |<***********| |
302 | | | (F6) SIP |
303 | | | NOTIFY |
304 | | | (pending) |
305 | | |<***********|
306 | | (F7) SIP | |
307 | | NOTIFY | |
308 | |<***********| |
309 | | (F8) SIP | |
310 | | 200 OK | |
311 | |***********>| |
312 | | | (F9) SIP |
313 | | | 200 OK |
314 | | |***********>|
315 | | | (F10) SIP |
316 | | | NOTIFY |
317 | | | (active) |
318 | | |<***********|
319 | | (F11) SIP | |
320 | | NOTIFY | |
321 | |<***********| |
322 | | (F12) SIP | |
323 | | 200 OK | |
324 | |***********>| |
325 | | | (F13) SIP |
326 | | | 200 OK |
327 | | |***********>|
328 | (F14) XMPP | | |
329 | subscribed | | |
330 |<...........| | |
331 | (F15) XMPP | | |
332 | presence | | |
333 |<...........| | |
334 | | | |
336 An XMPP user (e.g., juliet@example.com) asks for a presence
337 authorization by sending a request to a SIP contact (e.g.,
338 romeo@example.net), and the contact either accepts or declines the
339 request. If the SIP contact accepts the request, the XMPP user will
340 have a long-lived authorization to receive the SIP contact's presence
341 information until (1) the XMPP user unsubscribes or (2) the SIP
342 contact cancels the authorization. The request is encapsulated in a
343 stanza of type "subscribe":
345 Example 1: XMPP User Subscribes to SIP Contact (F1)
347 |
351 Upon receiving such a stanza, the XMPP server to which
352 Juliet has connected needs to determine the identity of the
353 domainpart in the 'to' address, which it does by following the
354 procedures explained in Section 5 of [RFC7247]. If the domain is a
355 SIP domain, the XMPP server will hand off the stanza to
356 an associated XMPP-to-SIP gateway or connection manager that natively
357 communicates with presence-aware SIP proxies.
359 The XMPP-to-SIP gateway is then responsible for translating the XMPP
360 request into a SIP SUBSCRIBE request addressed from the XMPP user to
361 the SIP contact:
363 Example 2: SIP Transformation of XMPP Presence Authorization Request
364 (F2)
366 | SUBSCRIBE sip:romeo@example.net SIP/2.0
367 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
368 | From: ;tag=j89d
369 | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
370 | Event: presence
371 | Max-Forwards: 70
372 | CSeq: 1 SUBSCRIBE
373 | Contact: ;gr=yn0cl4bnw0yr3vym
374 | Accept: application/pidf+xml
375 | Expires: 3600
376 | Content-Length: 0
378 Once the SIP proxy has delivered the SIP SUBSCRIBE to the SIP User
379 Agent or Presence Server (F3, no example shown), the SIP User Agent
380 then would send a response indicating acceptance of the request:
382 Example 3: SIP User Accepts Presence Authorization Request (F4)
384 | SIP/2.0 200 OK
385 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
386 | From: ;tag=j89d
387 | To: ;tag=ffd2
388 | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
389 | CSeq: 1 SUBSCRIBE
390 | Contact: ;gr=dr4hcr0st3lup4c
391 | Expires: 3600
392 | Content-Length: 0
394 In accordance with Section 6.7 of [RFC3856], the XMPP-to-SIP gateway
395 needs to consider the state to be "neutral" until it receives a
396 NOTIFY message with a Subscription-State header [RFC6665] whose value
397 is "active". Therefore, the SIP User Agent or Presence Server SHOULD
398 immediately send such a NOTIFY message (see Section 6 below). In
399 case the XMPP-to-SIP gateway initially receives one or more NOTIFY
400 messages with Subscription-State header whose value is "pending"
401 (F6), it MUST respond to them on the SIP side but not generate any
402 presence stanzas towards the XMPP User.
404 Example 4: SIP User Agent or Presence Server Sends Presence
405 Notification (F10)
407 | NOTIFY sip:juliet@example.com SIP/2.0
408 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk
409 | From: ;tag=j89d
410 | To: ;tag=ffd2
411 | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
412 | Event: presence
413 | Subscription-State: active;expires=499
414 | Max-Forwards: 70
415 | CSeq: 2 NOTIFY
416 | Content-Type: application/pidf+xml
417 | Content-Length: 193
418 |
419 |
420 |
422 |
423 |
424 | open
425 | away
426 |
427 |
428 |
429 Upon receiving the first NOTIFY with a state of active, the XMPP-to-
430 SIP gateway returns a 200 OK to the SIP User Agent or Presence Server
431 (F12, no example shown).
433 The XMPP-to-SIP gateway also generates a stanza of type
434 "subscribed":
436 Example 5: XMPP User Receives Acknowledgement from SIP Contact (F14)
438 |
442 As described in Section 6, if this first NOTIFY in the notification
443 session contains a body then the XMPP-to-SIP gateway also generates a
444 presence notification addressed to the XMPP user (if the NOTIFY does
445 not contain a body then the gateway would interpret it as unknown or
446 "closed"):
448 Example 6: XMPP User Receives Presence Notification from SIP Contact
449 (F15)
451 |
454 5.2.2. Refreshing a Notification Dialog
456 It is the responsibility of the XMPP-to-SIP gateway to set the value
457 of the Expires header and to periodically renew the notification
458 dialog on the SIMPLE side of the gateway. For example, the XMPP-to-
459 SIP gateway SHOULD send a new SUBSCRIBE request to the SIP contact
460 whenever the XMPP user initiates a presence session with the XMPP
461 server by sending initial presence to its XMPP server (this is
462 functionally equivalent to sending an XMPP presence probe). The
463 XMPP-to-SIP gateway also SHOULD send a new SUBSCRIBE request to the
464 SIP contact sufficiently in advance of when the SIP notification
465 dialog is scheduled to expire during the XMPP user's active presence
466 session.
468 The rules regarding SIP SUBSCRIBE requests for the purpose of
469 establishing and refreshing a notification dialog are provided in
470 [RFC6665]. Those rules also apply to XMPP-to-SIP gateways.
471 Furthermore, an XMPP-to-SIP gateway MUST consider the XMPP presence
472 authorization to be permanently cancelled (and so inform the XMPP
473 user) if it receives a SIP response of 403, 489, or 603. By
474 contrast, it is appropriate to consider a SIP response of 423 or 481
475 to be a transient error and to honor the long-lived XMPP presence
476 authorization. [RFC6665] explains more detailed considerations about
477 the handling of SIP responses in relation to notification dialogs and
478 refreshes.
480 Finally, see the security considerations section (Section 9) of this
481 document for important information and requirements regarding the
482 security implications of notification refreshes.
484 5.2.3. Cancelling a Presence Authorization
486 The following diagram illustrates the protocol flow by which an XMPP
487 user cancels her outbound presence authorization with a SIP contact
488 (i.e., indicates that she no longer wishes to be authorized to see
489 the SIP contact's presence). As can be seen, SIMPLE itself does not
490 have a construct that enables a user to cancel her outbound presence
491 authorization (however, in many SIP/SIMPLE implementations she could
492 use a technology such as XCAP [RFC4825] to remove the contact from
493 her address list); therefore, this flow instead results in
494 cancellation of the user's notification dialog (with the implication
495 on the XMPP side that the user will not request a subsequent
496 notification dialog). Additional details are explained in the text
497 and examples after the diagram.
499 XMPP XMPP SIP SIP UA or
500 Client Server Proxy Presence Server
501 | + X2S GW | |
502 | | | |
503 | (F16) XMPP | | |
504 |unsubscribe | | |
505 |...........>| | |
506 | | (F17) SIP | |
507 | | SUBSCRIBE | |
508 | | Expires: 0 | |
509 | |***********>| |
510 | | | (F18) SIP |
511 | | | SUBSCRIBE |
512 | | | Expires: 0 |
513 | | |***********>|
514 | | | (F19) SIP |
515 | | | 200 OK |
516 | | |<***********|
517 | | (F20) SIP | |
518 | | 200 OK | |
519 | |<***********| |
520 | (F21) XMPP | | |
521 |unsubscribed| | |
522 |<...........| | |
523 | | (F22) SIP | |
524 | | NOTIFY | |
525 | | terminated | |
526 | |***********>| |
527 | | | (F23) SIP |
528 | | | NOTIFY |
529 | | | terminated |
530 | | |***********>|
531 | | | (F24) SIP |
532 | | | 200 OK |
533 | | |<***********|
534 | | (F25) SIP | |
535 | | 200 OK | |
536 | |<***********| |
537 | | | |
539 At any time after subscribing, the XMPP user can indicate that she no
540 longer wishes to be authorized to receive presence notifications from
541 the contact. This is done by sending a stanza of type
542 "unsubscribe":
544 Example 7: XMPP User Unsubscribes from SIP Contact (F16)
546 |
550 The XMPP-to-SIP gateway is responsible for translating the XMPP
551 unsubscribe command into a SIP SUBSCRIBE request with the Expires
552 header set to a value of zero:
554 Example 8: SIP Transformation of XMPP Unsubscribe (F17)
556 | SUBSCRIBE sip:romeo@example.net SIP/2.0
557 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
558 | From: ;tag=j89d
559 | To: ;tag=ffd2
560 | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
561 | Event: presence
562 | Max-Forwards: 70
563 | CSeq: 42 SUBSCRIBE
564 | Contact: ;gr=yn0cl4bnw0yr3vym
565 | Accept: application/pidf+xml
566 | Expires: 0
567 | Content-Length: 0
569 Upon receiving the SIP 200 OK acknowleding the cancellation, the
570 XMPP-to-SIP gateway SHOULD send a stanza of type
571 "unsubscribed" addressed to the XMPP user:
573 Example 9: XMPP User Receives Unsubscribed Notification (F21)
575 |
579 In accordance with Section 4.4.1 of [RFC6665], the XMPP-to-SIP
580 gateway is then responsible for sending a NOTIFY with a
581 "Subscription-State" of "terminated" in order to formally end the
582 XMPP user's outbound presence authorization and the associated SIP
583 dialog.
585 Example 10: XMPP-to-SIP Gateway Sends Presence Notification to
586 Terminate Authorization (F25)
588 | NOTIFY sip:juliet@example.com SIP/2.0
589 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk
590 | From: ;tag=j89d
591 | To: ;tag=ffd2
592 | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
593 | Event: presence
594 | Subscription-State: terminated
595 | Max-Forwards: 70
596 | CSeq: 43 NOTIFY
597 | Content-Length: 0
599 Note: When the XMPP user cancels her outbound presence authorization
600 to the SIP user, any inbound authorization that she might have
601 approved (thus enabling the SIP user to see her presence) remains
602 unchanged.
604 5.3. SIP to XMPP
606 5.3.1. Requesting a Presence Authorization
608 The following diagram illustrates the protocol flow for establishing
609 an authorization for a SIP user to receive presence notifications
610 from an XMPP contact, as further explained in the text and examples
611 after the diagram.
613 SIP SIP XMPP XMPP
614 UA Proxy Server Client
615 | + S2X GW | |
616 | | | |
617 | (F26) SIP | | |
618 | SUBSCRIBE | | |
619 |**********>| | |
620 | (F27) SIP | | |
621 | 200 OK | | |
622 |<**********| | |
623 | | (F28) XMPP | |
624 | | subscribe | |
625 | |...........>| |
626 | | | (F29) XMPP|
627 | | | subscribe |
628 | | |..........>|
629 | | | (F30) XMPP|
630 | | | subscribed|
631 | | |<..........|
632 | | (F31) XMPP | |
633 | | subscribed | |
634 | |<...........| |
635 | (F32) SIP | | |
636 | NOTIFY | | |
637 | (active) | | |
638 |<**********| | |
639 | (F33) SIP | | |
640 | 200 OK | | |
641 |**********>| | |
642 | | | |
644 A SIP User Agent initiates a presence authorization to an XMPP
645 contact's presence information by sending a SIP SUBSCRIBE request to
646 the contact. The following is an example of such a request:
648 Example 11: SIP User Subscribes to XMPP Contact (F26)
650 | SUBSCRIBE sip:juliet@example.com SIP/2.0
651 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
652 | From: ;tag=xfg9
653 | To:
654 | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11
655 | Event: presence
656 | Max-Forwards: 70
657 | CSeq: 1 SUBSCRIBE
658 | Contact: ;gr=dr4hcr0st3lup4c
659 | Accept: application/pidf+xml
660 | Content-Length: 0
662 Notice that the Expires header was not included in the SUBSCRIBE
663 request; this means that the default value of 3600 (i.e., 3600
664 seconds = 1 hour) applies.
666 Upon receiving the SUBSCRIBE, the SIP proxy needs to determine the
667 identity of the domain portion of the Request-URI, which it does by
668 following the procedures explained in Section 5 of [RFC7247]. If the
669 domain is an XMPP domain, the SIP proxy will hand off the SUBSCRIBE
670 to an associated SIP-to-XMPP gateway or connection manager that
671 natively communicates with XMPP servers.
673 The SIP-to-XMPP gateway is then responsible for translating the
674 SUBSCRIBE into an XMPP authorization request addressed from the SIP
675 user to the XMPP contact:
677 Example 12: XMPP Transformation of SIP SUBSCRIBE (F28)
679 |
683 In accordance with [RFC6121], the XMPP user's server delivers the
684 presence authorization request to the XMPP user (or, if an
685 authorization already exists in the XMPP user's roster, the XMPP
686 server SHOULD auto-reply with a stanza of type
687 'subscribed').
689 The "happy path" is for the XMPP user to approve the presence
690 authorization request by generating a stanza of type
691 "subscribed" (F30). The XMPP server then stamps that presence stanza
692 with the 'from' address of the XMPP contact and sends it to the SIP
693 user (F31). Upon receiving the stanza, the SIP-to-XMPP gateway
694 generates an empty SIP NOTIFY message with a Subscription-State
695 header [RFC6665] of "active", which serves to inform the SIP user
696 that the presence authorization request has been approved (F32).
698 Example 13: XMPP User Approves Presence Authorization Request (F31)
700 |
704 Example 14: Presence Authorization Request Approved (F32)
706 | NOTIFY sip:romeo@example.net SIP/2.0
707 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
708 | From: ;tag=xfg9
709 | To: ;tag=ur93
710 | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11
711 | Event: presence
712 | Subscription-State: active
713 | Max-Forwards: 70
714 | CSeq: 2 NOTIFY
715 | Content-Length: 0
717 As an alternative to the "happy path", the XMPP user could decline
718 the presence authorization request by generating a stanza
719 of type "unsubscribed". The XMPP server would stamp that presence
720 stanza with the 'from' address of the XMPP contact and would send it
721 to the SIP user. The SIP-to-XMPP gateway then transforms that stanza
722 into an empty SIP NOTIFY message with a Subscription-State header
723 [RFC6665] of "terminated" and a reason of "rejected":
725 Example 15: XMPP User Rejects Presence Authorization Request
727 |
731 Example 16: Presence Authorization Request Rejected
733 | NOTIFY sip:romeo@example.net SIP/2.0
734 | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
735 | From: ;tag=xfg9
736 | To: ;tag=ur93
737 | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11
738 | Event: presence
739 | Subscription-State: terminated;reason=rejected
740 | Max-Forwards: 70
741 | CSeq: 2 NOTIFY
742 | Content-Length: 0
744 5.3.2. Refreshing a Notification Dialog
746 For as long as a SIP user is online and wishes to maintain a
747 notification session (i.e., receive presence notifications from the
748 XMPP contact), the user's SIP User Agent is responsible for
749 periodically refreshing the notification dialog by sending an updated
750 SUBSCRIBE request with an appropriate value for the Expires header.
751 In response, the presence-aware SIP-to-XMPP gateway sends a SIP
752 NOTIFY to the user agent (per [RFC6665]); if the SIP-to-XMPP gateway
753 has meaningful information about the availability state of the XMPP
754 user (e.g., obtained from the core presence session in the XMPP
755 server or learned by sending a presence probe as described under
756 Section 7) then the NOTIFY communicates that information (e.g., by
757 including a PIDF body [RFC3863] with the relevant data), whereas if
758 the SIP-to-XMPP gateway does not have meaningful information about
759 the availability state of the XMPP user then the NOTIFY MUST be empty
760 as allowed by [RFC6665].
762 5.3.3. Cancelling a Presence Authorization
764 SIP does not directly have a construct for cancelling an outbound
765 presence authorization. Instead, the SIP user would terminate his
766 outbound notification dialog by sending a SUBSCRIBE message whose
767 Expires header is set to a value of zero ("0"), and then never renew
768 it:
770 Example 17: SIP User Terminates Notification Dialog
772 | SUBSCRIBE sip:juliet@example.com SIP/2.0
773 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk
774 | From: ;tag=xfg9
775 | To: ;tag=ur93
776 | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11
777 | Event: presence
778 | Max-Forwards: 70
779 | CSeq: 66 SUBSCRIBE
780 | Contact: ;gr=dr4hcr0st3lup4c
781 | Expires: 0
782 | Content-Length: 0
784 A presence-aware SIP-to-XMPP gateway is then responsible for sending
785 a SIP NOTIFY request to the SIP User Agent containing a PIDF document
786 specifying that the XMPP contact now has a basic status of "closed",
787 including a Subscription-State header [RFC6665] of "terminated" with
788 a reason of "timeout"; and sending an XMPP stanza of type
789 "unavailable" to the XMPP contact
790 Note: When the SIP user cancels his outbound presence authorization
791 to the XMPP user, any inbound authorization that he might have
792 approved (enabling the XMPP user to see his presence) remains
793 unchanged.
795 6. Notifications of Presence Information
797 6.1. Overview
799 Both XMPP and presence-aware SIP systems enable entities (often, but
800 not necessarily, human users) to send presence notifications to other
801 entities. At its most basic, the term "presence" refers to
802 information about an entity's "on/off" availability for communication
803 on a network. Often, this basic concept is supplemented by
804 information that further specifies the entity's context or status
805 while available for communication; these availability states commonly
806 include "away" and "do not disturb". Some systems and protocols
807 extend the concepts of presence and availability even further and
808 refer to any relatively ephemeral information about an entity as a
809 kind of presence; categories of such "extended presence" include
810 geographical location (e.g., GPS coordinates), user mood (e.g.,
811 grumpy), user activity (e.g., walking), and ambient environment
812 (e.g., noisy). This document focuses on the "least common
813 denominator" of network availability only, although future documents
814 might address broader notions of presence, including availability
815 states and extended presence.
817 The XMPP instant messaging and presence specification [RFC6121]
818 defines how XMPP stanzas can indicate availability (via
819 absence of a 'type' attribute) or lack of availability (via a 'type'
820 attribute with a value of "unavailable"). SIP presence using a SIP
821 event package for presence is specified in [RFC3856].
823 As described in [RFC6121], XMPP presence information about an entity
824 is communicated by means of an XML stanza sent over an
825 XML stream. This document assumes that such a stanza is
826 sent from an XMPP client to an XMPP server over an XML stream
827 negotiated between the client and the server, and that the client is
828 controlled by a human user. In general, XMPP presence is sent by the
829 user to the user's server and then broadcast to all entities who are
830 subscribed to the user's presence information.
832 As described in [RFC3856], presence information about an entity is
833 communicated by means of a SIP NOTIFY event sent from a SIP User
834 Agent to an intended recipient who is most generally referenced by a
835 Presence URI of the form but who might be
836 referenced by a SIP or SIPS URI of the form or
837 .
839 This document addresses basic presence or network availability only,
840 not the various extensions to SIP and XMPP for "rich presence" such
841 as [RFC4480], [XEP-0107], and [XEP-0108].
843 6.2. XMPP to SIP
845 When Juliet interacts with her XMPP client to modify her presence
846 information (or when her client automatically updates her presence
847 information, e.g., via an "auto-away" feature), her client generates
848 an XMPP stanza. The syntax of the stanza,
849 including required and optional elements and attributes, is defined
850 in [RFC6121]. The following is an example of such a stanza:
852 Example 18: XMPP User Sends Presence Notification
854 |
856 Upon receiving such a stanza, the XMPP server to which Juliet has
857 connected broadcasts it to all subscribers who are authorized to
858 receive presence notifications from Juliet and who have indicated a
859 current interest in receiving notifications (this is similar to the
860 SIP NOTIFY method). For each subscriber, broadcasting the presence
861 notification involves adding the 'to' address of the subscriber and
862 then either delivering the notification to a local recipient (if the
863 hostname in the subscriber's address matches one of the hostnames
864 serviced by the XMPP server) or attempting to route it to the foreign
865 domain that services the hostname in the subscriber's address. If
866 the notification is bound for an address at a foreign domain, the
867 XMPP server needs to determine the identity of the domainpart in the
868 'to' address, which it does by following the procedures discussed in
869 [RFC7247]. If the domain is a SIP domain, the XMPP server will hand
870 off the stanza to an associated XMPP-to-SIP gateway or
871 connection manager that natively communicates with presence-aware SIP
872 proxy (no example shown).
874 The XMPP-to-SIP gateway is then responsible for translating the XMPP
875 stanza into a SIP NOTIFY request and included PIDF
876 document from the XMPP user to the SIP contact.
878 Example 19: SIP Transformation of XMPP Presence Notification
880 | NOTIFY sip:juliet@example.com SIP/2.0
881 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
882 | From: ;tag=gh19
883 | To:
884 | Contact: ;gr=yn0cl4bnw0yr3vym
885 | Call-ID: 2B44E147-3B53-45E4-9D48-C051F3216D14
886 | Event: presence
887 | Subscription-State: active;expires=599
888 | Max-Forwards: 70
889 | CSeq: 2 NOTIFY
890 | Content-Type: application/pidf+xml
891 | Content-Length: 192
892 |
893 |
894 |
896 |
897 |
898 | open
899 | away
900 |
901 |
902 |
904 The mapping of XMPP syntax elements to SIP syntax elements MUST be as
905 shown in the following table. (Mappings for elements not mentioned
906 are undefined.)
907 +-----------------------------+---------------------------+
908 | XMPP Element or Attribute | SIP Header or PIDF Data |
909 +-----------------------------+---------------------------+
910 | stanza | "Event: presence" (1) |
911 +-----------------------------+---------------------------+
912 | XMPP resource identifier | tuple 'id' attribute (2) |
913 +-----------------------------+---------------------------+
914 | from | From |
915 +-----------------------------+---------------------------+
916 | id | no mapping (3) |
917 +-----------------------------+---------------------------+
918 | to | To |
919 +-----------------------------+---------------------------+
920 | type | basic status (4) (5) |
921 +-----------------------------+---------------------------+
922 | xml:lang | Content-Language |
923 +-----------------------------+---------------------------+
924 | | priority for tuple (6) |
925 +-----------------------------+---------------------------+
926 | | no mapping (7) |
927 +-----------------------------+---------------------------+
928 | | |
929 +-----------------------------+---------------------------+
931 Table 1: Presence Syntax Mapping from XMPP to SIP
933 Note the following regarding these mappings:
935 1. Only an XMPP stanza that lacks a 'type' attribute or
936 whose 'type' attribute has a value of "unavailable" MUST be
937 mapped by an XMPP-to-SIP gateway to a SIP NOTIFY request, because
938 those are the only stanzas that represent
939 notifications.
941 2. The PIDF schema defines the tuple 'id' attribute as having a
942 datatype of "xs:ID"; because this datatype is more restrictive
943 than the "xs:string" datatype for XMPP resourceparts (in
944 particular, a number is not allowed as the first character of an
945 ID), it is RECOMMENDED to prepend the resourcepart with "ID-" or
946 some other alphabetic string when mapping from XMPP to SIP.
948 3. In practice, XMPP stanzas often do not include the
949 'id' attribute.
951 4. Because the lack of a 'type' attribute indicates that an XMPP
952 entity is available for communications, the XMPP-to-SIP gateway
953 MUST map that information to a PIDF basic status of "open".
954 Because a 'type' attribute with a value of "unavailable"
955 indicates that an XMPP entity is not available communications,
956 the XMPP-to-SIP gateway MUST map that information to a PIDF
957 status of "closed".
959 5. When the XMPP-to-SIP gateway receives XMPP presence of type
960 "unavailable" from the XMPP contact, it sends a SIP NOTIFY
961 request from the XMPP contact to the SIP User Agent containing a
962 PIDF document specifying that the XMPP contact now has a basic
963 status of "closed".
965 6. The value of the XMPP element is an integer between
966 -128 and +127, whereas the value of the PIDF element's
967 'priority' attribute is a decimal number from zero to one
968 inclusive, with a maximum of three decimal places. If the value
969 of the XMPP element is negative, an XMPP-to-SIP
970 gateway MUST NOT map the value. If an XMPP-to-SIP gateway maps
971 positive values, it SHOULD treat XMPP priority 0 as PIDF priority
972 0 and XMPP priority 127 as PIDF priority 1, mapping intermediate
973 values appropriately so that they are unique (e.g., XMPP priority
974 1 to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015,
975 and so on up through mapping XMPP priority 126 to PIDF priority
976 0.992; note that this is an example only and that the exact
977 mapping is up to the implementation).
979 7. Some implementations support custom extensions to encapsulate
980 detailed information about availability; however, there is no
981 need to standardize a PIDF extension for this purpose, because
982 PIDF is already extensible and thus the element
983 (qualified by the 'jabber:client' namespace) can be included
984 directly in the PIDF XML. The examples in this document
985 illustrate this usage, which is RECOMMENDED. The most useful
986 values are likely "away" and "dnd", although note that the latter
987 value merely means "busy" and does not imply that a server or
988 client ought to block incoming traffic while the user is in that
989 state. Naturally, an XMPP-to-SIP gateway can choose to translate
990 a custom extension into an established value of the
991 element [RFC6121] or translate a element into a custom
992 extension that the XMPP-to-SIP gateway knows is supported by the
993 user agent of the intended recipient. Unfortunately, this
994 behavior does not guarantee that information will not be lost; to
995 help prevent information loss, an XMPP-to-SIP gateway ought to
996 include both the element and the custom extension if it
997 cannot suitably translate the custom value into a value.
998 However, there is no guarantee that the SIP receiver will render
999 a standard XMPP value or custom extension.
1001 In XMPP, a user can connect with multiple devices at the same time
1002 [RFC6120]; for presence notification purposes [RFC6121], each device
1003 is associated with a distinct resourcepart [RFC7622] and a contact's
1004 user agent will receive a separate presence notification from each of
1005 the user's devices. Although the interpretation of multiple presence
1006 notifications from a single user is a matter of implementation by the
1007 contact's user agent, typically the user agent will show the "most
1008 available" status for the contact (e.g., if the user is online with
1009 three devices, one of which is away, one of which is in do not
1010 disturb mode, and one of which is available with no qualifications,
1011 then the status shown will simply be available. In SIP, it is
1012 reasonable for a user agent to model multiple presence notifications
1013 from an XMPP user in the same way that it would handle multiple
1014 tuples from a SIP user.
1016 6.3. SIP to XMPP
1018 When Romeo changes his presence, his SIP User Agent generates a SIP
1019 NOTIFY request for any contacts that have presence authorizations and
1020 notification sessions. The syntax of the NOTIFY request is defined
1021 in [RFC3856]. The following is an example of such a request:
1023 Example 20: SIP User Sends Presence Notification
1025 | NOTIFY sip:romeo@example.net SIP/2.0
1026 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk
1027 | From: ;tag=yt66
1028 | To: ;tag=bi54
1029 | Contact: ;gr=dr4hcr0st3lup4c
1030 | Call-ID: C33C6C9D-0F4A-42F9-B95C-7CE86B526B5B
1031 | Event: presence
1032 | Subscription-State: active;expires=499
1033 | Max-Forwards: 70
1034 | CSeq: 8 NOTIFY
1035 | Content-Type: application/pidf+xml
1036 | Content-Length: 193
1037 |
1038 |
1039 |
1041 |
1042 |
1043 | closed
1044 |
1045 |
1046 |
1048 Upon receiving the NOTIFY, the SIP proxy needs to determine the
1049 identity of the domain portion of the Request-URI, which it does by
1050 following the procedures discussed in [RFC7247]. If the domain is an
1051 XMPP domain, the SIP proxy will hand off the NOTIFY to an associated
1052 SIP-to-XMPP gateway or connection manager that natively communicates
1053 with XMPP servers.
1055 The SIP-to-XMPP gateway is then responsible for translating the
1056 NOTIFY into an XMPP stanza addressed from the SIP user to
1057 the XMPP contact:
1059 Example 21: XMPP Transformation of SIP Presence Notification
1061 |
1065 The mapping of SIP syntax elements to XMPP syntax elements MUST be as
1066 shown in the following table. (Mappings for elements not mentioned
1067 are undefined.)
1069 +---------------------------+-----------------------------+
1070 | SIP Header or PIDF Data | XMPP Element or Attribute |
1071 +---------------------------+-----------------------------+
1072 | basic status | type (1) |
1073 +---------------------------+-----------------------------+
1074 | Content-Language | xml:lang |
1075 +---------------------------+-----------------------------+
1076 | From | from |
1077 +---------------------------+-----------------------------+
1078 | priority for tuple | (2) |
1079 +---------------------------+-----------------------------+
1080 | To | to |
1081 +---------------------------+-----------------------------+
1082 | | |
1083 +---------------------------+-----------------------------+
1084 | | (3) |
1085 +---------------------------+-----------------------------+
1087 Table 2: Presence Syntax Mapping from SIP to XMPP
1089 Note the following regarding these mappings:
1091 1. A PIDF basic status of "open" MUST be mapped to no 'type'
1092 attribute, and a PIDF basic status of "closed" MUST be mapped to
1093 a 'type' attribute whose value is "unavailable".
1095 2. See the notes following Table 1 of this document regarding
1096 mapping of presence priority.
1098 3. If a SIP implementation supports the element (qualified
1099 by the 'jabber:client' namespace) as a PIDF extension for
1100 availability status as described in the notes following Table 1
1101 of this document, the SIP-to-XMPP gateway is responsible for
1102 including that element in the XMPP presence notification.
1104 7. Polling for Presence Information
1106 Both SIP and XMPP provide methods for explicitly requesting one-time
1107 information about the current presence status of another entity.
1108 These are "polling" methods as opposed to the subscribing methods
1109 described in the rest of this document.
1111 7.1. XMPP to SIP
1113 In XMPP, an explicit request for information about current presence
1114 status is completed by sending a stanza of type "probe":
1116 Example 22: XMPP Server Sends Presence Probe on Behalf of XMPP User
1118 |
1122 Note: As described in [RFC6121], presence probes are used by XMPP
1123 servers to request presence on behalf of XMPP users; XMPP clients are
1124 discouraged from sending presence probes, because retrieving presence
1125 is a service that servers provide automatically.
1127 A SIP-to-XMPP gateway would transform the presence probe into its SIP
1128 equivalent, which is a SUBSCRIBE request with an Expires header value
1129 of zero in a new dialog:
1131 Example 23: SIP Transformation of XMPP Presence Probe
1133 | SUBSCRIBE sip:romeo@example.net SIP/2.0
1134 | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk
1135 | From: ;tag=j89d
1136 | Call-ID: 2398B737-566F-4CBB-A21A-1F8EEF7AF423
1137 | Event: presence
1138 | Max-Forwards: 70
1139 | CSeq: 1 SUBSCRIBE
1140 | Contact: ;gr=yn0cl4bnw0yr3vym
1141 | Accept: application/pidf+xml
1142 | Expires: 0
1143 | Content-Length: 0
1144 As described in [RFC3856], this causes a NOTIFY to be sent to the
1145 subscriber, just as a presence probe does (the transformation rules
1146 for presence notifications have been previously described in
1147 Section 6.2 of this document).
1149 7.2. SIP to XMPP
1151 In SIP, an explicit request for information about current presence
1152 status is effectively completed by sending a SUBSCRIBE with an
1153 Expires header value of zero:
1155 Example 24: SIP User Sends Presence Request
1157 | SUBSCRIBE sip:juliet@example.com SIP/2.0
1158 | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk
1159 | From: ;tag=yt66
1160 | Call-ID: 717B1B84-F080-4F12-9F44-0EC1ADE767B9
1161 | Event: presence
1162 | Max-Forwards: 70
1163 | CSeq: 1 SUBSCRIBE
1164 | Contact: ;gr=dr4hcr0st3lup4c
1165 | Expires: 0
1166 | Content-Length: 0
1168 A presence-aware SIP-to-XMPP gateway translates such a SIP request
1169 into a stanza of type "probe" if it does not already have
1170 presence information about the contact:
1172 Example 25: XMPP Transformation of SIP Presence Request
1174 |
1178 8. IANA Considerations
1180 This document makes no requests of IANA.
1182 9. Privacy and Security Considerations
1184 Detailed privacy and security considerations for presence protocols
1185 are given in [RFC2779], for SIP-based presence in [RFC3856] (see also
1186 [RFC3261]), and for XMPP-based presence in [RFC6121] (see also
1187 [RFC6120]).
1189 9.1. Amplification Attacks
1191 There exists the possibility of an amplification attack launched from
1192 the XMPP network against a SIP presence server, because each long-
1193 lived XMPP presence authorization would typically result in multiple
1194 notification dialog refreshes on the SIP side of an XMPP-to-SIP
1195 gateway. Therefore, access to an XMPP-to-SIP gateway SHOULD be
1196 restricted in various ways; for example:
1198 o Only an XMPP service that carefully controls account provisioning
1199 and provides effective methods for the administrators to control
1200 the behavior of registered users ought to host an XMPP-to-SIP
1201 gateway (e.g., not a service that offers open account
1202 registration).
1204 o An XMPP-to-SIP gateway ought to be associated only with a single
1205 domain or trust realm. For example, an XMPP-to-SIP gateway hosted
1206 at simple.example.com ought to allow only users within the
1207 example.com domain to access the XMPP-to-SIP gateway, not users
1208 within example.org, example.net, or any other domain (unless they
1209 are part of the same multi-tenanted environment as example.com).
1210 This helps to prevent the gateway equivalent of open relays that
1211 are shared across XMPP domains from different trust realms.
1213 If a SIP presence server receives communications through an XMPP-to-
1214 SIP gateway from users who are not associated with a domain that is
1215 so related to the hostname of the XMPP-to-SIP gateway, it SHOULD
1216 (based on local service provisioning) refuse to service such users or
1217 refuse to receive traffic from the XMPP-to-SIP gateway. As a further
1218 check, whenever an XMPP-to-SIP gateway seeks to refresh an XMPP
1219 user's long-lived authorization to a SIP user's presence, it first
1220 sends an XMPP stanza of type "probe" from the address of
1221 the XMPP-to-SIP gateway to the "bare JID" (user@domain.tld) of the
1222 XMPP user, to which the user's XMPP server responds in accordance
1223 with [RFC6121]; this puts an equal burden on the XMPP server and the
1224 SIP proxy.
1226 9.2. Presence Leaks
1228 Presence notifications can contain sensitive information (e.g., about
1229 network availability). In addition, it is possible in both SIP and
1230 XMPP for an entity to send different presence notifications to
1231 different subscribers. Therefore, a gateway MUST NOT route or
1232 deliver a presence notification to any entity other than the intended
1233 recipient (as represented by the 'to' address for XMPP and by the
1234 Request-URI for SIP), because it does not possess information about
1235 authorization to receive presence notifications for such entities -
1236 that information resides at the user's home service, not at the
1237 receiving gateway).
1239 10. References
1241 10.1. Normative References
1243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1244 Requirement Levels", BCP 14, RFC 2119, March 1997.
1246 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
1247 A., Peterson, J., Sparks, R., Handley, M., and E.
1248 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
1249 June 2002.
1251 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
1252 Initiation Protocol (SIP)", RFC 3856, August 2004.
1254 [RFC3857] Rosenberg, J., "A Watcher Information Event Template-
1255 Package for the Session Initiation Protocol (SIP)", RFC
1256 3857, August 2004.
1258 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
1259 W., and J. Peterson, "Presence Information Data Format
1260 (PIDF)", RFC 3863, August 2004.
1262 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
1263 Protocol (XMPP): Core", RFC 6120, March 2011.
1265 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
1266 Protocol (XMPP): Instant Messaging and Presence", RFC
1267 6121, March 2011.
1269 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
1270 July 2012.
1272 [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand,
1273 "Interworking between the Session Initiation Protocol
1274 (SIP) and the Extensible Messaging and Presence Protocol
1275 (XMPP): Architecture, Addresses, and Error Handling", RFC
1276 7247, May 2014.
1278 [RFC7622] Saint-Andre, P., "Extensible Messaging and Presence
1279 Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/
1280 RFC7622, September 2015,
1281 .
1283 10.2. Informative References
1285 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
1286 Presence and Instant Messaging", RFC 2778, February 2000.
1288 [RFC2779] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
1289 / Presence Protocol Requirements", RFC 2779, February
1290 2000.
1292 [RFC3860] Peterson, J., "Common Profile for Instant Messaging
1293 (CPIM)", RFC 3860, August 2004.
1295 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
1296 Rosenberg, "RPID: Rich Presence Extensions to the Presence
1297 Information Data Format (PIDF)", RFC 4480, July 2006.
1299 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
1300 Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
1302 [RFC7572] Saint-Andre, P., Houri, A., and J. Hildebrand,
1303 "Interworking between the Session Initiation Protocol
1304 (SIP) and the Extensible Messaging and Presence Protocol
1305 (XMPP): Instant Messaging", RFC 7572, DOI 10.17487/
1306 RFC7572, June 2015,
1307 .
1309 [RFC7573] Saint-Andre, P. and S. Loreto, "Interworking between the
1310 Session Initiation Protocol (SIP) and the Extensible
1311 Messaging and Presence Protocol (XMPP): One-to-One Text
1312 Chat Sessions", RFC 7573, DOI 10.17487/RFC7573, June 2015,
1313 .
1315 [RFC7702] Saint-Andre, P., Ibarra, S., and S. Loreto, "Interworking
1316 between the Session Initiation Protocol (SIP) and the
1317 Extensible Messaging and Presence Protocol (XMPP):
1318 Groupchat", RFC 7702, DOI 10.17487/RFC7702, December 2015,
1319 .
1321 [XEP-0107]
1322 Saint-Andre, P. and R. Meijer, "User Mood", XSF XEP 0107,
1323 October 2008, .
1325 [XEP-0108]
1326 Meijer, R. and P. Saint-Andre, "User Activity", XSF XEP
1327 0108, October 2008,
1328 .
1330 Appendix A. Changes from RFC 7248
1332 RFC 7248 had already been published when the STOX WG discovered that
1333 a related document (since published as [RFC7702]) contained problems
1334 that also applied to RFC 7248. Specifically, the diagrams and
1335 protocol flows in RFC 7248 contained errors that reflected an
1336 incorrect architecture with gateways on both sides of the protocol
1337 exchange; in theory and in practice, presence traffic from an XMPP
1338 system would be translated by an XMPP-to-SIMPLE gateway on the XMPP
1339 side and received by a normal SIP/SIMPLE system directly (without a
1340 receiving gateway on the SIP/SIMPLE side), and traffic from a SIP
1341 system would be translated by a SIMPLE-to-XMPP gateway on the SIP
1342 side and received by a normal XMPP system (without a receiving
1343 gateway on the XMPP side).
1345 Therefore, this document makes the following substantive changes from
1346 RFC 7248:
1348 o Corrects the architectural assumptions, diagrams, and protocol
1349 flows to reflect a single-gateway model in each direction.
1351 o Adjusts terminology to replace the term "SIP Server" with the term
1352 "SIP Proxy" or "SIP Presence Server" as appropriate, and to use
1353 the term "notification dialog" for a SIP subscription and the term
1354 "presence authorization" for an XMPP subscription instead of the
1355 generic term "subscription" in both contexts.
1357 o Clarifies that SIP notification dialogs are used to handle
1358 presence authorizations in SIP (e.g., there is no dedicated way to
1359 signal outbound cancellation of an authorization as there is in
1360 XMPP).
1362 o Clarifies the use of the 'presence.winfo' event package, of the
1363 Subscription-State headers (specifically with values of "pending",
1364 "active", "closed", or "terminated"), and of NOTIFY messages with
1365 no body.
1367 o Clarifies the durations of notification dialogs and presence
1368 authorizations, and how they are extended in SIP and handled in
1369 XMPP.
1371 o Removes the mapping of the XMPP 'id' attribute to the SIP "CSeq"
1372 header.
1374 o Describes the handling of multiple connected resources in XMPP.
1376 o Provides information about mitigations for leaks of presence
1377 information.
1379 Appendix B. Acknowledgements
1381 Thanks to the authors, contributors, and other individuals
1382 acknowledged in RFC 7248.
1384 Thanks to Saul Ibarra Corretge and Markus Isomaki for their reviews
1385 during working group consideration.
1387 Special thanks to Ben Campbell for identifying the underlying
1388 discrepancy that resulted in the need to obsolete RFC 7248.
1390 Thanks also to Markus Isomaki and Yana Stamcheva as the working group
1391 chairs and Alissa Cooper as the sponsoring Area Director.
1393 Author's Address
1395 Peter Saint-Andre
1396 Filament
1398 Email: peter@filament.com
1399 URI: https://filament.com/