Summary

  • RFC 3340 separated transaction identifiers tied to a live BEEP channel from identifiers embedded in APEX service data, which could remain meaningful after the requesting application detached.
  • A second application could attach as the same endpoint and receive the first application’s reply; the endpoint name and transaction identifier correlated records but did not prove request ownership, continuing intent or authority to act.

The uncomfortable sentence appears in Section 6.1.1 of RFC 3340, not in a retrospective critique. An application may attach as an APEX endpoint, send data to a service with an embedded transaction identifier, and later detach. A second application may attach as that same endpoint and send requests of its own. It may then receive data from the service responding to the first application’s request, with the first application’s identifier inside it.

That small scenario contains a complete succession problem. The endpoint persists as a routable name. The BEEP connection does not. The first process is gone. The service still has work or a response in flight. A replacement process acquires the endpoint and becomes reachable. When the answer arrives, it is correctly correlated with an earlier request and correctly delivered to the current attachment, yet neither fact establishes that the current process owns the old request.

Two kinds of lifetime

APEX ran over BEEP, the Blocks Extensible Exchange Protocol. RFC 3340 distinguishes two scopes. In endpoint-relay and relay-relay exchanges, a transaction identifier is meaningful only for the lifetime of the BEEP channel. An attach operation illustrates the rule: release the BEEP connection and the channel ceases to exist; the application is no longer attached to the relay mesh.

Service traffic was different. Its identifier could be embedded inside the data carried through the mesh. The identifier was therefore “potentially long-lived.” It could cross the very boundary that ended the channel-scoped association. The RFC recommends values that appear unpredictable to reduce ambiguity. That is a sensible correlation safeguard. It is not an identity system. A hard-to-guess value does not say which process generated it, which attachment generation retains authority, whether the original request was cancelled, or whether the successor should apply the answer.

The distinction matters because endpoint names are often treated as if they named a continuously existing actor. RFC 3340’s endpoint instead named a place at which an application could be attached. The name could remain stable while the actor behind it changed. A reply addressed to the place could therefore be routed correctly and still reach the wrong generation of actor for an irreversible decision.

The early ok

The data path adds another bounded receipt. Under Section 4.4.4.1, a relay first checks whether its BEEP client is authorized to send on behalf of the stated originator and processes any per-data options. It then returns ok. Only afterward does it process per-originator options and each recipient.

For a recipient in another administrative domain, successful processing means that a session was established to a relay for that domain, the new data was sent, and that next relay returned ok. For a local recipient, the access service must permit the communication, the endpoint must be attached, and the application must return ok after application-specific processing. These are deliberately different checkpoints. The first relay’s acceptance is not the service’s eventual answer, and even the recipient application’s protocol acknowledgement is not evidence that a business action succeeded.

APEX offered more evidence without pretending it was the same evidence. A statusRequest option caused each applicable relay to send a later statusResponse through the report service. With targetHop set to all, an originator could trace passage through the mesh. The trace was a chain of observations, not an expansion of the initial ok. It also carried a cost: related timing options could expose private topology, and RFC 3342 advised that administrators might disable them except at administrative ingress and egress.

Identity stopped at the boundary it proved

The architecture used DNS SRV to locate relays. RFC 3340 therefore said relaying integrity depended on DNS and on applications using DNS, with additional assurance when the BEEP initiator required the listener to authenticate itself. BEEP peer authentication could support authorization to attach or relay as an endpoint. End-to-end content authentication, where desired, belonged to signing the content itself rather than trusting hop-by-hop protection.

Those controls answer important but limited questions: which listener was reached, which peer authenticated, whether that peer could originate for an endpoint, and whether the content was altered. They do not collapse an endpoint into a process. They do not bind an embedded transaction identifier to one workload generation. A signed old reply may be excellent proof of what the service sent and still be unsafe for a newly attached process to execute without a durable ownership record.

The minimum useful ledger therefore has more than an endpoint and a transaction identifier. It needs the authenticated peer, channel and attachment generation; the process or workload identity; a hash of the request; the service destination and durable receipt; relay acknowledgements and status reports; the detach event; the successor’s attach event; a hash of the reply; and the policy decision to consume, quarantine or discard it. Idempotency state and the observed application outcome belong after that decision, not inside the identifier.

A design became history

RFC 3340 appeared on the Standards Track in July 2002. It was one of four APEX documents: the core, access service, option collection and presence service in RFCs 3340 through 3343. Ten years later, the IETF’s Datatracker recorded why all four were moved to Historic status. To the best of the IETF’s knowledge, no implementations had been deployed; their functionality was being provided by XMPP, represented by RFCs 6120 and 6121, which had been widely deployed.

That record must be read precisely. It supports a non-deployment statement qualified by the IETF’s knowledge and a comparison with XMPP’s deployment. It does not prove that the long-lived-identifier mechanism caused APEX’s fate. Nor does Historic status make the lifecycle example obsolete. If anything, the example survives because it names a problem shared by job queues, callbacks, orchestration systems and service identities: a stable address can conceal replacement.

The right conclusion is not that late replies are invalid. It is that their validity has several dimensions. The bytes may come from the expected service. The identifier may match an old request. The endpoint may be correct. The receiving process may nevertheless lack ownership or current authority. A safe consumer must join those receipts instead of allowing a convenient correlation key to impersonate all of them.

Sources