RFC 3856

A Presence Event Package for the Session Initiation Protocol (SIP)

📅 published August 2004, from ietf

RFC 3856: A Presence Event Package for the Session Initiation Protocol (SIP) 💖

Okay bestie, let's get into it! 🎀 This one is by J. Rosenberg from dynamicsoft, dated August 2004, and it's on the Standards Track 🦋. It doesn't list any RFCs it obsoletes or updates, so it's a standalone move ✨. The whole point is using SIP, the Session Initiation Protocol, for presence, which means knowing whether people are reachable and willing to talk 🫶.

Status of this Memo

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2004) ©️ 🌸.

Abstract

Okay so this doc explains how SIP gets used for subscribing to presence and getting notified about it 🔥. Presence here means how willing and able a user is to communicate with other users on the network ✨. Historically presence was just "on-line" and "off-line," but the idea here is way broader, ngl 💀. Subscriptions and notifications work by defining an event package inside the general SIP event notification framework 🎀. Also, this protocol is compliant with the Common Presence Profile (CPP) framework, which is so iconic 👑.

Table of Contents

1.  Introduction ................................................   2
2.  Terminology .................................................   3
3.  Definitions .................................................   3
4.  Overview of Operation .......................................   4
5.  Usage of Presence URIs ......................................   6
6.  Presence Event Package ......................................   7
    6.1.  Package Name ..........................................   8
    6.2.  Event Package Parameters ..............................   8
    6.3.  SUBSCRIBE Bodies ......................................   8
    6.4.  Subscription Duration .................................   9
    6.5.  NOTIFY Bodies .........................................   9
    6.6.  Notifier Processing of SUBSCRIBE Requests .............   9
          6.6.1. Authentication .................................  10
          6.6.2. Authorization ..................................  10
    6.7.  Notifier Generation of NOTIFY Requests ................  11
    6.8.  Subscriber Processing of NOTIFY Requests ..............  13
    6.9.  Handling of Forked Requests ...........................  13
    6.10. Rate of Notifications .................................  14
    6.11. State Agents ..........................................  14
          6.11.1. Aggregation, Authentication, and Authorization.  14
          6.11.2. Migration .....................................  15
7.  Learning Presence State .....................................  16
    7.1.  Co-location ...........................................  16
    7.2.  REGISTER ..............................................  16
    7.3.  Uploading Presence Documents ..........................  17
8.  Example Message Flow ........................................  17
9.  Security Considerations .....................................  20
    9.1.  Confidentiality .......................................  20
    9.2.  Message Integrity and Authenticity ....................  21
    9.3.  Outbound Authentication ...............................  22
    9.4.  Replay Prevention .....................................  22
    9.5.  Denial of Service Attacks Against Third Parties .......  22
    9.6.  Denial Of Service Attacks Against Servers .............  23
10. IANA Considerations .........................................  23
11. Contributors ................................................  24
12. Acknowledgements ............................................  25
13. Normative References ........................................  25
14. Informative References ......................................  26
15. Author's Address ............................................  26
16. Full Copyright Statement ....................................  27

1. Introduction ✨

Okay so presence, also called presence information, is about a user's ability and willingness to communicate across a bunch of devices 📱. RFC 2778 [10] defines a model and terminology for systems that give out presence info 🧚. In that model, a presence service is a system that takes in, stores, and distributes presence information to interested parties, who are called watchers 👀. A presence protocol is a protocol that provides a presence service over the Internet or any IP network 🌸.

This document proposes using SIP [1] as a presence protocol 🦋. It does this by making a concrete version of the general event notification framework defined for SIP [2], so it uses the SUBSCRIBE and NOTIFY methods from there 💅. Specifically, this document defines an event package, as described in RFC 3265 [2] 🎀. SIP is honestly so well suited for this 😭. SIP location services already hold presence information in the form of registrations 🔥. SIP networks can also route requests from any user on the network to the server holding that user's registration state 🌈. Since that state is a key part of user presence, SIP networks can let SUBSCRIBE requests get routed to the same server 👑. So SIP networks can be reused to set up global connectivity for presence subscriptions and notifications 💜.

This event package is built around the idea of a presence agent 🧚. A presence agent is a new logical entity that can accept subscriptions, store subscription state, and generate notifications when presence changes ⭐. It's described as logical because it usually lives on the same box as another entity 🙈.

This event package is also compliant with the Common Presence Profile (CPP) framework defined in [3] 🫶. That means SIP for presence can easily interwork with other presence systems that are CPP compliant 🍓.

2. Terminology 🎀

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] 📚. They show requirement levels for compliant implementations 💅.

3. Definitions 💖

This document uses the terms defined in RFC 2778 [10] 🦋. On top of that, the following terms are defined or clarified further ✨:

  • Presence User Agent (PUA): A PUA manipulates presence information for a presentity 🎀. That can happen as a side effect of something else, like sending a SIP REGISTER request to add a new Contact, or it can be done directly by publishing presence documents 📄. We explicitly allow multiple PUAs per presentity 🌈. So a user can have lots of devices, like a cell phone and a Personal Digital Assistant (PDA), and each one is independently generating a piece of the overall presence info for that presentity 📱. PUAs push data into the presence system but sit outside of it, since they don't receive SUBSCRIBE messages or send NOTIFY messages 🙅‍♀️.
  • Presence Agent (PA): A presence agent is a SIP user agent that can receive SUBSCRIBE requests, respond to them, and generate notifications of presence state changes 🔥. A presence agent must know the presence state of a presentity 🧠. That means it has to have access to the presence data that PUAs manipulate for that presentity 🗂️. One way to do this is to co-locate the PA with the proxy/registrar 🏠. Another way is to co-locate it with the presence user agent of the presentity 🫶. These aren't the only options, though, and this specification makes no recommendations about where the PA function should be located 🤷‍♀️. A PA is always addressable with a SIP URI that uniquely identifies the presentity, like sip:joe@example.com 💌. There can be multiple PAs for one presentity, and each one handles some subset of the total subscriptions currently active for that presentity 🧚. A PA is also a notifier (defined in RFC 3265 [2]) that supports the presence event package 👑.
  • Presence Server: A presence server is a physical entity that can act as either a presence agent or a proxy server for SUBSCRIBE requests 🖥️. When it acts as a PA, it knows the presence information of the presentity through some protocol means 🧩. When it acts as a proxy, the SUBSCRIBE requests get proxied to another entity that may act as a PA 🔁.
  • Edge Presence Server: An edge presence server is a presence agent that is co-located with a PUA 🌸. It knows the presence information of the presentity because it sits with the entity that manipulates that presence information 💜.

4. Overview of Operation ✨

okay so this section is basically a tour of how this event package works 🦋 some of it is written here, some lives in the SIP event framework [2], and some is in the SIP spec [1]. it's meant for people who are only kinda familiar with those specs, but ngl the real deets need you to already know SIP events and SIP itself 💅

okay so when a subscriber (the entity that wants to know about someone's presence info 👀) wants to learn about a user, it makes a SUBSCRIBE request. this request names the desired presentity in the Request-URI, and that can be a SIP URI, a SIPS URI [1], or a presence (pres) URI [3] 🎀 the SUBSCRIBE gets carried through SIP proxies like any other SIP request, no special treatment. in most cases it ends up at a presence server, and that server can either answer it itself (in which case it's acting as the presence agent for the presentity ✨), or pass it along to an edge presence server. if the edge presence server handles the subscription, then it's the presence agent for the presentity 🧚

whether a presence server proxies or terminates the SUBSCRIBE is a local decision, totally up to it 💖 this doc does describe one way to set that up, using REGISTER, so that's there if you're curious.

the presence agent (PA for short, whether it's in the presence server or the edge one) authenticates the subscription first, then authorizes it. how authorization works is outside the scope of this protocol, and we expect lots of different mechanisms to get used 🌈 if it's authorized, the PA sends back a 200 OK. if authorization couldn't be obtained right now, the subscription is "pending" and the PA sends back a 202 instead 🫶 either way, the PA then sends an immediate NOTIFY with the state of the presentity and of the subscription.

here's the spicy part 🙈 the presentity state can be bogus for a pending subscription. like, it might say offline no matter what the actual state is. this is to protect the presentity's privacy, because they might not want to reveal that they haven't given the subscriber authorization. super iconic of the protocol to think about that 😭 as the presentity's state changes, the PA sends NOTIFYs with those changes to every subscriber that has an authorized subscription. changes to the subscription itself can trigger NOTIFY requests too. that state rides along in the Subscription-State header field of the NOTIFY, and it'd usually tell you whether the subscription is active or pending 💅

the SUBSCRIBE message sets up a "dialog" with the presence agent 🦋 a dialog is defined in RFC 3261 [1], and it's basically the SIP state between two entities so they can do peer-to-peer message exchanges. that state includes sequence numbers for messages going in both directions (SUBSCRIBE from the subscriber, NOTIFY from the presence agent), plus a route set and a remote target URI. the route set is a list of SIP (or SIPS) URIs that point at the proxy servers to be visited on the path of SUBSCRIBE refreshes or NOTIFY requests. the remote target URI is the SIP or SIPS URI for whatever the message is aiming at: the subscriber in the case of a NOTIFY, or the presence agent in the case of a SUBSCRIBE refresh 🎀

SIP also has a procedure called record-routing ✨ it lets proxy servers ask to be on the path of NOTIFY messages and SUBSCRIBE refreshes. this gets done by inserting a URI into the Record-Route header field in the initial SUBSCRIBE request. proxies really be wanting a seat at the table 👑

the subscription lasts for a duration that's negotiated as part of the initial SUBSCRIBE. if the subscriber wants to keep it, they need to refresh it before it expires 🫠 that's done by sending a SUBSCRIBE refresh within the same dialog the initial SUBSCRIBE made. the refresh is nearly identical to the first one, but it has a tag in the To header field, a higher CSeq header field value, and possibly a set of Route header field values that spell out the path of proxies the request should take 🌸

the subscriber can end the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field value of zero 💀 that causes an immediate termination. the PA then generates a NOTIFY with the most recent state. and honestly this part is so clean: the PA handles an Expires of zero the exact same way it handles any other expiration value. pending or authorized SUBSCRIBEs both result in a triggered NOTIFY with the current presentity and subscription state 🧚

the PA can also end the subscription whenever it wants ✨ it does that by sending a NOTIFY with a Subscription-State header field saying the subscription has been terminated. a reason parameter can be included to explain why 💜

and if you just want to peek at the current presence state once, you can fetch it 👀 that's a one-time notification with the current state, and you get it by sending a SUBSCRIBE with an immediate expiration 🍓

5. Usage of Presence URIs

okay so a presentity gets identified in the most general way through a presence URI [3], which looks like pres:user@domain 🦋 these URIs get resolved into protocol-specific URIs, like a SIP or SIPS URI, using domain-specific mapping policies that live on a server 🌈

it's very possible that a user has both a SIP (and/or SIPS) URI and a pres URI, to identify both themself and other people 💅 and that raises questions about how these URIs relate to each other and which one should get used 🙈

sometimes a user starts with one format, like a pres URI, and then learns a URI in a different format through some protocol means ✨ for example, a SUBSCRIBE sent to a pres URI results in learning a SIP or SIPS URI for the presentity from the Contact header field of the 200 OK to that SUBSCRIBE. another example: a DNS mechanism might get defined that lets you look up a pres URI and get a SIP or SIPS URI back 🧚 when one URI is learned from another through protocol means, those means often come with some kind of scoping that limits how long the learned URI lives. DNS, for example, has a TTL that limits the scope of the URI ⏳ these scopes are super useful for avoiding stale or conflicting URIs that point at the same resource. so to make sure a user can always tell whether a learned URI is still valid, it is RECOMMENDED that systems which provide lookup services for presence URIs have some kind of scoping mechanism 🫶

if a subscriber only knows the protocol-independent pres URI for a presentity, it follows the procedures defined in [5] 🎀 those procedures put the pres URI in the Request-URI of the SIP request, and then use the DNS procedures from [5] to figure out which host the SIP request should go to. a local outbound proxy can also be used instead, as specified in RFC 3261 [1] 💖

now if the subscriber knows both the protocol-independent pres URI and the SIP or SIPS URI for the same presentity, and both are valid (per the stuff above), it SHOULD use the pres URI format 👑 and if the subscriber only knows the SIP URI for the presentity, then that URI gets used and standard RFC 3261 processing happens 🌸 when the pres URI is used, any proxies along the path of the SUBSCRIBE that don't understand the URI scheme will reject the request 😭 so it's expected that lots of systems will initially get deployed giving users only a SIP URI. that's just the reality of rollout 🍓

SUBSCRIBE messages also carry logical identifiers that define the originator and recipient of the subscription (the To and From header fields) ✨ those headers can take either a pres URI or a SIP URI. if the subscriber knows both a pres and a SIP URI for its own identity, it SHOULD use the pres URI in the From header field 🦋 and similarly, if the subscriber knows both a pres and a SIP URI for the desired presentity, it SHOULD use the pres URI in the To header field 💅

using the pres URI instead of the SIP URI inside the SIP message supports interoperability through gateways to other CPP-compliant systems 🌈 it's a protocol-independent form of identification that can be passed between systems. without it, gateways would have to map SIP URIs into the addressing format of other protocols. usually that gets done by converting the SIP URI into the form <foreign-protocol-scheme>:<encoded SIP URI>@<gateway> 📧 this is commonly done in email systems, and it has lots of known problems 💀

the pres URI usage is a SHOULD, and not a MUST 🫶 that's so it can allow for cases where it's known there are no gateways around, or where using the pres URI would cause interoperability problems with SIP components that don't support it.

the Contact, Record-Route and Route fields don't identify logical entities 🧚 they identify concrete ones used for SIP messaging. SIP [1] has the rules for how to build those ✨

6. Presence Event Package

okay so the SIP event framework [2] defines a SIP extension for subscribing to events and getting notified about them 🦋 it leaves the definition of lots of event details to concrete extensions, which are called event packages 🌈 this document qualifies as an event package 💖 and this section fills in all the info that RFC 3265 [2] requires every event package to have 👑

6.1. Package Name

the name of this package is "presence" 🎀 as RFC 3265 [2] specifies, this value shows up in the Event header field in SUBSCRIBE and NOTIFY requests.

Example:

Event: presence

6.2. Event Package Parameters

the SIP event framework lets event packages define extra parameters that get carried in the Event header field 🌸 but this package, presence, doesn't define any extra parameters. keeping it simple, bestie 💅

6.3. SUBSCRIBE Bodies

a SUBSCRIBE request MAY contain a body 🦋 what the body is for depends on its type. subscriptions will normally not have bodies 🫠

the Request-URI identifies the presentity, and combined with the event package name, that's enough for presence ✨ no body needed.

one type of body that can go in a SUBSCRIBE is a filter document 🧚 these filters ask for only certain presence events to generate notifications, or they ask to restrict the set of data returned in NOTIFY requests. for example, a presence filter might say notifications should only get generated when the status of the user's instant inbox [10] changes 👀 it might also say the content of those notifications should only contain the status of the instant inbox. filter documents aren't specified in this document, and at the time of writing they're expected to be the subject of future standardization work 🌈

honoring these filters is at the policy discretion of the PA 💜

if the SUBSCRIBE request doesn't contain a filter, that tells the PA that no filter is to be applied 🍓 and then the PA SHOULD send NOTIFY requests at the discretion of its own policy 🎀

6.4. Subscription Duration ⏰

Okay so user presence changes because of, like, SO many things 🙈 Some examples:

  • Turning your cell phone on and off 📱
  • Modifying the registration from a softphone 📞
  • Changing your status on an instant messaging tool 💬

These events are usually triggered by human intervention 🙋 and happen anywhere from every few seconds to every few hours. So subscriptions should have an expiration in the middle of that range, which is roughly one hour ✨. Therefore, the default expiration time for subscriptions in this package is 3600 seconds. As per RFC 3265 [2], the subscriber MAY specify an alternate expiration in the Expires header field 💅.

6.5. NOTIFY Bodies 📬

As described in RFC 3265 [2], the NOTIFY message will contain bodies that describe the state of the subscribed resource 🫶 This body is in a format listed in the Accept header field of the SUBSCRIBE, or a package-specific default if the Accept header field was omitted from the SUBSCRIBE.

In this event package, the body of the notification contains a presence document 💜 This document describes the presence of the presentity that was subscribed to. All subscribers and notifiers MUST support the "application/pidf+xml" presence data format described in [6]. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/pidf+xml". If the header field is present, it MUST include "application/pidf+xml", and MAY include any other types capable of representing user presence.

6.6. Notifier Processing of SUBSCRIBE Requests 🕵️‍♀️

Based on the proxy routing procedures defined in the SIP specification, the SUBSCRIBE request will arrive at a presence agent (PA) 🦋 This subsection defines package-specific processing at the PA of a SUBSCRIBE request. General processing rules for requests are covered in Section 8.2 of RFC 3261 [1], in addition to general SUBSCRIBE processing in RFC 3265 [2].

User presence is highly sensitive information 😭 Because the implications of divulging presence information can be severe, strong requirements are imposed on the PA regarding subscription processing, especially related to authentication and authorization.

6.6.1. Authentication 🔐

A presence agent MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in RFC 3261 [1]. Note that digest is mandatory to implement, as specified in RFC 3261.

In single-domain systems, where the subscribers all have shared secrets with the PA, the combination of digest authentication over Transport Layer Security (TLS) [7] provides a secure and workable solution for authentication. This use case is described in Section 26.3.2.1 of RFC 3261 [1].

In inter-domain scenarios, establishing an authenticated identity of the subscriber is harder 🥲 It is anticipated that authentication will often be established through transitive trust. SIP mechanisms for network asserted identity can be applied to establish the identity of the subscriber [11].

A presentity MAY choose to represent itself with a SIPS URI ✨ By "represent itself", it means that the user represented by the presentity hands out, on business cards, web pages, and so on, a SIPS URI for their presentity. The semantics associated with this URI, as described in RFC 3261 [1], require TLS usage on each hop between the subscriber and the server in the domain of the URI. This provides additional assurances (but no absolute guarantees) that identity has been verified at each hop.

Another mechanism for authentication is S/MIME 💌 Its usage with SIP is described fully in RFC 3261 [1]. It provides an end-to-end authentication mechanism that can be used for a PA to establish the identity of the subscriber.

6.6.2. Authorization 🪪

Once authenticated, the PA makes an authorization decision. A PA MUST NOT accept a subscription unless authorization has been provided by the presentity. The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page. Authorization may have been provided by means of uploading of some kind of standardized access control list document. Back end authorization servers, such as a DIAMETER [12] server, can also be used. It is also useful to be able to query the user for authorization following the receipt of a subscription request for which no authorization information has been provided. The "watcherinfo" event template package for SIP [8] defines a means by which a presentity can become aware that a user has attempted to subscribe to it, so that it can then provide an authorization decision.

Authorization decisions can be very complex 🌀 Ultimately, all authorization decisions can be mapped into one of three states: rejected, successful, and pending. Any subscription for which the client is authorized to receive information about some subset of presence state at some points in time is a successful subscription. Any subscription for which the client will never receive any information about any subset of the presence state is a rejected subscription. Any subscription for which it is not yet known whether it is successful or rejected is pending. Generally, a pending subscription occurs when the server cannot obtain authorization at the time of the subscription, but may be able to do so at a later time, perhaps when the presentity becomes available.

The appropriate response codes for conveying a successful, rejected, or pending subscription (200, 403 or 603, and 202, respectively) are described in RFC 3265 [2].

If the resource is not in a meaningful state, RFC 3265 [2] allows the body of the initial NOTIFY to be empty. In the case of presence, that NOTIFY MAY contain a presence document. This document would indicate whatever presence state the subscriber has been authorized to see; it is interpreted by the subscriber as the current presence state of the presentity. For pending subscriptions, the state of the presentity SHOULD include some kind of textual note that indicates a pending status.

Polite blocking, as described in [13], is possible by generating a 200 OK to the subscription even though it has been rejected (or marked pending) 🙊 Of course, an immediate NOTIFY will still be sent. The contents of the presence document in such a NOTIFY are at the discretion of the implementor, but SHOULD be constructed in such a way as to not reveal to the subscriber that their request has actually been blocked. Typically, this is done by indicating "offline" or equivalent status for a single contact address. 👻

6.7. Notifier Generation of NOTIFY Requests 📣

RFC 3265 details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the presence event package.

A PA MAY send a NOTIFY at any time. Typically, it will send one when the state of the presentity changes. The NOTIFY request MAY contain a body indicating the state of the presentity. The times at which the NOTIFY is sent for a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that governs the subscription. This protocol in no way limits the scope of such policies. As a baseline, a reasonable policy is to generate notifications when the state of any of the presence tuples changes. These notifications would contain the complete and current presence state of the presentity as known to the presence agent. Future extensions can be defined that allow a subscriber to request that the notifications contain changes in presence information only, rather than complete state.

In the case of a pending subscription, when final authorization is determined, a NOTIFY can be sent. If the result of the authorization decision was success, a NOTIFY SHOULD be sent and SHOULD contain a presence document with the current state of the presentity. If the subscription is rejected, a NOTIFY MAY be sent. As described in RFC 3265 [2], the Subscription-State header field indicates the state of the subscription.

The body of the NOTIFY MUST be sent using one of the types listed in the Accept header field in the most recent SUBSCRIBE request, or using the type "application/pidf+xml" if no Accept header field was present.

The means by which the PA learns the state of the presentity are also outside the scope of this recommendation. Registrations can provide a component of the presentity state. However, the means by which a PA uses registrations to construct a presence document are an implementation choice. If a PUA wishes to explicitly inform the presence agent of its presence state, it should explicitly publish the presence document (or its piece of it) rather than attempting to manipulate their registrations to achieve the desired result.

For reasons of privacy, it will frequently be necessary to encrypt the contents of the notifications 🔒 This can be accomplished using S/MIME. The encryption can be performed using the key of the subscriber as identified in the From field of the SUBSCRIBE request. Similarly, integrity of the notifications is important to subscribers. As such, the contents of the notifications MAY provide authentication and message integrity using S/MIME. Since the NOTIFY is generated by the presence server, which may not have access to the key of the user represented by the presentity, it will frequently be the case that the NOTIFY is signed by a third party. It is RECOMMENDED that the signature be by an authority over the domain of the presentity. In other words, for a user pres:user@example.com, the signator of the NOTIFY SHOULD be the authority for example.com.

6.8. Subscriber Processing of NOTIFY Requests 🥰

RFC 3265 [2] leaves it to event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request, including any logic required to form a coherent resource state.

In this specification, each NOTIFY contains either no presence document, or a document representing the complete and coherent state of the presentity. Within a dialog, the presence document in the NOTIFY request with the highest CSeq header field value is the current one. When no document is present in that NOTIFY, the presence document present in the NOTIFY with the next highest CSeq value is used. Extensions which specify the use of partial state for presentities will need to dictate how coherent state is achieved.

6.9. Handling of Forked Requests ✨

Okay so RFC 3265 [2] says every package has to describe how forked SUBSCRIBE requests get handled 🍴

This spec only lets a single dialog be built from one initial SUBSCRIBE request. That's the whole trick: it guarantees that only one PA is generating notifications for a particular subscription to a particular presentity 🔒

The result is that a presentity can have multiple PAs active, but they should be homogeneous, so that each one can generate the same set of notifications for the presentity. Supporting heterogeneous PAs, where each one generates notifications for a subset of the presence data, is complex and a total pain to manage 😭 It would make the subscriber act as the aggregator for presence data, and this aggregation function can only reasonably be performed by agents representing the presentity. So if aggregation is needed, it MUST be done in a PA representing the presentity 💅

Section 4.4.9 of RFC 3265 [2] covers the processing needed to guarantee that a single dialog gets created in response to a SUBSCRIBE request 🧚

6.10. Rate of Notifications 🔥

RFC 3265 [2] says each package has to specify the maximum rate at which notifications can be sent ⏱️

A PA SHOULD NOT generate notifications for a single presentity at a rate of more than once every five seconds. Main character energy is not spamming your bestie every 0.2 seconds 🙈💜

6.11. State Agents 🌈

RFC 3265 [2] says each package has to consider the role of state agents, and if they're used, specify how authentication and authorization get done 📋

State agents are core to this package, no cap 💖 Whenever the PA is not co-located with the PUA for the presentity, the PA is acting as a state agent. It collects presence state from the PUA and aggregates it into a presence document. Because there can be multiple PUA, you need a centralized state agent to do that aggregation, which is why state agents are fundamental to presence. They even have a specific term for them: a presence server 🖥️✨

6.11.1. Aggregation, Authentication, and Authorization 🎀

The way aggregation happens inside the state agent is purely a matter of policy. The policy will typically mix the presentity's wishes with the provider's wishes. This document doesn't restrict the set of policies that can be applied, so go wild 🫶

Still, the state agent clearly needs access to the state of the presentity. That state gets manipulated by the PUA, and one way the state agent can grab it is by subscribing to it. So if there were 5 PUA manipulating presence state for a single presentity, the state agent would generate 5 subscriptions, one to each PUA 🙃 For this to actually work well, all PUA SHOULD be capable of acting as a PA for the state they manipulate, and they should authorize subscriptions that can be authenticated as coming from the domain of the presentity 🔐

Using state agents doesn't really change how the PA does authentication. Any of the SIP authentication mechanisms can be used by a state agent. However, digest authentication means the state agent has to know the shared secret between the presentity and the subscriber. That means you need some way to securely transfer the shared secrets from the presentity to the state agent 🗝️

Authorization is where state agents really shake things up 😤 As stated in Section 6.6, a PA is required to authorize all subscriptions. If no explicit authorization policy has been defined, the PA will need to ask the user for authorization. In a presence edge server (where the PUA is co-located with the PUA), this is trivially done. But when state agents are used (i.e., a presence server), you need a way to alert the user that an authorization decision is needed. That's the reason for the watcherinfo event template-package [8]. All state agents SHOULD support the watcherinfo template-package 👑

6.11.2. Migration 🦋

Sometimes it makes sense for the PA function to migrate from one server to another. For example, for reasons of scale, the PA function might live in the presence server when the PUA isn't running, and then when the PUA connects to the network, the PA migrates subscriptions over to it to cut down on state in the network. The mechanism for doing that is described in Section 3.3.5 of RFC 3265 [2]. However, packages need to define under what conditions a migration would actually happen 🌸

A PA MAY choose to migrate subscriptions at any time, through configuration, or through dynamic means. The REGISTER request gives one dynamic way for a presence server to discover that the function can migrate to a PUA. Specifically, if a PUA wants to show it supports the PA function, it SHOULD use the callee capabilities specification [9] to indicate that it supports the SUBSCRIBE request method and the presence event package. Those two together define a PA 🧩 Of course, a presence server can always attempt a migration without these explicit hints. If it fails with either a 405 or 489 response code, the server knows the PUA doesn't support the PA function. In that case, the server itself will need to act as a PA for that subscription request. Once a failure like that has happened, the server SHOULD NOT attempt further migrations to that PUA for the duration of its registration. To avoid the extra traffic from these failed requests, though, a presence server SHOULD support the callee capabilities extension 🫠

Also, just indicating support for the SUBSCRIBE request and the presence event package isn't enough to migrate subscriptions 🚫 A PA SHOULD NOT migrate the subscription if it is composing aggregated presence documents received from multiple PUA.

7. Learning Presence State 🌸

Presence information can be obtained by the PA in lots of ways. No specific mechanism is mandated by this specification. This section gives an overview of some of the options, purely for informational purposes 🧠

7.1. Co-location 💜

When the PA function is co-located with the PUA, the PA knows presence directly. Easy mode 😌

7.2. REGISTER 📇

A UA uses the SIP REGISTER method to tell the SIP network its current communications addresses (i.e., Contact addresses). Multiple UA can independently register Contact addresses for the same address-of-record. This registration state is a big piece of the overall presence picture, since it's an indication of basic reachability for communications 📡

Using REGISTER information to build presence only works if the PA can access the registration database and be told about changes to it. One way to make that happen is to co-locate the PA with the registrar 🏠

How registration state gets turned into presence state is a matter of local policy and beyond the scope of this specification. Some general guidelines can still be given, though 📝 The address-of-record in the registration (the To header field) identifies the presentity. Each registered Contact header field identifies a point of communications for that presentity, which can be modeled using a tuple. The contact address in the tuple doesn't need to be the same as the registered contact address. Using an address-of-record instead lets later communications from a watcher pass through proxies, which is useful for policy processing on behalf of the presentity and the provider 💅

A PUA that uses registrations to manipulate presence state SHOULD make use of the SIP callee capabilities extension [9]. This lets the PUA give the PA richer info about itself. For example, the methods parameter listing the method "MESSAGE" shows support for instant messaging 💬

The q values from the Contact header field [1] can be used to set relative priorities among the various communications addresses in the Contact header fields ⭐

Using registrations to get presence information raises the bar for authenticity and integrity of registrations. Therefore, REGISTER requests used by presence user agents MUST be authenticated 🔐

7.3. Uploading Presence Documents 📤

If there's a way to upload presence documents from the PUA to the PA, the PA can act as an aggregator and redistributor of those documents. The PA would take the presence documents received from each PUA for the same presentity and merge the tuples across all of those PUA into a single presence document. Typically, that aggregation gets done through administrator- or user-defined policies about how it should work 🧁

The specific means by which a presence document gets uploaded to a presence agent are outside the scope of this specification. When a PUA wants direct manipulation of the presence that gets distributed to subscribers, direct uploading of presence documents is RECOMMENDED 🌟

8. Example Message Flow ✨

okay so this message flow is the perfect example of how the presence server can be the one sending notifications for a presentity 🦋 It assumes the watcher was already authorized to subscribe to this resource at the server, so the bouncer already let them in 💅

In this flow, the PUA tells the server about the updated presence info through some non-SIP means 🧚

ngl the Content-Length header with the "..." placeholder just means "put whatever the computed length of the body is here" 🧮

Watcher             Server                 PUA
   | F1 SUBSCRIBE      |                    |
   |------------------>|                    |
   | F2 200 OK         |                    |
   |<------------------|                    |
   | F3 NOTIFY         |                    |
   |<------------------|                    |
   | F4 200 OK         |                    |
   |------------------>|                    |
   |                   |                    |
   |                   |   Update presence  |
   |                   |<------------------ |
   |                   |                    |
   | F5 NOTIFY         |                    |
   |<------------------|                    |
   | F6 200 OK         |                    |
   |------------------>|                    |

Message Details 🎀

F1 SUBSCRIBE watcher->example.com server

SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
To: <sip:resource@example.com>
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml
Contact: <sip:user@watcherhost.example.com>
Expires: 600
Content-Length: 0

F2 200 OK example.com server->watcher

SIP/2.0 200 OK
Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
  ;received=192.0.2.1
To: <sip:resource@example.com>;tag=ffd2
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Expires: 600
Contact: sip:server.example.com
Content-Length: 0

F3 NOTIFY example.com server-> watcher

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
Event: presence
Subscription-State: active;expires=599
Max-Forwards: 70
CSeq: 8775 NOTIFY
Contact: sip:server.example.com
Content-Type: application/pidf+xml
Content-Length: ...

[PIDF Document]

F4 200 OK watcher-> example.com server

SIP/2.0 200 OK
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
  ;received=192.0.2.2
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8775 NOTIFY
Content-Length: 0

F5 NOTIFY example.com server -> watcher

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY
Event: presence
Subscription-State: active;expires=543
Max-Forwards: 70
Contact: sip:server.example.com
Content-Type: application/pidf+xml
Content-Length: ...

[New PIDF Document]

F6 200 OK

SIP/2.0 200 OK
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
 ;received=192.0.2.2
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY
Content-Length: 0

9. Security Considerations 🔐

okay this section is super serious, no cap 😭 There are SO many security things to think about for presence. RFC 2779 [13] lays out a bunch of them, and we already talked about them above. This section goes through them one by one 🫶

9.1. Confidentiality 🤫

confidentiality covers a lot in a presence system:

  • Subscribers may not want to reveal the fact that they have subscribed to certain users
  • Users may not want to reveal that they have accepted subscriptions from certain users
  • Notifications (and fetch results) may contain sensitive data which should not be revealed to anyone but the subscriber

confidentiality comes from a combo of hop-by-hop encryption and end-to-end encryption. The hop-by-hop mechanisms give scalable confidentiality, shut down attacks involving traffic analysis, and hide all aspects of presence messages. However, they run on transitivity of trust, and they cause message content to be revealed to proxies. The end-to-end mechanisms do not require transitivity of trust, and reveal information only to the desired recipient. However, end-to-end encryption cannot hide all information, and it is susceptible to traffic analysis. Strong end-to-end authentication and encryption can be done using public keys, and end-to-end encryption can be done using private keys [14]. Both hop-by-hop and end-to-end mechanisms will likely be needed for complete privacy services 🌸

SIP allows any hop by hop encryption scheme, but TLS is mandatory to implement for servers. Therefore, it is RECOMMENDED that TLS [7] be used between elements to provide this function. The details for usage of TLS for server-to-server and client-to-server security are detailed in Section 26.3.2 of RFC 3261 [1].

SIP encryption with S/MIME is an end-to-end option for both SUBSCRIBE and NOTIFY requests 💖 SIP encryption, using S/MIME, MAY be used end-to-end for the transmission of both SUBSCRIBE and NOTIFY requests.

9.2. Message Integrity and Authenticity 🧾

it's so important that the message recipient can check the contents are actually what the originator sent, and can figure out who the originator really is. This applies to both requests and responses of SUBSCRIBE and NOTIFY. NOTIFY requests are especially important 👀 Without authentication and integrity, presence documents could be forged or modified, tricking the watcher into believing incorrect presence information 💀

RFC 3261 has lots of mechanisms for these features. For the PA to authenticate the watcher, it MAY use HTTP Digest (Section 22 of RFC 3261). So all watchers MUST support HTTP Digest. This is kinda redundant, though, since RFC 3261 already says all SIP user agents have to support it. To provide authenticity and integrity, a watcher MAY use the SIPS scheme when subscribing to the presentity. To support this, all PA MUST support TLS and SIPS as if they were a proxy (see Section 26.3.1 of RFC 3261).

Furthermore, SMIME MAY be used for integrity and authenticity of SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC 3261 🎀

9.3. Outbound Authentication 🚪

when local proxies are used for sending outbound messages, proxy authentication is RECOMMENDED. This is useful to verify who the originator is, and to prevent spoofing and spamming at the originating network 🙅‍♀️

9.4. Replay Prevention 🔁

replay attacks can be used by an attacker to trick a watcher into believing an outdated presence state for a presentity. For example, a document describing a presentity as "offline" can be replayed, tricking watchers into thinking that the user is never online. This may effectively block communications with the presentity 😩

SIP S/MIME can provide message integrity and authentication over SIP request bodies. Watchers and PAs MAY implement S/MIME signatures to prevent these replay attacks. When it is used for that purpose, the presence document carried in the NOTIFY request MUST contain a timestamp. For PIDF, this is done using the timestamp element, as described in Section 6 of [6]. Tuples whose timestamp is older than the timestamp of the most recently received presence document SHOULD be considered stale, and discarded.

Finally, HTTP digest authentication (which MUST be implemented by watchers and PAs) MAY be used to prevent replay attacks, when there is a shared secret between the PA and the watcher. In that case, the watcher can challenge the NOTIFY requests with the auth-int quality of protection 🔐

9.5. Denial of Service Attacks Against Third Parties 🚨

Denial of Service (DOS) attacks are a critical problem for an open, inter-domain, presence protocol. Unfortunately, presence is a good candidate for Distributed DoS (DDOS) attacks because of its amplification properties. A single SUBSCRIBE message could generate a nearly unending stream of notifications, as long as a suitably dynamic source of presence data can be found. So a simple way to launch an attack against a target is to send subscriptions to a large number of users, and in the Contact header field (which is where notifications are sent), put the address of the target. RFC 3265 provides some mechanisms to mitigate these attacks [2]. If a NOTIFY is not acknowledged or was not wanted, the subscription that generated it is removed. This eliminates the amplification properties of providing false Contact addresses.

Authentication and authorization at the PA can also prevent these attacks. Typically, authorization policy will not allow subscriptions from unknown watchers. If the attacks are launched from watchers unknown to the presentity (a common case), the attacks are mitigated 🛡️

9.6. Denial Of Service Attacks Against Servers 🧱

Denial of service attacks can also be launched against a presence agent itself, to disrupt service to a community of users. SIP itself, along with RFC 3265 [2], describes several mechanisms to mitigate these attacks.

A server can prevent SYN-attack style attacks through a four-way handshake using digest authentication [1]. Even if the server does not have a shared secret with the client, it can verify the source IP address of the request using the "anonymous" user mechanism described in Section 22.1 of RFC 3261 [1]. SIP also lets a server tell a client to back off from sending it requests, using the 503 response code (Section 21.5.4 of RFC 3261 [1]). This can be used to fend off floods of SUBSCRIBE requests launched as part of a distributed denial of service attack 🙈

10. IANA Considerations 📋

this spec registers an event package, based on the registration procedures defined in RFC 3265 [2]. Here's the info needed for that registration:

     Package Name: presence

     Package or Template-Package: This is a package.

     Published Document: RFC 3856

     Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.

11. Contributors ✨

okay so these are the people who did the initial technical design work, and they're literally the reason this whole spec exists 🫶

Jonathan Lennox
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003

EMail: lennox@cs.columbia.edu

Robert Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024

EMail: rsparks@dynamicsoft.com

Ben Campbell

EMail: ben@nostrum.com

Dean Willis
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024

EMail: dwillis@dynamicsoft.com

Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003

EMail: schulzrinne@cs.columbia.edu
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399

EMail: huitema@microsoft.com

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399

EMail: bernarda@microsoft.com

David Gurle
Reuters Corporation

EMail: David.Gurle@reuters.com

David Oran
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134

EMail: oran@cisco.com

12. Acknowledgements 🙏

big thank-you energy here 💜 The authors shout out Rick Workman, Adam Roach, Sean Olson, Billy Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, Ya-Ching Tan, Patrik Faltstrom, Allison Mankin and Hisham Khartabil for their comments and support of this specification. literally everyone who helped make it better 🌸

13. Normative References 📚

these are the docs you need to actually read to understand this one, no skipping 💅

[1]  Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, A.,
     Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
     Session Initiation Protocol", RFC 3261, June 2002.

[2]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
     Notification", RFC 3265, June 2002.

[3]  Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
     August 2004.

[4]  Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[5]  Peterson, J., "Address Resolution for Instant Messaging and
     Presence", RFC 3861, August 2004.

[6]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
     J. Peterson, "Presence Information Data Format (PIDF)", RFC
     3863, August 2004.

[7]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
     2246, January 1999.

[8]  Rosenberg, J., "A Watcher Information Event Template-Package for
     the Session Initiation Protocol (SIP)", RFC 3857, August 2004.

[9]  Schulzrinne, H. Rosenberg, J., and P. Kyzivat, "Indicating User
     Agent Capabilities in the Session Initiation Protocol (SIP)",
     RFC 3840, August 2004.

14. Informative References 🧠

these ones are extra context, not required reading, but they're giving so much background 🦋

[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
     Instant Messaging", RFC 2778, February 2000.

[11] Peterson, J., "Enhancements for Authenticated Identity
     Management in the Session Initiation Protocol (SIP)", Work in
     Progress, May 2004.

[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
     "Diameter Base Protocol", RFC 3588, September 2003.

[13] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
     Messaging / Presence Protocol Requirements", RFC 2779, February
     2000.

[14] Gutmann, P., "Password-Based Encryption for CMS", RFC 3211,
     December 2001.

15. Author's Address 🎀

and this is where you can find the main author, Jonathan Rosenberg, at dynamicsoft 💖

Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054

EMail: jdrosen@dynamicsoft.com

okay this part is a little legal-sounding, so I've kept the wording exactly as it was so nothing gets lost 🙈

Copyright (C) The Internet Society (2004).  This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔥

this one's about patents and rights, and yes it's the full text, no cap

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at ietf-
ipr@ietf.org.

Acknowledgement 🌈

and last but definitely not least, the RFC Editor function is funded by the Internet Society, so thank you to them too ✨

📦 where this page comes from