From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7248.txt | 1683 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1683 insertions(+) create mode 100644 doc/rfc/rfc7248.txt (limited to 'doc/rfc/rfc7248.txt') diff --git a/doc/rfc/rfc7248.txt b/doc/rfc/rfc7248.txt new file mode 100644 index 0000000..3cfe235 --- /dev/null +++ b/doc/rfc/rfc7248.txt @@ -0,0 +1,1683 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Saint-Andre +Request for Comments: 7248 &yet +Category: Standards Track A. Houri +ISSN: 2070-1721 IBM + J. Hildebrand + Cisco Systems, Inc. + May 2014 + + + Interworking between the Session Initiation Protocol (SIP) and the + Extensible Messaging and Presence Protocol (XMPP): Presence + +Abstract + + This document defines a bidirectional protocol mapping for the + exchange of presence information between the Session Initiation + Protocol (SIP) and the Extensible Messaging and Presence Protocol + (XMPP). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7248. + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Saint-Andre, et al. Standards Track [Page 1] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Intended Audience ...............................................3 + 3. Terminology .....................................................3 + 4. Subscriptions to Presence Information ...........................4 + 4.1. Overview ...................................................4 + 4.2. XMPP to SIP ................................................5 + 4.2.1. Establishing a Presence Subscription ................5 + 4.2.2. Refreshing a Presence Subscription ..................9 + 4.2.3. Cancelling a Presence Subscription .................10 + 4.3. SIP to XMPP ...............................................12 + 4.3.1. Establishing a Presence Subscription ...............12 + 4.3.2. Refreshing a Presence Subscription .................14 + 4.3.3. Cancelling a Presence Subscription .................17 + 5. Notifications of Presence Information ..........................17 + 5.1. Overview ..................................................17 + 5.2. XMPP to SIP ...............................................19 + 5.3. SIP to XMPP ...............................................22 + 6. Requests for Presence Information ..............................24 + 6.1. XMPP to SIP ...............................................24 + 6.2. SIP to XMPP ...............................................25 + 7. Security Considerations ........................................26 + 8. References .....................................................27 + 8.1. Normative References ......................................27 + 8.2. Informative References ....................................27 + Appendix A. Acknowledgements ......................................29 + +1. Introduction + + In order to help ensure interworking between presence systems that + conform to the instant message / presence requirements [RFC2779], it + is important to clearly define protocol mappings between such + systems. Within the IETF, work has proceeded on two presence + technologies: + + o Various extensions to the Session Initiation Protocol ([RFC3261]) + for presence, in particular [RFC3856] + + o The Extensible Messaging and Presence Protocol (XMPP), which + consists of a formalization of the core XML streaming protocols + developed originally by the Jabber open-source community; the + relevant specifications are [RFC6120] for the XML streaming layer + and [RFC6121] for basic presence and instant-messaging extensions + + One approach to helping ensure interworking between these protocols + is to map each protocol to the abstract semantics described in + [RFC3860]; although that is the approach taken by both [RFC3922] and + + + +Saint-Andre, et al. Standards Track [Page 2] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + [SIMPLE-CPIM-MAPPING], to the best of our knowledge that approach has + never been implemented. The approach taken in this document is to + directly map semantics from one protocol to another (i.e., from SIP/ + SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) + to XMPP and vice versa), since that is how existing systems solve the + interworking problem. + + The architectural assumptions underlying such direct mappings are + provided in [RFC7247], including mapping of addresses and error + conditions. The mappings specified in this document cover basic + presence functionality. Mapping of more advanced functionality + (e.g., so-called "rich presence") is out of scope for this document. + +2. Intended Audience + + The documents in this series are intended for use by software + developers who have an existing system based on one of these + technologies (e.g., SIP) and would like to enable communication from + that existing system to systems based on the other technology (e.g., + XMPP). We assume that readers are familiar with the core + specifications for both SIP [RFC3261] and XMPP [RFC6120], with the + base document for this series [RFC7247], and with the following + presence-related specifications: + + o "A Presence Event Package for the Session Initiation Protocol + (SIP)" [RFC3856] + + o "Presence Information Data Format (PIDF)" [RFC3863] + + o "Extensible Messaging and Presence Protocol (XMPP): Instant + Messaging and Presence" [RFC6121] + + o "SIP-Specific Event Notification" [RFC6665] + +3. Terminology + + A number of terms used here (user, contact, subscription, + notification, etc.) are explained in [RFC3261], [RFC3856], [RFC6120], + and [RFC6121]. This document uses some, but not all, of the terms + defined in the Model for Presence and Instant Messaging [RFC2778]. + + In flow diagrams, SIP traffic is shown using arrows such as "***>", + whereas XMPP traffic is shown using arrows such as "...>". + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + + +Saint-Andre, et al. Standards Track [Page 3] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + +4. Subscriptions to Presence Information + +4.1. Overview + + Both XMPP and presence-aware SIP systems enable entities (often, but + not necessarily, human users) to subscribe to the presence of other + entities. XMPP presence subscriptions are specified in [RFC6121]. + Presence subscriptions using a SIP event package for presence are + specified in [RFC3856]. + + As described in [RFC6121], XMPP presence subscriptions are managed + using XMPP stanzas of type "subscribe", "subscribed", + "unsubscribe", and "unsubscribed". The main subscription states are: + + o "none" (neither the user nor the contact is subscribed to the + other's presence information) + + o "from" (the user has a subscription from the contact) + + o "to" (the user has a subscription to the contact's presence + information) + + o "both" (both user and contact are subscribed to each other's + presence information) + + As described in [RFC3856], SIP presence subscriptions are managed + through the use of SIP SUBSCRIBE events sent from a SIP user agent to + an intended recipient who is most generally referenced by a Presence + URI of the form but who might be referenced by a + SIP or SIPS (Session Initiation Protocol Secure) URI of the form + or . In practice, 'pres' URIs + are rarely used, which is why the examples in this document use 'sip' + URIs. + + The subscription models underlying XMPP and SIP differ mainly in the + fact that XMPP presence subscriptions are long-lived (indeed + permanent if not explicitly cancelled, so that a subscription need + never be refreshed during any given presence "session"), whereas SIP + presence subscriptions are short-lived (the default time-to-live of a + SIP presence subscription is 3600 seconds, as specified in + Section 6.4 of [RFC3856], so that a subscription needs to be + explicitly refreshed if it will have the appearance of being + permanent or even of lasting as long as the duration of a presence + "session"). This disparity has implications for the handling of + subscription cancellations in either direction and, from the SIP + side, subscription refreshes. + + + + + +Saint-Andre, et al. Standards Track [Page 4] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + +4.2. XMPP to SIP + +4.2.1. Establishing a Presence Subscription + + The following diagram illustrates the protocol flow for establishing + a presence subscription from an XMPP user to a SIP user, as further + explained in the text and examples after the diagram. + + XMPP XMPP XMPP-to-SIP SIP-to-XMPP SIP SIP + User Server Gateway Gateway Server User + | | | | | | + | (F1) XMPP | | | | | + | subscribe | | | | | + |..........>| | | | | + | | (F2) XMPP | | | | + | | subscribe | | | | + | |...........>| | | | + | | | (F3) SIP SUBSCRIBE | | + | | |**************************>| | + | | | | | (F4) SIP | + | | | | | SUBSCRIBE | + | | | | |**********>| + | | | | | (F5) SIP | + | | | | | 200 OK | + | | | | (F6) SIP |<**********| + | | | | 200 OK | (F7) SIP | + | | | |<***********| NOTIFY | + | | | | |<**********| + | | | | (F8) SIP | | + | | | | NOTIFY | | + | | | |<***********| | + | | | | (F9) SIP | | + | | | | 200 OK | | + | | | |***********>| | + | | | | | (F10) SIP | + | | (F11) XMPP subscribed | | 200 OK | + | |<..........................| |**********>| + | | (F12) XMPP presence | | | + | |<..........................| | | + | (F13) XMPP| | | | | + | subscribed| | | | | + |<..........| | | | | + | (F14) XMPP| | | | | + | presence | | | | | + |<..........| | | | | + + + + + + +Saint-Andre, et al. Standards Track [Page 5] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + An XMPP user (e.g., juliet@example.com) initiates a subscription by + sending a subscription request to a contact (e.g., + romeo@example.net), and the contact either accepts or declines the + request. If the contact accepts the request, the user will have a + subscription to the contact's presence information until (1) the user + unsubscribes or (2) the contact cancels the subscription. The + subscription request is encapsulated in a stanza of type + "subscribe": + + Example 1: XMPP User Subscribes to SIP Contact (F1) + + | + + Upon receiving such a stanza, the XMPP server to which + Juliet has connected needs to determine the identity of the + domainpart in the 'to' address, which it does by following the + procedures explained in Section 5 of [RFC7247]. If the domain is a + SIP domain, the XMPP server will hand off the stanza to + an associated XMPP-to-SIP gateway or connection manager that natively + communicates with presence-aware SIP servers. + + The XMPP-to-SIP gateway is then responsible for translating the XMPP + subscription request into a SIP SUBSCRIBE request addressed from the + XMPP user to the SIP user: + + Example 2: SIP Transformation of XMPP Subscription Request (F3) + + | SUBSCRIBE sip:romeo@example.net SIP/2.0 + | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk + | From: ;tag=ffd2 + | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C + | Event: presence + | Max-Forwards: 70 + | CSeq: 123 SUBSCRIBE + | Contact: + | Accept: application/pidf+xml + | Expires: 3600 + | Content-Length: 0 + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 6] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + Once the XMPP-to-SIP gateway has passed the SIP SUBSCRIBE off to the + SIP server (via the SIP-to-XMPP gateway) and the SIP server has + delivered the SIP SUBSCRIBE to the SIP user (F3 and F4; no example + shown for F4), the SIP user would then send a response indicating + acceptance of the subscription request: + + Example 3: SIP Accepts Subscription Request (F6) + + | SIP/2.0 200 OK + | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk + | From: ;tag=ffd2 + | To: ;tag=j89d + | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C + | CSeq: 234 SUBSCRIBE + | Contact: + | Expires: 3600 + | Content-Length: 0 + + In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD consider + the subscription state to be "neutral" until it receives a NOTIFY + message. Therefore, the SIP user or SIP-to-XMPP gateway at the SIP + user's domain SHOULD immediately send a NOTIFY message containing a + Subscription-State header whose value contains the string "active" + (see Section 5). + + + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 7] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + Example 4: SIP User Sends Presence Notification (F7) + + | NOTIFY sip:192.0.2.1 SIP/2.0 + | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk + | From: ;tag=yt66 + | To: ;tag=bi54 + | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C + | Event: presence + | Subscription-State: active;expires=499 + | Max-Forwards: 70 + | CSeq: 8775 NOTIFY + | Contact: + | Content-Type: application/pidf+xml + | Content-Length: 193 + | + | + | + | + | + | open + | away + | + | + | + + In response, the presence-aware SIP-to-XMPP gateway would send a 200 + OK to the SIP user (not shown here, since it is not translated into + an XMPP stanza). + + Upon receiving the first NOTIFY with a subscription state of active, + the XMPP-to-SIP gateway MUST generate a stanza of type + "subscribed": + + Example 5: XMPP User Receives Acknowledgement from SIP Contact (F13) + + | + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 8] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + As described in Section 5, the gateway MUST also generate a presence + notification addressed to the XMPP user: + + Example 6: XMPP User Receives Presence Notification from SIP Contact + (F14) + + | + +4.2.2. Refreshing a Presence Subscription + + It is the responsibility of the XMPP-to-SIP gateway to set the value + of the Expires header and to periodically renew the subscription on + the SIP side of the gateway so that the subscription appears to be + permanent to the XMPP user. For example, the XMPP-to-SIP gateway + SHOULD send a new SUBSCRIBE request to the SIP user whenever the XMPP + user initiates a presence session with the XMPP server by sending + initial presence to its XMPP server. The XMPP-to-SIP gateway also + SHOULD send a new SUBSCRIBE request to the SIP user whenever the SIP + presence subscription is scheduled to expire during the XMPP user's + active presence session. + + The rules regarding SIP SUBSCRIBE requests for the purpose of + establishing and refreshing a presence subscription are provided in + [RFC6665]. Those rules also apply to XMPP-to-SIP gateways. + Furthermore, an XMPP-to-SIP gateway MUST consider the XMPP + subscription to be permanently cancelled (and so inform the XMPP + user) if it receives a SIP response of 403, 489, or 603. By + contrast, it is appropriate to consider a SIP response of 423 or 481 + to be a transient error and to maintain the long-lived XMPP presence + subscription. [RFC6665] explains more detailed considerations about + the handling of SIP responses in relation to subscription requests + and refreshes. + + Finally, see the security considerations section (Section 7) of this + document for important information and requirements regarding the + security implications of subscription refreshes. + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 9] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + +4.2.3. Cancelling a Presence Subscription + + The following diagram illustrates the protocol flow for cancelling an + XMPP user's presence subscription to a SIP user, as further explained + in the text and examples after the diagram. + + XMPP XMPP XMPP-to-SIP SIP-to-XMPP SIP SIP + User Server Gateway Gateway Server User + | | | | | | + | (F15) XMPP| | | | | + |unsubscribe| | | | | + |..........>| | | | | + | | (F16) XMPP | | | | + | | unsubscribe| | | | + | |...........>| | | | + | | | (F17) SIP SUBSCRIBE | | + | | | Expires: 0 | | | + | | |**************************>| | + | | | | | (F18) SIP | + | | | | | SUBSCRIBE | + | | | | | Expires: 0| + | | | | |**********>| + | | | | | (F19) SIP | + | | | | | 200 OK | + | | | | |<**********| + | | | | (F20) SIP | | + | | | | 200 OK | | + | | | |<***********| | + | | (F21) XMPP unsubscribed | | | + | |<..........................| | | + | (F22) XMPP| | | | | + | unsubscribed | | | | + |<..........| | | | | + | | | | | | + + At any time after subscribing, the XMPP user can unsubscribe from the + contact's presence. This is done by sending a stanza of + type "unsubscribe": + + Example 7: XMPP User Unsubscribes from SIP Contact (F15) + + | + + + + + + + +Saint-Andre, et al. Standards Track [Page 10] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + The XMPP-to-SIP gateway is responsible for translating the + unsubscribe command into a SIP SUBSCRIBE request with the Expires + header set to a value of zero: + + Example 8: SIP Transformation of XMPP Unsubscribe (F17) + + | SUBSCRIBE sip:romeo@example.net SIP/2.0 + | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk + | From: ;tag=j89d + | Call-ID: 9D9F00DF-FCA9-4E7E-B970-80B638D5218A + | Event: presence + | Max-Forwards: 70 + | CSeq: 789 SUBSCRIBE + | Contact: + | Accept: application/pidf+xml + | Expires: 0 + | Content-Length: 0 + + Upon sending the transformed unsubscribe, the XMPP-to-SIP gateway + SHOULD send a stanza of type "unsubscribed" addressed to + the XMPP user: + + Example 9: XMPP User Receives Unsubscribed Notification (F22) + + | + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 11] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + +4.3. SIP to XMPP + +4.3.1. Establishing a Presence Subscription + + The following diagram illustrates the protocol flow for establishing + a presence subscription from a SIP user to an XMPP user, as further + explained in the text and examples after the diagram. + + SIP SIP SIP-to-XMPP XMPP-to-SIP XMPP XMPP + User Server Gateway Gateway Server User + | | | | | | + | (F23) SIP | | | | | + | SUBSCRIBE | | | | | + |**********>| | | | | + | | (F24) SIP | | | | + | | SUBSCRIBE | | | | + | |***********>| | | | + | | | (F25) XMPP subscribe | | + | | |..........................>| | + | | | | | (F26) XMPP| + | | | | | subscribe | + | | | | |..........>| + | | | | | (F27) XMPP| + | | | | | subscribed| + | | | | |<..........| + | | | | (F28) XMPP | | + | | | | subscribed | | + | | | |<...........| | + | | (F29) SIP 200 OK | | | + | |<**************************| | | + | (F30) SIP | | | | | + | 200 OK | | | | | + |<**********| | | | | + | | | | | | + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 12] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + A SIP user initiates a subscription to a contact's presence + information by sending a SIP SUBSCRIBE request to the contact. The + following is an example of such a request: + + Example 10: SIP User Subscribes to XMPP Contact (F23) + + | SUBSCRIBE sip:juliet@example.com SIP/2.0 + | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk + | From: ;tag=xfg9 + | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11 + | Event: presence + | Max-Forwards: 70 + | CSeq: 263 SUBSCRIBE + | Contact: + | Accept: application/pidf+xml + | Content-Length: 0 + + Notice that the Expires header was not included in the SUBSCRIBE + request; this means that the default value of 3600 (i.e., 3600 + seconds = 1 hour) applies. + + Upon receiving the SUBSCRIBE, the SIP server needs to determine the + identity of the domain portion of the Request-URI or To header, which + it does by following the procedures explained in Section 5 of + [RFC7247]. If the domain is an XMPP domain, the SIP server will hand + off the SUBSCRIBE to an associated SIP-to-XMPP gateway or connection + manager that natively communicates with XMPP servers. + + The SIP-to-XMPP gateway is then responsible for translating the + SUBSCRIBE into an XMPP subscription request addressed from the SIP + user to the XMPP user: + + Example 11: XMPP Transformation of SIP SUBSCRIBE (F25) + + | + + In accordance with [RFC6121], once it receives the stanza from the + XMPP-to-SIP gateway, the XMPP user's server MUST deliver the presence + subscription request to the XMPP user (or, if a subscription already + exists in the XMPP user's roster, the XMPP server SHOULD auto-reply + with a stanza of type "subscribed"). + + + + + + + + +Saint-Andre, et al. Standards Track [Page 13] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + If the XMPP user approves the subscription request, the XMPP server + then MUST return a stanza of type "subscribed" addressed + from the XMPP user to the SIP user. The XMPP-to-SIP gateway is + responsible for translating the stanza of type + "subscribed" into a SIP 200 OK response. + + If the XMPP user declines the subscription request, the XMPP server + then MUST return a stanza of type "unsubscribed" + addressed from the XMPP user to the SIP user and the XMPP-to-SIP + gateway MUST transform that stanza into an empty SIP NOTIFY message + with a Subscription-State of "terminated" and a reason of "rejected": + + Example 12: Subscription Request Rejected + + | NOTIFY sip:192.0.2.2 SIP/2.0 + | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk + | From: ;tag=ur93 + | To: ;tag=pq72 + | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11 + | Event: presence + | Subscription-State: terminated;reason=rejected + | Max-Forwards: 70 + | CSeq: 232 NOTIFY + | Contact: + | Content-Type: application/pidf+xml + | Content-Length: 0 + +4.3.2. Refreshing a Presence Subscription + + For as long as a SIP user is online and interested in receiving + presence notifications from the XMPP contact, the user's SIP user + agent is responsible for periodically refreshing the subscription by + sending an updated SUBSCRIBE request with an appropriate value for + the Expires header. In response, the presence-aware SIP-to-XMPP + gateway MUST send a SIP NOTIFY to the user agent (per [RFC6665]); if + the gateway has meaningful information about the availability state + of the XMPP user (e.g., obtained from the core presence session in + the XMPP server) then the NOTIFY MUST communicate that information + (e.g., by including a PIDF body [RFC3863] with the relevant data), + whereas if the gateway does not have meaningful information about the + availability state of the XMPP user then the NOTIFY MUST be empty as + allowed by [RFC6665]. + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 14] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + Once the SIP user ends its presence session, it is the responsibility + of the presence-aware SIP-to-XMPP gateway to properly handle the + difference between short-lived SIP presence subscriptions and long- + lived XMPP presence subscriptions. The gateway has two options when + the SIP user's subscription expires: + + o Cancel the subscription (i.e., treat it as temporary) and send an + XMPP stanza of type "unsubscribe" to the XMPP contact; + this honors the SIP semantic but will seem strange to the XMPP + contact (since it will appear that the SIP user has cancelled a + long-lived subscription). + + o Maintain the subscription (i.e., treat it as long-lived), and + + 1. send a SIP NOTIFY request to the SIP user containing a PIDF + document specifying that the XMPP contact now has a basic + status of "closed", including a Subscription-State of + "terminated" with a reason of "timeout" + + 2. send an XMPP stanza of type "unavailable" to the + XMPP contact; this violates the letter of the SIP semantic but + will seem more natural to the XMPP contact + + Which of these options a presence-aware SIP-to-XMPP gateway chooses + is up to the implementation. + + If the implementation chooses the first option, the protocol + generated would be as follows: + + Example 13: XMPP Handling of Temporary Subscription Expiry + + | + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 15] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + If the implementation chooses the second option, the protocol + generated would be as follows: + + Example 14: SIP Handling of Long-Lived Subscription Expiry + + | NOTIFY sip:192.0.2.2 SIP/2.0 + | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk + | From: ;tag=ur93 + | To: ;tag=pq72 + | Call-ID: 2B44E147-3B53-45E4-9D48-C051F3216D14 + | Event: presence + | Subscription-State: terminated;reason=timeout + | Max-Forwards: 70 + | CSeq: 232 NOTIFY + | Contact: + | Content-Type: application/pidf+xml + | Content-Length: 194 + | + | + | + | + | + | closed + | + | + | + + Example 15: XMPP Handling of Long-Lived Subscription Expiry + + | + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 16] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + +4.3.3. Cancelling a Presence Subscription + + At any time, the SIP user can cancel the subscription by sending a + SUBSCRIBE message whose Expires header is set to a value of zero + ("0"): + + Example 16: SIP User Cancels Subscription + + | SUBSCRIBE sip:juliet@example.com SIP/2.0 + | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk + | From: ;tag=yt66 + | Call-ID: 717B1B84-F080-4F12-9F44-0EC1ADE767B9 + | Event: presence + | Max-Forwards: 70 + | CSeq: 8775 SUBSCRIBE + | Contact: + | Expires: 0 + | Content-Length: 0 + + As above, upon receiving such a request, a presence-aware SIP-to-XMPP + gateway is responsible for doing one of the following: + + o Cancel the subscription (i.e., treat it as temporary) and send an + XMPP stanza of type "unsubscribe" to the XMPP contact. + + o Maintain the subscription (i.e., treat it as long-lived), and + + 1. send a SIP NOTIFY request to the SIP user containing a PIDF + document specifying that the XMPP contact now has a basic + status of "closed" + + 2. send a SIP SUBSCRIBE request to the SIP user with an Expires + header set to a value of "0" (zero) when it receives XMPP + presence of type "unavailable" from the XMPP contact + + 3. send an XMPP stanza of type "unavailable" to the + XMPP contact + +5. Notifications of Presence Information + +5.1. Overview + + Both XMPP and presence-aware SIP systems enable entities (often, but + not necessarily, human users) to send presence notifications to other + entities. At its most basic, the term "presence" refers to + information about an entity's "on/off" availability for communication + on a network. Often, this basic concept is supplemented by + information that further specifies the entity's context or status + + + +Saint-Andre, et al. Standards Track [Page 17] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + while available for communication; these availability states commonly + include "away" and "do not disturb". Some systems and protocols + extend the concepts of presence and availability even further and + refer to any relatively ephemeral information about an entity as a + kind of presence; categories of such "extended presence" include + geographical location (e.g., GPS coordinates), user mood (e.g., + grumpy), user activity (e.g., walking), and ambient environment + (e.g., noisy). In this document, we focus on the "least common + denominator" of network availability only, although future documents + might address broader notions of presence, including availability + states and extended presence. + + [RFC6121] defines how XMPP stanzas can indicate + availability (via absence of a 'type' attribute) or lack of + availability (via a 'type' attribute with a value of "unavailable"). + SIP presence using a SIP event package for presence is specified in + [RFC3856]. + + As described in [RFC6121], XMPP presence information about an entity + is communicated by means of an XML stanza sent over an + XML stream. In this document we will assume that such a + stanza is sent from an XMPP client to an XMPP server over an XML + stream negotiated between the client and the server, and that the + client is controlled by a human user. In general, XMPP presence is + sent by the user to the user's server and then broadcast to all + entities who are subscribed to the user's presence information. + + As described in [RFC3856], presence information about an entity is + communicated by means of a SIP NOTIFY event sent from a SIP user + agent to an intended recipient who is most generally referenced by a + Presence URI of the form but who might be + referenced by a SIP or SIPS URI of the form or + . + + This document addresses basic presence or network availability only, + not the various extensions to SIP and XMPP for "rich presence" such + as [RFC4480], [XEP-0107], and [XEP-0108]. + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 18] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + +5.2. XMPP to SIP + + When Juliet interacts with her XMPP client to modify her presence + information (or when her client automatically updates her presence + information, e.g., via an "auto-away" feature), her client generates + an XMPP stanza. The syntax of the stanza, + including required and optional elements and attributes, is defined + in [RFC6121]. The following is an example of such a stanza: + + Example 17: XMPP User Sends Presence Notification + + | + + Upon receiving such a stanza, the XMPP server to which Juliet has + connected broadcasts it to all subscribers who are authorized to + receive presence notifications from Juliet (this is similar to the + SIP NOTIFY method). For each subscriber, broadcasting the presence + notification involves either delivering it to a local recipient (if + the hostname in the subscriber's address matches one of the hostnames + serviced by the XMPP server) or attempting to route it to the foreign + domain that services the hostname in the subscriber's address. Thus, + the XMPP server needs to determine the identity of the domainpart in + the 'to' address, which it does by following the procedures discussed + in [RFC7247]. If the domain is a SIP domain, the XMPP server will + hand off the stanza to an associated XMPP-to-SIP gateway + or connection manager that natively communicates with presence-aware + SIP servers (no example shown). + + The XMPP-to-SIP gateway is then responsible for translating the XMPP + stanza into a SIP NOTIFY request and included PIDF + document from the XMPP user to the SIP user. + + Example 18: SIP Transformation of XMPP Presence Notification + + | NOTIFY sip:192.0.2.2 SIP/2.0 + | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk + | From: ;tag=gh19 + | To: ;tag=yt66 + | Contact: ;gr=balcony + | Call-ID: 2B44E147-3B53-45E4-9D48-C051F3216D14 + | Event: presence + | Subscription-State: active;expires=599 + | Max-Forwards: 70 + | CSeq: 157 NOTIFY + | Contact: + | Content-Type: application/pidf+xml + | Content-Length: 192 + | + + + +Saint-Andre, et al. Standards Track [Page 19] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + | + | + | + | + | open + | away + | + | + | + + The mapping of XMPP syntax elements to SIP syntax elements SHOULD be + as shown in the following table. (Mappings for elements not + mentioned are undefined.) + + +-----------------------------+---------------------------+ + | XMPP Element or Attribute | SIP Header or PIDF Data | + +-----------------------------+---------------------------+ + | stanza | "Event: presence" (1) | + +-----------------------------+---------------------------+ + | XMPP resource identifier | tuple 'id' attribute (2) | + +-----------------------------+---------------------------+ + | from | From | + +-----------------------------+---------------------------+ + | id | CSeq (3) | + +-----------------------------+---------------------------+ + | to | To | + +-----------------------------+---------------------------+ + | type | basic status (4) (5) | + +-----------------------------+---------------------------+ + | xml:lang | Content-Language | + +-----------------------------+---------------------------+ + | | priority for tuple (6) | + +-----------------------------+---------------------------+ + | | no mapping (7) | + +-----------------------------+---------------------------+ + | | | + +-----------------------------+---------------------------+ + + Table 1: Presence Syntax Mapping from XMPP to SIP + + Note the following regarding these mappings: + + (1) Only an XMPP stanza that lacks a 'type' attribute or + whose 'type' attribute has a value of "unavailable" SHOULD be + mapped by an XMPP-to-SIP gateway to a SIP NOTIFY request, since + those are the only stanzas that represent + notifications. + + + +Saint-Andre, et al. Standards Track [Page 20] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + (2) The PIDF schema defines the tuple 'id' attribute as having a + datatype of "xs:ID"; because this datatype is more restrictive + than the "xs:string" datatype for XMPP resourceparts (in + particular, a number is not allowed as the first character of an + ID), prepending the resourcepart with "ID-" or some other + alphabetic string when mapping from XMPP to SIP is RECOMMENDED. + + (3) In practice, XMPP stanzas often do not include the + 'id' attribute. + + (4) Because the lack of a 'type' attribute indicates that an XMPP + entity is available for communications, the gateway SHOULD map + that information to a PIDF basic status of "open". Because a + 'type' attribute with a value of "unavailable" indicates that an + XMPP entity is not available for communications, the gateway + SHOULD map that information to a PIDF basic status of "closed". + + (5) When the XMPP-to-SIP gateway receives XMPP presence of type + "unavailable" from the XMPP contact, it SHOULD (a) send a SIP + NOTIFY request to the SIP user containing a PIDF document + specifying that the XMPP contact now has a basic status of + "closed" and (b) send a SIP SUBSCRIBE request to the SIP user + with an Expires header set to a value of "0" (zero). + + (6) The value of the XMPP element is an integer between + -128 and +127, whereas the value of the PIDF + element's 'priority' attribute is a decimal number from zero to + one inclusive, with a maximum of three decimal places. If the + value of the XMPP element is negative, an XMPP-to- + SIP gateway MUST NOT map the value. If an XMPP-to-SIP gateway + maps positive values, it SHOULD treat XMPP priority 0 as PIDF + priority 0 and XMPP priority 127 as PIDF priority 1, mapping + intermediate values appropriately so that they are unique (e.g., + XMPP priority 1 to PIDF priority 0.007, XMPP priority 2 to PIDF + priority 0.015, and so on up through mapping XMPP priority 126 + to PIDF priority 0.992; note that this is an example only and + that the exact mapping is up to the implementation). + + (7) Some implementations support custom extensions to encapsulate + detailed information about availability; however, there is no + need to standardize a PIDF extension for this purpose, since + PIDF is already extensible and thus the element + (qualified by the 'jabber:client' namespace) can be included + directly in the PIDF XML. The examples in this document + illustrate this usage, which is RECOMMENDED. The most useful + values are likely "away" and "dnd", although note that the + latter value merely means "busy" and does not imply that a + server or client ought to block incoming traffic while the user + + + +Saint-Andre, et al. Standards Track [Page 21] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + is in that state. Naturally, a gateway can choose to translate + a custom extension into an established value of the + element [RFC6121] or translate a element into a custom + extension that the gateway knows is supported by the user agent + of the intended recipient. Unfortunately, this behavior does + not guarantee that information will not be lost; to help prevent + information loss, a gateway ought to include both the + element and the custom extension if the gateway cannot suitably + translate the custom value into a value. + +5.3. SIP to XMPP + + When Romeo changes his presence, his SIP user agent generates a SIP + NOTIFY request for any active subscriptions. The syntax of the + NOTIFY request is defined in [RFC3856]. The following is an example + of such a request: + + Example 19: SIP User Sends Presence Notification + + | NOTIFY sip:192.0.2.1 SIP/2.0 + | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk + | From: ;tag=yt66 + | To: ;tag=bi54 + | Contact: ;gr=orchard + | Call-ID: C33C6C9D-0F4A-42F9-B95C-7CE86B526B5B + | Event: presence + | Subscription-State: active;expires=499 + | Max-Forwards: 70 + | CSeq: 8775 NOTIFY + | Contact: + | Content-Type: application/pidf+xml + | Content-Length: 193 + | + | + | + | + | + | closed + | + | + | + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 22] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + Upon receiving the NOTIFY, the SIP server needs to determine the + identity of the domain portion of the Request-URI or To header, which + it does by following the procedures discussed in [RFC7247]. If the + domain is an XMPP domain, the SIP server will hand off the NOTIFY to + an associated SIP-to-XMPP gateway or connection manager that natively + communicates with XMPP servers. + + The SIP-to-XMPP gateway is then responsible for translating the + NOTIFY into an XMPP stanza addressed from the SIP user to + the XMPP user: + + Example 20: XMPP Transformation of SIP Presence Notification + + | + + The mapping of SIP syntax elements to XMPP syntax elements SHOULD be + as shown in the following table. (Mappings for elements not + mentioned are undefined.) + + +---------------------------+-----------------------------+ + | SIP Header or PIDF Data | XMPP Element or Attribute | + +---------------------------+-----------------------------+ + | basic status | type (1) | + +---------------------------+-----------------------------+ + | Content-Language | xml:lang | + +---------------------------+-----------------------------+ + | CSeq | id (2) | + +---------------------------+-----------------------------+ + | From | from | + +---------------------------+-----------------------------+ + | priority for tuple | (3) | + +---------------------------+-----------------------------+ + | To | to | + +---------------------------+-----------------------------+ + | | | + +---------------------------+-----------------------------+ + | | (4) | + +---------------------------+-----------------------------+ + + Table 2: Presence Syntax Mapping from SIP to XMPP + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 23] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + Note the following regarding these mappings: + + (1) A PIDF basic status of "open" SHOULD be mapped to no 'type' + attribute, and a PIDF basic status of "closed" SHOULD be mapped + to a 'type' attribute whose value is "unavailable". + + (2) This mapping is OPTIONAL. + + (3) See the notes following Table 1 of this document regarding + mapping of presence priority. + + (4) If a SIP implementation supports the element (qualified + by the 'jabber:client' namespace) as a PIDF extension for + availability status as described in the notes following Table 1 + of this document, the SIP-to-XMPP gateway is responsible for + including that element in the XMPP presence notification. + +6. Requests for Presence Information + + Both SIP and XMPP provide methods for requesting presence information + about another entity. + +6.1. XMPP to SIP + + In XMPP, a request for presence information is completed by sending a + stanza of type "probe": + + Example 21: XMPP Server Sends Presence Probe on Behalf of XMPP User + + | + + Note: As described in [RFC6121], presence probes are used by XMPP + servers to request presence on behalf of XMPP users; XMPP clients + are discouraged from sending presence probes, since retrieving + presence is a service that servers provide. + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 24] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + An XMPP-to-SIP gateway would transform the presence probe into its + SIP equivalent, which is a SUBSCRIBE request with an Expires header + value of zero: + + Example 22: SIP Transformation of XMPP Presence Probe + + | SUBSCRIBE sip:romeo@example.net SIP/2.0 + | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk + | From: ;tag=ffd2 + | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C + | Event: presence + | Max-Forwards: 70 + | CSeq: 123 SUBSCRIBE + | Contact: + | Accept: application/pidf+xml + | Expires: 0 + | Content-Length: 0 + + As described in [RFC3856], this cancels any subscription but causes a + NOTIFY to be sent to the subscriber, just as a presence probe does + (the transformation rules for presence notifications have been + previously described in Section 5.2 of this document). + +6.2. SIP to XMPP + + In SIP, a request for presence information is effectively completed + by sending a SUBSCRIBE with an Expires header value of zero: + + Example 23: SIP User Sends Presence Request + + | SUBSCRIBE sip:juliet@example.com SIP/2.0 + | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk + | From: ;tag=yt66 + | Call-ID: 717B1B84-F080-4F12-9F44-0EC1ADE767B9 + | Event: presence + | Max-Forwards: 70 + | CSeq: 8775 SUBSCRIBE + | Contact: + | Expires: 0 + | Content-Length: 0 + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 25] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + When honoring the long-lived semantics of an XMPP presence + subscription, a presence-aware SIP-to-XMPP gateway SHOULD translate + such a SIP request into a stanza of type "probe" if it + does not already have presence information about the contact: + + Example 24: XMPP Transformation of SIP Presence Request + + | + +7. Security Considerations + + Detailed security considerations for presence protocols are given in + [RFC2779], for SIP-based presence in [RFC3856] (see also [RFC3261]), + and for XMPP-based presence in [RFC6121] (see also [RFC6120]). + + The mismatch between long-lived XMPP presence subscriptions and + short-lived SIP presence subscriptions introduces the possibility of + an amplification attack launched from the XMPP network against a SIP + presence server (since each long-lived XMPP presence subscription + would typically result in multiple subscription refresh requests on + the SIP side of a gateway). Therefore, access to an XMPP-to-SIP + gateway SHOULD be restricted in various ways; among other things, + only an XMPP service that carefully controls account provisioning and + provides effective methods for the administrators to control the + behavior of registered users ought to host such a gateway (e.g., not + a service that offers open account registration), and a gateway ought + to be associated only with a single domain or trust realm (e.g., a + gateway hosted at simple.example.com ought to allow only users within + the example.com domain to access the gateway, not users within + example.org, example.net, or any other domain). If a SIP presence + server receives communications through an XMPP-to-SIP gateway from + users who are not associated with a domain that is so related to the + hostname of the gateway, it SHOULD (based on local service + provisioning) refuse to service such users or refuse to receive + traffic from the gateway. As a further check, whenever an XMPP-to- + SIP gateway seeks to refresh an XMPP user's long-lived subscription + to a SIP user's presence, it MUST first send an XMPP + stanza of type "probe" from the address of the gateway to the "bare + Jabber ID (JID)" (user@domain.tld) of the XMPP user, to which the + user's XMPP server MUST respond in accordance with [RFC6121]; this + puts an equal burden on the XMPP server and the SIP server. + + + + + + + + +Saint-Andre, et al. Standards Track [Page 26] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC3856] Rosenberg, J., "A Presence Event Package for the Session + Initiation Protocol (SIP)", RFC 3856, August 2004. + + [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, + W., and J. Peterson, "Presence Information Data Format + (PIDF)", RFC 3863, August 2004. + + [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Core", RFC 6120, March 2011. + + [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Instant Messaging and Presence", + RFC 6121, March 2011. + + [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, + July 2012. + + [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, + "Interworking between the Session Initiation Protocol + (SIP) and the Extensible Messaging and Presence Protocol + (XMPP): Architecture, Addresses, and Error Handling", + RFC 7247, May 2014. + +8.2. Informative References + + [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for + Presence and Instant Messaging", RFC 2778, February 2000. + + [RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant + Messaging / Presence Protocol Requirements", RFC 2779, + February 2000. + + [RFC3860] Peterson, J., "Common Profile for Instant Messaging + (CPIM)", RFC 3860, August 2004. + + + + + +Saint-Andre, et al. Standards Track [Page 27] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + + [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and + Presence Protocol (XMPP) to Common Presence and Instant + Messaging (CPIM)", RFC 3922, October 2004. + + [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. + Rosenberg, "RPID: Rich Presence Extensions to the Presence + Information Data Format (PIDF)", RFC 4480, July 2006. + + [SIMPLE-CPIM-MAPPING] + Campbell, B. and J. Rosenberg, "CPIM Mapping of SIMPLE + Presence and Instant Messaging", Work in Progress, + June 2002. + + [XEP-0107] Saint-Andre, P. and R. Meijer, "User Mood", XSF XEP 0107, + October 2008, . + + [XEP-0108] Meijer, R. and P. Saint-Andre, "User Activity", + XSF XEP 0108, October 2008, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 28] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + +Appendix A. Acknowledgements + + The authors wish to thank the following individuals for their + feedback: Chris Christou, Fabio Forno, Adrian Georgescu, Philipp + Hancke, Saul Ibarra Corretge, Markus Isomaki, Olle Johansson, Paul + Kyzivat, Salvatore Loreto, Michael Lundberg, Daniel-Constantin + Mierla, and Tory Patnoe. + + Dave Crocker provided helpful and detailed feedback on behalf of the + Applications Area Directorate. + + Ben Laurie performed a review on behalf of the Security Directorate, + resulting in improvements to the security considerations. + + During IESG review, Pete Resnick caught several oversights in the + document with regard to interoperability. + + The authors gratefully acknowledge the assistance of Markus Isomaki + and Yana Stamcheva as the working group chairs and Gonzalo Camarillo + as the sponsoring Area Director. + + Some text in this document was borrowed from [RFC3922]. + + Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for + employing him during his work on earlier versions of this document. + + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 29] + +RFC 7248 SIP-XMPP Interworking: Presence May 2014 + + +Authors' Addresses + + Peter Saint-Andre + &yet + + EMail: ietf@stpeter.im + + + Avshalom Houri + IBM + Rorberg Building, Pekris 3 + Rehovot 76123 + Israel + + EMail: avshalom@il.ibm.com + + + Joe Hildebrand + Cisco Systems, Inc. + 1899 Wynkoop Street, Suite 600 + Denver, CO 80202 + USA + + EMail: jhildebr@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre, et al. Standards Track [Page 30] + -- cgit v1.2.3