Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (26)
Full presence documents are sent for every change even when only a single element changes. Over low-bandwidth, high-latency links this degrades the presence service, motivating a partial notification mechanism that delivers only what has changed.
The version counter is not reset on subscription refresh (only on termination) so that the PA and watcher stay synchronized even across SUBSCRIBE refreshes. If the PA reverts to pidf-diff+xml after using another content type, the counter continues incrementing from the last value rather than restarting, avoiding false-loss detection.
Watcher processing errors in received pidf-diff+xml documents should trigger subscription renewal rather than signaling the error to the notifier, because the error is likely in the notifier's process and signaling it back is not useful.
Watchers that encounter processing errors on 'application/pidf-diff+xml' bodies MAY fall back to normal presence operations by omitting 'application/pidf-diff+xml' from the Accept header in a new SUBSCRIBE request, reverting to full PIDF notifications.
A watcher that wants to allow the presence agent to send partial notifications MUST include an Accept header field in its SUBSCRIBE request containing 'application/pidf-diff+xml' in addition to 'application/pidf+xml'. The watcher MAY include a 'q' parameter to indicate relative preference.
Entities supporting the partial notification extension MUST support the 'application/pidf-diff+xml' content type specified in the PIDF extension for partial presence (RFC 5262).
If the PA changes content type mid-subscription, the watcher MUST discard all previously received presence information except the local version counter; the version counter MUST NOT be discarded so that it continues correctly if the PA reverts to 'application/pidf-diff+xml'.
If the PA switches from another content type to 'application/pidf-diff+xml' mid-subscription, it MUST deliver the full presence state with a <pidf-full> root element as the first partial notification after the switch.
If the received version is higher by more than one compared to the locally stored value, the watcher assumes one or more NOTIFYs were lost and SHOULD either refresh the subscription to receive a full presence document or terminate the subscription.
If the root element is <pidf-diff> and the received version is exactly one greater than the local counter, the watcher MUST apply the diff changes to its local copy and increment the local version counter by one.
On receiving the first 'application/pidf-diff+xml' NOTIFY, the watcher MUST initialize an internal version counter to the received 'version' value and store the full presence document as its local copy.
On subsequent 'application/pidf-diff+xml' NOTIFYs, the watcher MUST compare the received 'version' with the local counter. If the received version is equal to or lower than the local value, the watcher SHOULD discard the document without further processing (treating it as a PA failure).
Once a subscription is accepted, the PA MUST deliver the full state of presence information in the first partial notification, using a document with the <pidf-full> root element, and MUST set Content-Type to 'application/pidf-diff+xml'.
The PA MUST construct partial presence documents so that added information appears inside <add> elements, removed information inside <remove> elements, and changed information inside <replace> elements, per the PIDF extension for Partial Presence.
The PA MUST NOT send a new NOTIFY containing a partial notification for the same Request-URI until it has received a final response from the watcher for the previous NOTIFY or the previous NOTIFY has timed out.
The presence agent SHOULD base content-type selection on the watcher's 'q' parameter preferences unless local policy dictates otherwise.
When the PA receives a SUBSCRIBE request (refresh or termination) within an associated subscription, it SHOULD send a NOTIFY containing the full presence document.
When using 'application/pidf-diff+xml', the PA MUST include a 'version' attribute initialized to 1 for the first partial notification within a given subscription, and MUST increment it by one with each subsequent partial notification. The version is scoped to the subscription and is only reset when the subscription is terminated, not when refreshed.
Partial presence documents use three change-indication elements from RFC 5262: <add> for newly added presence information, <remove> for deleted information, and <replace> for modified information, each with XPath-based 'sel' attributes to identify the target node.
The Accept header in the watcher's SUBSCRIBE request is used to negotiate content type. Including 'application/pidf-diff+xml' (alongside 'application/pidf+xml') signals willingness to receive partial notifications; the optional 'q' parameter expresses relative preference.
The MIME type 'application/pidf-diff+xml' is used for partial presence notifications. Documents using this type carry either a <pidf-full> root element (full state) or a <pidf-diff> root element (incremental changes), along with a mandatory 'version' attribute.
The version counter is subscription-scoped: initialized to 1 on first use, incremented by one per partial notification, and reset only on subscription termination (not on refresh). It allows watchers to detect missing notifications.
A third party could inject a NOTIFY with partial state to cause the watcher to believe a notification was missed and request a full document (causing unnecessary load). This attack is no worse than injecting a NOTIFY with Subscription-State: terminated, which existing SIP security mechanisms already address.
Partial notifications can reveal information about which aspects of a presentity's presence are changing, making it easier for an eavesdropper to infer behavior patterns. However, this is no worse than baseline PIDF, where the same information is visible in full documents.
TLS is RECOMMENDED between elements for hop-by-hop confidentiality. S/MIME MAY be used for integrity and authenticity of SUBSCRIBE and NOTIFY requests, as described in RFC 3261 Section 23.
Watcher local state: (1) No subscription — watcher sends SUBSCRIBE with Accept including pidf-diff+xml. (2) Awaiting first NOTIFY — initializes version counter and local copy on receipt of <pidf-full>. (3) Active delta tracking — applies <pidf-diff> patches when version increments by exactly one; triggers re-subscribe on version gap > 1; discards document on version <= local. (4) Terminated — version counter reset.