Summary

  • RFC 9622 says Sent means message-derived data has passed down or through the underlying protocol stack and is no longer the Transport Services API’s responsibility.
  • The RFC expressly leaves the data’s exact disposition implementation-specific. A Sent event is not a portable claim that a packet was emitted, that a peer received it or that an application completed work.

Software often turns a lifecycle label into a business fact. A telemetry screen says “sent”; an audit trail closes the action; a caller treats the returned event as the end of the story. That shortcut is attractive because local software can record it cheaply. It is also where a transport boundary begins to impersonate a result.

RFC 9622, the January 2025 Standards Track Transport Services API written by Brian Trammell, Michael Welzl, Rolf Engelhardt, Gorry Fairhurst, Mirja Kühlewind, Colin Perkins, Paweł Tiesel and Tommy Pauly, provides an exact counterexample. Its Sent event occurs when data from a message has passed down or through the underlying protocol stack and has ceased to be the API’s responsibility. The document immediately refuses to universalize the next fact: at that moment the data might have been transmitted, placed in a network-interface buffer, placed in a kernel buffer, or occupy another implementation-defined position.

That wording is not a defect to be repaired by optimistic reporting. The API sits between an application and a local Transport Services System. It gives an application an asynchronous way to state requirements and receive local events. It is not a protocol acknowledgment from a remote endpoint. RFC 9621 makes the same allocation visible in its design: selection properties may be requirements, prohibitions or preferences, while candidate paths and protocol stacks are selected through available information, system policy and implementation heuristics.

The later events preserve useful distinctions. Expired says a message was not sent before its declared Lifetime elapsed; SendError identifies a local error such as excessive size, underlying-stack failure or incompatible properties. Even Lifetime is a hint, not a guarantee that a late message will never be sent. Priority is similarly bounded: RFC 9622 allows relative priorities to be expressed, including entirely sender-local scheduling, but guarantees nothing about how that expression will be realized.

The practical receipt chain is longer: application call, local stack handoff, device and interface disposition, on-wire observation, remote transport handling, remote application processing and the effect that matters to a user or operator. A Sent event securely answers one of those questions. It should not borrow authority from the rest.

Sources