Summary

  • RFC 3343 promised that the presence service would send no further updates after processing terminate and its reply, while warning that earlier presence or watcher updates might still arrive because they were already in transit.
  • A code 250 cancellation reply therefore proved a service-side cutoff, not queue drainage; transaction correlation, message age, current subscription generation and consumer disposition remained separate evidence.

Cancellation is often imagined as a line across time: everything before it belongs to the operation, everything after it cannot. RFC 3343 drew a more physical boundary. The service could stop generating and sending new work after processing a terminate request, yet the relay mesh could still contain work emitted beforehand. The receipt marked what the source would do next, not what every downstream conduit had already finished doing.

That distinction turns a familiar race into an evidence problem. A consumer that receives a late update must not call the cancellation false. Nor may it assume the update represents the current subscription. Both records can be authentic while referring to different moments in the delivery chain.

A service built from three kinds of continuing operation

The APEX presence service lived at the well-known endpoint apex=presence inside an administrative domain. Applications could publish presence entries, subscribe to a publisher's presence, or watch the list of endpoints subscribing to that publisher.

A subscription immediately returned the current presence entry. With a non-zero duration it then produced new publish operations whenever the entry changed and eventually ended with a terminate. A zero-duration subscription acted as a one-time poll. A watch first received code 250, then one notify for each current subscriber, and later notifications when subscriptions began or ended.

These were long-lived operations rather than isolated request-response pairs. The presence service had to persist both presence entries and in-progress operations. Service-originated publish and notify messages carried the transaction identifier of the subscription or watch that caused them. That identifier made the lineage visible, but did not make every later arrival current.

What terminate actually promised

Either the consumer or service could end a subscribe or watch operation. A consumer sent terminate with the transaction identifier. If it did not refer to an in-progress operation for that originator, the service returned error 550. Otherwise it removed the operation and replied with code 250.

The specification then states the awkward part directly. Following termination, the originator may receive further presence or watcher updates. The service sends no further updates after it processes the terminate and sends the reply, but earlier updates may be in transit.

The reply therefore carries a scoped fact: the active operation has ended at the service, and the service's future send behavior has changed. It does not say that every relay buffer, connection, scheduler or consumer input queue is empty. It does not retract a publish or notify already handed to the mesh.

Modern systems sometimes call the stronger property a drain barrier. A drain barrier requires evidence that all work before a boundary has either arrived, been discarded under a defined rule, or been accounted for. RFC 3343's terminate receipt was not such a barrier. The document preserved the gap instead of hiding it.

Correlation survives validity

The late update still carried the old transaction identifier. That allowed the receiving application to say which ended operation had caused it. Correlation is valuable, but it is not a command to apply the content.

The consumer needs another state: an operation generation or tombstone that records the termination boundary and late-message policy. It might discard the update, retain it for audit, compare its presence timestamp with a newer snapshot, or quarantine it until reconciliation. What it must not do is treat a matching identifier as proof that the subscription is currently active.

The same separation appears when a new subscription replaces an earlier one for the same originator and subject. RFC 3343 silently terminated the prior operation before continuing. A reused logical relationship did not erase the older generation's in-transit messages. Without a generation-aware ledger, an update from the old operation can be mistaken for the first update of the new one.

Presence was not attachment

Every administrative domain maintained a presence entry for each endpoint regardless of whether that endpoint was attached to the relay mesh. Each entry had a publisher, lastUpdate, publisher information and one or more tuples. A tuple identified a destination URI, an availableUntil time, optional information and capabilities.

The existence of the entry therefore did not prove a live attachment. An availableUntil claim described the latest time an entity was capable of receiving messages within the data model; it was not an observed delivery result. An update arriving late after termination could still be a faithful copy of a stored entry while being operationally stale for the consumer's current decision.

Publishing used its own concurrency boundary. The supplied presence lastUpdate had to match the stored value semantically or the service returned code 555. On success the service updated the entry, set a new service time and replied 250. That protected a mutation at the service. It did not prove when every subscriber received the change.

Privacy and historical scope

RFC 3343 was published in April 2003 as Experimental. It is now Historic. The RFC Editor record lists its current state, and its errata search supplies the current correction record. The IETF history dated 29 July 2012 says that, to the best of the IETF's knowledge, no implementations of RFCs 3340 through 3343 had been deployed and that APEX functionality was provided by widely deployed XMPP under RFCs 6120 and 6121.

That qualified record does not say the termination race caused non-adoption. It supplies no implementation, queue measurement or incident. The RFC's security section separately noted that timestamps could reveal location through their offsets, permitting conversion followed by -00:00 when the location information was sensitive. Even a valid presence record had disclosure consequences outside its delivery mechanics.

The useful inheritance is narrower. Keep separate receipts for update creation, handoff to transport, termination processing, source-side cutoff, relay drainage, consumer arrival and consumer action. If only the first four exist, do not invent the fifth. A cancellation can be real while its past is still approaching.

Sources