A Presence Event Package for the Session Initiation Protocol (SIP)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (26)
Forked SUBSCRIBE requests are constrained to produce only a single dialog so that only one PA generates notifications per subscription. Supporting heterogeneous PAs each handling a subset of presence data would require the subscriber to act as aggregator, which can only reasonably be performed by agents representing the presentity.
SIP is chosen as a presence protocol because SIP location services already contain presence information in the form of registrations, and SIP networks can route SUBSCRIBE requests to the server holding registration state. This allows SIP infrastructure to be reused for global presence subscription connectivity without additional routing infrastructure.
Usage of pres URIs in SUBSCRIBE From/To fields instead of SIP URIs is a SHOULD (not MUST) to support interoperability with CPP-compliant systems via gateways. The pres URI provides a protocol-independent identity form; the exception allows cases where pres URI would cause interoperability problems with SIP components that do not support it.
This presence event package is compliant with the Common Presence Profile (CPP) framework (RFC 3859), enabling SIP-based presence to interwork with other CPP-compliant presence systems through gateways. Protocol-independent pres URIs are used to facilitate this interoperability.
A PA MUST NOT accept a subscription unless authorization has been provided by the presentity. Authorization may come from access lists, uploaded ACL documents, backend AAA servers, or real-time user queries.
A PA SHOULD NOT generate notifications for a single presentity at a rate of more than once every five seconds.
A presence agent MUST authenticate all subscription requests using any mechanisms defined in RFC 3261; digest authentication is mandatory to implement per RFC 3261.
All PUAs acting as PAs SHOULD be capable of acting as a PA for the state they manipulate, and SHOULD authorize subscriptions that can be authenticated as coming from the domain of the presentity.
All state agents (presence servers) SHOULD support the watcherinfo event template-package (RFC 3857), which provides a means to alert the presentity that an authorization decision is required.
All subscribers and notifiers MUST support the "application/pidf+xml" presence data format. If no Accept header field is present in the SUBSCRIBE, the default value is "application/pidf+xml"; if present, it MUST include "application/pidf+xml".
If final authorization for a pending subscription results in success, a NOTIFY SHOULD be sent containing a presence document with the current state of the presentity.
REGISTER requests used by presence user agents MUST be authenticated, because using registrations to obtain presence information increases the requirements for authenticity and integrity of registrations.
The body of the NOTIFY MUST be sent using one of the types listed in the Accept header field of the most recent SUBSCRIBE request, or using "application/pidf+xml" if no Accept header field was present.
This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request, ensuring that only a single PA generates notifications for a particular subscription to a particular presentity. If aggregation is needed, it MUST be done in a PA representing the presentity.
When a PUA wishes to have direct manipulation of the presence distributed to subscribers, direct uploading of presence documents is RECOMMENDED rather than manipulating registrations to achieve the desired result.
Authorization decisions map to three states: successful (client is authorized to receive some presence state), rejected (client will never receive any presence state), and pending (authorization not yet determined). Response codes 200, 403/603, and 202 correspond to these states respectively.
Default subscription duration for the presence event package is 3600 seconds (one hour), reflecting the human-driven frequency of presence state changes (on the order of seconds to hours). Subscribers MAY specify an alternate expiration in the Expires header field.
PA migration allows the PA function to move from one server to another, e.g., from a presence server to a PUA when it connects. A PUA wishing to indicate PA support SHOULD use callee capabilities (RFC 3840) to indicate support for SUBSCRIBE and the presence event package. After a failed migration (405 or 489 response), the server SHOULD NOT attempt further migrations to that PUA for the duration of its registration.
Polite blocking allows a PA to return 200 OK to a subscription even when it has been rejected or marked pending. The NOTIFY presence document SHOULD be constructed to not reveal to the subscriber that their request has been blocked, typically by indicating "offline" status.
The presence event package name is "presence", which appears in the Event header field of SUBSCRIBE and NOTIFY requests. This package is defined within the general SIP event notification framework (RFC 3265).
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 from the NOTIFY with the next highest CSeq is used.
This specification registers the "presence" event package with IANA under the procedures defined in RFC 3265. The package name is "presence", published in RFC 3856, contact Jonathan Rosenberg.
All watchers MUST support HTTP Digest authentication. All PAs MUST support TLS and SIPS. S/MIME MAY be used for end-to-end integrity and authenticity of SUBSCRIBE and NOTIFY requests to prevent forgery or modification of presence documents.
Confidentiality requires both hop-by-hop encryption (TLS is RECOMMENDED between elements) and end-to-end encryption (S/MIME MAY be used). TLS provides scalable confidentiality and traffic analysis protection but requires transitivity of trust; S/MIME provides end-to-end protection without transitivity of trust but cannot hide all metadata.
Presence is susceptible to amplified DoS attacks: a single SUBSCRIBE to a dynamic source could generate an unending notification stream directed at a target via a forged Contact address. RFC 3265 mitigates this by removing subscriptions for unacknowledged or unwanted NOTIFYs. Authorization policy further mitigates by rejecting subscriptions from unknown watchers.
Replay attacks can fool watchers into believing outdated presence state. To prevent this, when S/MIME signatures are used, the presence document in NOTIFY MUST contain a timestamp. Tuples whose timestamp is older than the most recently received presence document SHOULD be considered stale and discarded.