Summary

  • In RFC 3342, expiry of reportAfter generated a transient timing report but explicitly did not affect delivery; the relay forwarded the original data regardless.
  • noLaterThan was the separate hard delivery budget, while returnTrip bounded the final-hop report itself, so warning, enforcement, report receipt and application outcome remained distinct evidence states.

The seductive interpretation of a delay alarm is that something has failed. RFC 3342 refused that shortcut. Its dataTiming option carried several millisecond values, but they did not answer the same question. One value asked when the originator should be told that delivery was taking longer than expected. Another set the upper bound after which forwarding should cease. A third limited how long the final report had to make its own way home.

That architecture matters because control systems often turn monitoring events into state. A dashboard receives an alert and labels a job failed. A retry controller starts another copy. An operator cancels downstream work. Yet in the RFC's delayed-delivery branch, the original data remains alive after the alert. If the surrounding system promotes the report beyond its defined meaning, it may create duplication or contradictory action from perfectly conforming protocol behavior.

The soft threshold spent itself, not the payload

APEX began as an immediate, best-effort application-layer datagram service. Without options, an unavailable relay could lead to a silent drop. RFC 3342 added controlled queuing and reporting. For dataTiming, every relay processed the timing option, so the originator had to mark it for all hops and require understanding.

Immediately before a relay sent data onward, it reduced reportAfter by the time spent locally finding the next relay, binding and preparing to send. If the remaining value reached zero or below, the relay set it to zero and invoked the report service. Then the specification says the data element is sent to the next relay regardless. At the endpoint hop, failure to receive the endpoint's ok within that reporting interval likewise produced a transient report.

The report identified the original transaction and recipient with reply code 350, a transient-success indicator. It did not say the payload had been discarded. It did not turn a late delivery into a permanent failure. It recorded that the reporting threshold had been crossed. After the value became zero, later hops could carry that exhausted observation state without pretending that the message itself had expired.

This is a useful evidence design. The alarm is not false merely because delivery later succeeds. The later success does not make the alarm false either. One statement concerns elapsed processing beyond a threshold; the other concerns whether the message ultimately crossed the required protocol boundary.

A hard budget used a different verb

noLaterThan supplied the upper bound. Each relay reduced it by local processing time immediately before forwarding. If the budget became zero or negative, processing had failed and the relay did not send the data to the next relay. When reportErrors was true, it also invoked the report service to send a timing-error report.

At the final endpoint, the remaining budget governed how long the relay waited for an ok. A timeout there was also a timing error. The contrast with reportAfter is exact: one threshold caused a report and continued forwarding; the other could terminate forwarding. Combining their events into a single red status would erase the policy difference the protocol took care to encode.

Even the hard deadline had a bounded claim. It proved that this timed forwarding attempt exceeded the budget at a stated processing point. It did not prove why. A slow or unavailable next relay, local processing, an unattached endpoint, congestion or another condition could consume the interval. Nor did a timely endpoint ok prove a human or business outcome beyond the application-layer processing acknowledged at that point.

The receipt travelled under its own deadline

When data was successfully transmitted to the recipient and returnTrip was non-zero, the relay invoked the report service for a final-hop report. That report was not an omniscient flag written directly into the sender's database. It was another APEX data operation. Its new dataTiming.noLaterThan equalled the original returnTrip value.

The result is a second delivery problem nested inside the first. The payload may reach the recipient, a final report may be generated, and the report may still fail to return within its own budget. After that, the sender may presume the report lost. Absence of the receipt is not retroactive proof that the payload failed. Presence of the receipt proves the final-hop protocol event, not every later consequence.

A durable ledger therefore needs separate fields for original relay acceptance, remaining soft threshold, transient-report generation, original forwarding after the report, remaining hard deadline, forwarding stop or endpoint acknowledgement, final-report generation, return budget, report receipt and observed application result. A single status column cannot preserve this sequence without lying by compression.

Queues and hops added adjacent limits

The hold4Endpoint option allowed a relay to queue data while the recipient endpoint was unattached. Without a delivery upper bound, that queue could last indefinitely. RFC 3342 warned that the mechanism could facilitate denial of service and suggested administrative limits, including requiring a short-lived noLaterThan. Queue existence was not a promise of eventual delivery; it was stored exposure governed by another control.

The separate dataHopping option reintroduced a TTL-like hop count for detecting relay loops. It reduced noMoreThan before the next relay and stopped forwarding when the value expired. That counter bounded topology traversal, not elapsed time. A message might remain within its hop allowance while exhausting its time budget, or consume hops quickly while remaining timely. Treating the two limits as interchangeable would again merge different evidence.

attachOverride created another adjacent state change by letting a new attachment terminate the previous application for the same endpoint. RFC 3340 already supplies the crucial ownership warning: data expected by the former application could reach the later one. That lifecycle belongs to separate coverage. Here it matters only to show why a timing report cannot identify the continuing application's right to act.

Historic status did not turn thresholds into outcomes

RFC 3342 was published in July 2002 as a Standards Track document. The RFC Editor currently marks it Historic and lists no matching errata. The IETF history entry 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 being provided by widely deployed XMPP under RFCs 6120 and 6121.

That record is qualified and narrow. It does not say this timing design caused the lack of deployment. It supplies no production measurement, incident or implementation verdict. The useful inheritance is conceptual: observation, intervention and proof of intervention should never share a label merely because they share a timer.

RFC 3342 also warned that timing reports could expose private network topology, so administrators might enable them only at administrative-domain ingress and egress. More observability was not automatically more authority. The report could improve diagnosis while revealing structure, and its scope remained a deployment choice.

The modern lesson is not that every delayed task needs three APEX fields. It is that a system must say which timer only observes, which timer changes behavior, and which timer governs the evidence returning from that change. When an alert fires, ask whether work stopped. When work stops, ask what the stop proves. When a receipt arrives, ask which boundary issued it. That is how a warning stays useful without becoming a fictional outcome.

Sources