Summary

  • RFC 5264 applies each accepted partial PIDF update to one locally stored full publication. If that publication expires without refresh, the compositor clears the entire full state; it does not remove only the last patch or reconstruct an earlier version.
  • A defensible publication receipt must bind the entity-tag lineage, full/diff body, pre- and post-state hashes, lifetime, refresh or removal event, compositor commit and contribution to composite state.

The timer did not belong to the last patch

A publisher sent a full presence document and received an entity-tag. It later changed one activity, removed one note and adjusted one contact priority through partial publications. Each update was small. Each was conditionally attached to the publication created before it.

Then the refresh did not arrive. The tempting mental model says the most recent delta should expire: undo the priority change, restore the note, perhaps return to the earlier activity. RFC 5264 specifies a different result. The compositor clears the entire full-state publication.

Nothing in that result is accidental. The delta was a transport-efficient instruction for changing a publication. It was not a separately leased fact with its own independent lifetime. Once accepted, its effect lived inside the current full document.

Partial describes the message, not the ownership unit

RFC 3903 defines PUBLISH-created event state as soft state. It has a negotiated lifetime and must be refreshed if it is to remain. RFC 5264 adds a way to modify that state without retransmitting every unchanged XML element.

The first publication under the partial-presence content type still contains full state in pidf-full. Later modifying requests may carry pidf-diff operations or another full document. The compositor applies the operations in sequence and sends the resulting full document into the same composition logic used for ordinary full-state publication.

This changes network cost, not the unit of authority. The publication remains the object identified, refreshed, modified, removed and expired. A patch is one input to its transition.

One conditional lineage orders the changes

SIP event publication identifies state with the Request-URI, event package and, for an existing publication, an entity-tag. A successful PUBLISH produces a new SIP-ETag. The next refresh, modification or removal names the state it expects through SIP-If-Match.

RFC 5264 deliberately relies on that mechanism for ordering. Partial PIDF has a version attribute, but using both that number and the entity-tag as competing clocks would create an undefined case when they disagree. The specification therefore avoids the second version system.

The consequence for evidence is precise. A stored delta without its request identity, prior entity-tag and returned entity-tag is not a complete transition record. It cannot show which publication the compositor was asked to change or which accepted state followed it.

The compositor stores the result, not a reversible patch stack

For every resource, the compositor maintains records for individual publications and indexes them through entity-tags. On a valid partial modification, it applies the ordered patch operations to the locally stored document. The output becomes the current full publication.

RFC 5264 expressly says the compositor does not keep a record of the applied patches for rollback. There is no protocol promise of a journal from which an earlier document can be reconstructed. The way back is a new full-state publication.

That is the real difference between a patching mechanism and a version-control system. Both can describe change. Only one promises retained historical states and reversible ancestry. Partial presence promises the former, not the latter.

Expiration clears the publication that the patches produced

The specification ties changes in expiration to the full, patched publication. When a publication carrying partial presence expires without refresh, the compositor must clear that entire publication.

This can produce a large semantic change from a small missed operation. A refresh message contains no new body, yet its absence can remove the publisher's complete contribution. Conversely, a tiny delta can survive for as long as the publication is refreshed because its effect has already been incorporated into the current full document.

The operational question is therefore not “How long does this patch live?” It is “Which publication lifetime now governs the full result, and what evidence shows that the refresh was accepted before expiry?”

The blast radius is one publication, not necessarily the resource

Precision matters in the other direction too. RFC 3903 allows several endpoints to publish their own state for the same resource. A compositor may combine those active publications, and it may also use separately provisioned hard state that does not expire.

Clearing one expired publication does not, by itself, mean erasing every other publisher's contribution or all composite resource state. The visible result depends on what else remains and on composition policy, which is outside the protocol's definition.

A trustworthy incident record must name the publication that disappeared, the other contributions that remained, the composite output before and after, and the policy version that combined them. “Presence disappeared” is too broad; “publication X expired and was removed” is auditable.

Failure paths preserve an older state only before acceptance

RFC 5264 gives processing failures an atomic shape. A partial body without a valid modifying context is rejected. A document-processing error produces a 400-class failure and may include RFC 5261 diagnostics. Other failures before the complete publication has been processed require a 500 response and restoration of the original locally stored publication.

That rollback is different from expiry. Before acceptance, the compositor can reject the attempted transition and retain the prior state. After accepted changes have become the current publication, later expiry clears that publication; it does not replay the earlier snapshots.

This boundary should appear in logs. A 400 or 500 proves a rejected attempt. A 2xx with a new entity-tag proves an accepted conditional transition. Neither alone proves what a downstream watcher later received or what a person acted upon.

A publication-state receipt

For consequential use, retain:

  • Request-URI, event package, publisher, presentity and publication identity;
  • previous and returned entity-tags, plus the exact SIP-If-Match value;
  • full or partial content type, raw body, hash and receive time;
  • ordered add, replace and remove results with any diagnostics;
  • locally stored full-document hash before and after processing;
  • requested, granted and effective expiration values;
  • refresh deadline, refresh request, response code and commit time;
  • explicit removal or natural-expiration event and the state it cleared;
  • other active publications and non-expiring hard-state contributions;
  • composite output hash, policy version and downstream notification identity; and
  • any later display, automated decision or human outcome.

The purpose is not to turn a lightweight presence protocol into a universal ledger. It is to stop a small conditional message from being mistaken for an independently durable object—and to stop its disappearance from being explained as the reversal of one patch when the protocol removed a whole publication.

Sources