Summary

  • RFC 5263 requires a Presence Agent to wait for the prior partial NOTIFY’s final response or timeout before sending another one for the same Request-URI; this serializes transactions but does not create a durable receipt for watcher state.
  • A defensible handoff binds the subscription and version to the NOTIFY body, SIP response, parser and patch result, pre- and post-state hashes, storage acknowledgement, downstream exposure and any later human or service outcome.

The green response arrived before the state did

The Presence Agent sent a partial notification. The watcher’s automated SIP layer found the request acceptable and returned a final success response. The send window opened, and the next change became eligible to leave the server.

Behind that response, the local state pipeline had not finished. The XML body still had to be parsed, its subscription-scoped version compared, its patch applied to the correct full document and the result made durable. A failure in any of those steps could force a refresh or fallback without a useful error travelling back to the notifier.

Nothing here makes the response false. It makes the claim narrower. The response is evidence about a SIP transaction boundary. Treating it as evidence of a committed watcher state is an institutional promotion that the protocol does not supply.

The response is the gate for the next send

RFC 5263 says a Presence Agent must not send a new partial NOTIFY for the same Request-URI until it has received a final response for the previous request or that request has timed out. This rule prevents an uncontrolled stack of dependent deltas from being in flight at once.

The generic SIP event framework gives the other half of the exchange. Once a NOTIFY is deemed acceptable, the subscriber should return 200. The transaction must not last longer than automated processing requires, and the subscriber must not wait for a user response before sending the final answer.

That is a deliberate control boundary. It limits transaction occupancy and lets the notifier decide whether to advance, retry or remove a failed subscription. It cannot simultaneously serve as proof that a person saw the change or that every downstream component committed it.

One subscription owns the partial-state sequence

To permit the mechanism, a watcher advertises both application/pidf-diff+xml and the default application/pidf+xml in SUBSCRIBE. The Presence Agent may choose the partial format, considering preferences unless local policy says otherwise.

The first partial-format notification containing presence data carries a full document. Its version starts at one for that subscription. Later full or partial notifications advance the same counter. Refreshing does not reset it; terminating the subscription does.

This matters for the receipt. A version value without the subscription and dialog identity is not a global coordinate. A success response without the body hash and version is not evidence of which state transition the watcher was asked to make.

“Successfully sent” remains upstream language

The Presence Agent increments relative to the earlier successfully sent partial-presence document for that watcher and subscription. It also waits for the earlier transaction’s final response or timeout before sending the next.

Those facts support a sender-side history: request emitted, transaction answered or expired, next version released. They do not reveal whether the receiver’s local full copy changed, whether the result survived a process crash, or whether the view used by another component ever observed the new hash.

Leadership systems often collapse these stages because they occur close together in healthy operation. The collapse is harmless until the evidence is needed during a dispute, incident or automated decision. Then “the request succeeded” and “the state changed” become materially different propositions.

The watcher has failure paths the notifier may never see

When a diff is exactly one version higher, the watcher applies it to the local full copy and advances its counter. When the received value is equal to or lower than the local value, the document is treated as a Presence Agent failure and should be discarded. When the value jumps by more than one, the watcher assumes that notifications were lost and should refresh for full state or terminate.

There is another branch: the body can fail during processing. RFC 5263 says the watcher should renew the subscription and may fall back to ordinary full presence by omitting the partial MIME type in a new SUBSCRIBE. It then makes a striking operational observation: signalling that processing error to the notifier is hardly reasonable, even when the error exists in the notifier process.

That sentence prevents a false inference. An upstream transaction history can look orderly while the receiver quietly abandons the partial-state path and asks for a new baseline.

Content-type changes preserve one coordinate and discard another

If the Presence Agent changes the content type within an existing subscription, the watcher discards previously received presence information for that presentity, except its local version counter. The counter remains because a later return to partial format continues the sequence.

This produces a governance trap. The surviving counter looks like continuity, while the stored representation beneath it has been replaced. A receipt that preserves only the latest version number cannot explain which full state existed before the switch, what was discarded, or which document became authoritative afterward.

A full document sent on refresh is a useful resynchronization point. It does not retroactively prove that earlier deltas were applied or that a discarded local copy was ever exposed.

Authentic delivery is not durable application

RFC 5263 inherits the presence framework’s confidentiality, integrity, authenticity, replay and denial-of-service concerns. It recommends hop-by-hop TLS in its original context and allows S/MIME protection for SUBSCRIBE and NOTIFY. RFC 8996 later updates the TLS dependency by deprecating TLS 1.0 and 1.1.

These protections matter. An injected partial notification can manufacture the appearance of a gap and provoke a full-state request. But a message can be authentic and still fail parsing, target an unavailable local store, lose a race with a content-type change or remain invisible to the business surface.

Cryptographic and transport evidence should stay in the chain. Neither should borrow the missing authority of an application commit.

The watcher-state receipt

For consequential uses, retain:

  • presentity, watcher, Request-URI, subscription, dialog and event-package identity;
  • negotiated content types, preferences and the Presence Agent’s local selection;
  • NOTIFY Call-ID, tags, CSeq, body bytes, content type, hash and received time;
  • subscription-scoped presence version and expected prior version;
  • final SIP response code, response time, timeout or retry result;
  • parser result and precise processing error;
  • pre-state full-document hash and patch operation result;
  • post-state reconstructed-document hash and local counter;
  • durable storage acknowledgement and process generation;
  • any refresh, fallback, content-type switch or replacement full-state hash;
  • downstream exposure identity, hash and observation time; and
  • later user-interface display, contact attempt, delivery and human or service outcome.

This does not make a 200 response less useful. It prevents an efficient flow-control signal from becoming a fictional end-to-end receipt.

Sources