History of the Internet

Back Door Was Not a Route: How RFC 831 Reached a Partitioned SATNET

The Back Door Was Not a Route: How RFC 831 Reached a Partitioned SATNET

The emergency machine was allowed to behave like a gateway, but it was forbidden to become one. That distinction carried the whole proposal in RFC 831. A multihomed host at UCL could rewrite a chosen maintenance exchange around a broken SATNET path, yet it would send no routing updates and attract no ordinary traffic. The recovery door was useful precisely because it did not become a road.

Gateway Could Carry the Bytes. It Could Not Invent the Missing Meaning: How RFC 875 Challenged Protocol Translation

The Gateway Could Carry the Bytes. It Could Not Invent the Missing Meaning: How RFC 875 Challenged Protocol Translation

A rectangle labelled “gateway” made incompatible networks look one arrow apart. RFC 875 asked what the rectangle had to remember: two address models, two acknowledgements, two flow-control contracts and exceptional signals that did not command the same actor. Moving data was the easy part. Preserving what the data meant was the architecture.

Master File Could Be Current. The Network Could Still Be Stale: How RFC 849 Split Push from Poll

The Master File Could Be Current. The Network Could Still Be Stale: How RFC 849 Split Push from Poll

In May 1983, Mark Crispin described a naming failure that could survive a perfectly updated master file: a host that never learned the file had changed. RFC 849 treated freshness not as a property of the registry alone, but as a chain of version evidence, delivery, integrity, local installation and recovery.

Host Table Said TCP. The Socket Had to Answer: How RFC 832 Measured Running Code

The Host Table Said TCP. The Socket Had to Answer: How RFC 832 Measured Running Code

In December 1982, the Internet already had a list of machines said to support TCP. David Smallberg did not treat the list as deployment. He used it as a set of claims, tried the service ports, named the different ways a connection could fail, retried negative observations, and issued another dated survey the following week. The resulting RFC sequence is an unusually clear record of how operational truth is made: execution outranks declaration, but one successful socket is still only evidence from one place and time.

Client Became the Service: How RFC 818 Put User Telnet Behind Port 107

The Client Became the Service: How RFC 818 Put User Telnet Behind Port 107

A client normally knocks; a server normally listens. RFC 818 made that picture deliberately unreliable. On a small terminal concentrator, the useful application was the Telnet program that opened connections outward. By placing that User Telnet capability behind a well-known incoming port and joining the two sides with a pseudo-terminal, BBN turned a local client into a remotely invocable service without changing Telnet's common grammar.

Name Service Was Almost a Negotiator: How RFC 830 Separated Domains from Capabilities

The Name Service Was Almost a Negotiator: How RFC 830 Separated Domains from Capabilities

A file-transfer program asks for NIFTP. The destination has no NIFTP implementation, but it does offer FTP. In the architecture proposed by RFC 830, that mismatch did not have to end the attempt. One part of the name service found the destination domain; another part asked what the domain could actually do and returned a compatible alternative. Before DNS became a shared database of typed records, the Internet briefly considered making name service a live negotiator.

Number Did Not Make It a Standard: How RFC 825 Made Intent Part of the Record

The Number Did Not Make It a Standard: How RFC 825 Made Intent Part of the Record

A procurement clause says a product is “RFC 825 compliant.” The number looks precise, the link is public and the document is real. Yet none of those facts tells the buyer whether the cited memo was a standard, a discussion, a status report or merely information. In 1982, RFC 825 confronted exactly that ambiguity. Its answer was to make a document declare what kind of act it was performing.

Layer Was Not the Module: How RFC 817 Cut Across the Stack

The Layer Was Not the Module: How RFC 817 Cut Across the Stack

One typed character could make three answers leave a server: a TCP acknowledgement, a window update and a Telnet echo. The protocol layers were each behaving correctly. The implementation was still wasting packets. RFC 817 used that small inefficiency to make a larger distinction: the lines that explain a protocol are not always the lines along which running software should be divided.

Error Message Was Advice, Not a Verdict: How RFC 816 Layered Failure Decisions

The Error Message Was Advice, Not a Verdict: How RFC 816 Layered Failure Decisions

A gateway that has crashed cannot send the error message explaining why packets disappear into it. RFC 816 began with that silence and built a layered answer: let routing repair distant failures, make the host replace a dead first hop, let TCP expose retransmission and timeout, and leave application completion to the application.

Missing Segment Did Not Stop the Next One: How RDP Separated Reliability from Order

The Missing Segment Did Not Stop the Next One: How RDP Separated Reliability from Order

In 1984, the Reliable Data Protocol made a choice that still unsettles casual descriptions of transport: a later message could be safely received, individually acknowledged and even handed to an application while an earlier message was still missing. Reliability described whether every message would eventually arrive; order described when the application was allowed to see it. RDP refused to pretend those were the same promise.

Name Was Not the Address: How RFC 814 Kept Identity Separate from Route

The Name Was Not the Address: How RFC 814 Kept Identity Separate from Route

In 1982, a stale host table could send queued mail to an unexpected machine after the intended host had moved. RFC 814 treated that failure as more than bad data. It exposed four different references—name, address, route and port—and argued that an Internet host should translate among them without pretending they were the same thing.

Acknowledgement That Stopped at the Link: How PPP Localized Reliability

The Acknowledgement That Stopped at the Link: How PPP Localized Reliability

In 1994, PPP acquired an optional way to number, acknowledge and retransmit frames across one link. RFC 1663 made that recovery loop precise—and kept its authority deliberately narrow. A returned acknowledgement could establish progress between two adjacent peers; it could not certify authentication, routing or an application result beyond them.

Hierarchy Was Really a Graph: How Gopher Put the Next Server Inside Every Menu Line

The Hierarchy Was Really a Graph: How Gopher Put the Next Server Inside Every Menu Line

Gopher made a scattered collection of autonomous machines look like one calm hierarchy. The illusion did not come from a global catalogue or a persistent session. It came from a modest menu line that separated what a reader saw from what a client had to do next: interpret a type, preserve an opaque selector, contact a host and choose a port. A label invited the click; four hidden fields moved authority elsewhere.

Report That Could Not Declare the Link Bad: How PPP Kept Quality Policy Local

The Report That Could Not Declare the Link Bad: How PPP Kept Quality Policy Local

A PPP peer could say how many packets and octets it had sent, and return what it had seen from the other direction. It could not make the protocol pronounce the link acceptable. Link-Quality-Reports standardized a shared accounting mechanism while leaving the threshold, the remedy and even the monitoring policy at each endpoint.

One Link Was Actually Several: How PPP Multilink Kept a Bundle in Sequence

A second line could join a PPP connection without beginning a second network conversation. Multilink PPP treated the lines as members of one bundle, cut a packet into independently framed fragments, and gave the receiver just enough shared order to put the packet back together. The difficult part was not splitting bytes. It was deciding what had to remain common when every member could run at a different speed.

Success That Ended Its Own Stream: How XMPP Restarted After TLS and SASL

The Success That Ended Its Own Stream: How XMPP Restarted After TLS and SASL

In XMPP, a successful security negotiation did not authorize the old XML stream to continue. It made that stream obsolete. The parties kept the same TCP connection, discarded context that no longer deserved trust, exchanged new stream headers and learned again which features were valid. The wire stayed up; the application-layer truth was rebuilt.

Characters the Checksum Never Saw: How PPP Filtered the Serial Path Before Trusting the Frame

The Characters the Checksum Never Saw: How PPP Filtered the Serial Path Before Trusting the Frame

PPP did not ask its checksum to remember every character that crossed a serial path. It first defined which bytes belonged to the frame, which were temporary disguises, and which low control characters intervening equipment might have inserted. Only after the receiver reversed that narrow path accommodation did it test the frame it believed its peer had sent.

Header That Appeared Only When It Saved Bytes: How IPComp Made Compression Conditional

The Header That Appeared Only When It Saved Bytes: How IPComp Made Compression Conditional

IPComp negotiated a common way to decompress traffic, then allowed each packet to decline the offer. If compression plus its four-byte header did not make that packet smaller, the correct wire format was the original packet with no IPComp header at all. Capability lived in the association. Execution had to earn its place one datagram at a time.

Datagram Relay That Died with a Stream: How SOCKS5 Bound UDP to a TCP Association

The Datagram Relay That Died with a Stream: How SOCKS5 Bound UDP to a TCP Association

A SOCKS5 relay could still be receiving perfectly formed UDP datagrams when its TCP control connection vanished. The specification nevertheless ended the association. UDP had no farewell to offer, so the protocol borrowed a lifetime from a different transport—and kept that borrowed authority deliberately narrow.