Summary

  • TCP urgent did not create a second delivery channel. URG made a pointer meaningful and asked the receiver to enter urgent mode until a boundary in the normal sequence space had been consumed.
  • Telnet and FTP used that notification to attract attention during blocked work, but an in-stream DATA MARK supplied the synchronizing evidence. Notifications could merge and did not count commands.
  • Standards briefly moved the pointer by one byte; deployed stacks largely did not. RFC 6093 restored deployed semantics while telling new applications to avoid the mechanism, and RFC 9293 retains that compatibility bargain.

The interrupt that remained in the stream

The name invites the wrong mental picture. “Urgent data” sounds like a privileged parcel that jumps a queue. TCP supplied no such pipe. RFC 793 put a sixteen-bit field in the ordinary header and made it meaningful only when URG was set. Add the field to the segment sequence number and the receiver learns a point in the same byte stream.

While that point lies ahead of bytes already consumed, TCP tells the application to enter urgent mode. When consumption catches up, it announces normal mode. An updated pointer need not produce another visible event, so sender indications and receiver notifications never formed a reliable one-for-one count.

Telnet needed attention, not a second pipe

The application problem was real. A terminal server could be busy producing output when a user wanted to interrupt it. RFC 854 paired a TCP urgent notification with Telnet DATA MARK. Urgency woke special handling; the receiver scanned the ordinary stream, discarded intervening characters and returned to normal only after finding the mark.

The distinction mattered. Several Synch signals could merge. TCP might report the end of urgent information before DATA MARK appeared, yet Telnet had to keep scanning. The in-stream command supplied application meaning that the transport indication could not.

RFC 959 reused the pattern for FTP. If a server could not watch control and data work simultaneously, a client could send Telnet Interrupt Process, Telnet Synch and then ABOR or STAT. The urgent event attracted attention; the following FTP command still decided what to do.

One specification contained two endpoints

RFC 793's header description said the pointer names the octet after urgent data. Its state-machine text set SND.UP to SND.NXT-1, which names the last urgent octet. The difference is one byte, but protocol boundaries live on differences of one.

RFC 1011 called the page-17 wording wrong in 1987. RFC 1122 made LAST rather than LAST+1 a host requirement in 1989. It also required arbitrary-length urgent sequences and asynchronous notice to the application.

This looked like normal specification repair: identify an ambiguity, choose a boundary and require implementations to converge. The network supplied a different verdict.

A socket API made one byte look separate

RFC 6093 reported that virtually all tested popular implementations retained the page-17, octet-after convention. More importantly, their default socket behavior commonly removed the last urgent byte from ordinary reads and exposed it through MSG_OOB. A transport boundary had become one byte that appeared “out of band”.

That adaptation narrowed an arbitrary-length mechanism to a one-byte slot. A later urgent indication could overwrite a byte the application had not read. SO_OOBINLINE could restore inline delivery, but changing a socket option did not make every peer or intermediary interpret the pointer alike.

Middleboxes could erase urgency

Security devices faced streams whose endpoints and inspection logic could parse different bytes. Some cleared URG and zeroed the pointer. The data continued inline, but an application waiting for a special notification might never receive it. A control path designed to wake blocked processing could itself disappear at a device the endpoints did not control.

This was not proof that every middlebox behaved alike. It was enough to defeat the architectural promise. An application cannot make correctness depend on a signal that widely deployed devices may remove and that receiver APIs may expose under incompatible boundaries.

The standard moved while the warning hardened

RFC 6093 chose interoperability over the unused correction. It restored the octet-after meaning followed by known implementations. At the same time it withdrew the mechanism from new design: new applications should not use urgent indications; implementations must retain them for legacy users; remaining applications should request inline delivery and remain correct if URG is cleared.

RFC 9293 carries the same settlement into the current TCP specification. Support is mandatory. New application dependence is discouraged. Compatibility preserves old conversations without pretending that a legacy field is a trustworthy new abstraction.

Sources and evidence limits

The RFCs establish the intended in-stream boundary, Telnet and FTP uses, the off-by-one correction, observed implementation practice, middlebox interference and the modern requirements. They do not prove one deployment date, identical socket behavior everywhere or reliable traversal of every path. Urgency does not bypass TCP ordering, congestion control or application parsing.

The history is therefore not a story of a field being abolished. It is the subtler retirement of authority: the bit remains on the wire, while new software is told not to stake correctness on what it appears to promise.