History of the Internet

Row Was Active. The Reservation Was Still Unproven: RFC 2213

The Row Was Active. The Reservation Was Still Unproven: RFC 2213

RFC 2213 gave Integrated Services a management surface detailed enough to inspect and, in some implementations, alter. Its precision was useful precisely because every field stopped short of proving the whole reservation.

Server Drew Three Mail Maps. It Did Not Prove a Mailbox Was There: RFC 2342

The Server Drew Three Mail Maps. It Did Not Prove a Mailbox Was There: RFC 2342

RFC 2342 let an IMAP server disclose the naming conventions for personal, other-users and shared mailboxes. A prefix and hierarchy delimiter could tell a client how to ask the next question. They could not answer whether a particular mailbox existed, appeared in a list, accepted a SELECT, exposed messages or reached a reader.

One Path, Four Algebras, and One Contagious Unknown: RFC 2215

A network path can be described by many numbers, but those numbers do not obey one law. RFC 2215 made that distinction operational: a break propagates by logical OR, aware hops are counted, bandwidth and packet size are narrowed by minima, and latency accumulates. More importantly, an unknown contribution remains unknown downstream. A composed value is therefore a qualified path characterization—not a reservation, a measurement of delivered performance, or a receipt for an application result.

Packet Contained Picture and Sound. It Did Not Prove a Programme Played: RFC 2343

The Packet Contained Picture and Sound. It Did Not Prove a Programme Played: RFC 2343

RFC 2343 put MPEG-2 video slices and audio frames into one RTP payload so that a stored programme could travel as one coordinated stream. The packet carried useful timing and boundary evidence. It still could not testify for the network, decoder, renderer, loudspeaker, screen or viewer that came after it.

Service Had a Name. The Name Proved Almost Nothing: RFC 2216

The Service Had a Name. The Name Proved Almost Nothing: RFC 2216

In 1997, the Internet engineering community gave quality-of-service offerings a namespace. But RFC 2216 made the harder point first: a service number was only an address into a specification. The proof began after the name—with the caller, the traffic contract, the element’s admitted state, its packet-handling rules, the way requests were merged, and the behavior actually observed.

One Clean Match Hid the Hard Questions: RFC 2345 and the Company-Name Lookup

A company name went in; a name and a URL came back. RFC 2345 made that exchange intentionally small enough for a 1998 browser add-in and a port-43 server. The economy was the point. Yet the response line carried no proof of who registered the domain, which legal entity the name denoted, how the directory chose or ranked the entry, what it omitted, who controlled the page, or whether the user would receive a working service. A useful direction was still only a direction.

Error Terms That Made a Promise Calculable: RFC 2212

The Error Terms That Made a Promise Calculable: RFC 2212

Guaranteed Service did not promise that a network would behave like a perfect wire. RFC 2212 did something more useful: it required every participating element to put a maximum price on its departure from that ideal, then showed how those prices could be added into a delay bound without pretending that the bound proved the rest of the application.

Map Was Not the Road: What RFC 2333 Let NHRP Resolve—and What It Could Never Prove

The Map Was Not the Road: What RFC 2333 Let NHRP Resolve—and What It Could Never Prove

A clean NHRP cache row could look like the end of a problem. It joined an IP destination to an NBMA address, carried an authority class and retained a holding time. Yet RFC 2333 placed that row in a much longer chain. Routing had to choose a path first. NHRP could then resolve a suitable next hop. A connection-oriented NBMA layer might still need to build a circuit. Packets still had to cross it, the remote system still had to answer, and the application still had to finish. The map was useful precisely because it was not the road.

Request Reached the Coffee Pot. The Cup Was Still Empty: RFC 2324

The Request Reached the Coffee Pot. The Cup Was Still Empty: RFC 2324

RFC 2324 made a networked coffee pot answer HTTP-like commands, then quietly exposed how little a successful exchange can say about the physical world. A valid `BREW` request is evidence about a message and a controller. It is not a receipt for hot coffee, a filled cup, a safe drink or a person taking the first sip.

Bit That Invalidated a Path: What RFC 2210's ADSPEC Could Actually Prove

The Bit That Invalidated a Path: What RFC 2210's ADSPEC Could Actually Prove

RFC 2210 gave an RSVP receiver a compact account of the path in front of it. The account could include hop count, bandwidth, latency, MTU and service-specific terms. Yet the most important field was not a large number or a precise bound. It was a break bit: a one-bit warning that the path had crossed a place where the assumptions behind the rest of the summary no longer held. The design is a useful history of network evidence—how declarations, advertisements and requests can remain distinct even when they travel in the same signaling exchange.

Alias Reached the Child Zone. Nothing Else Was Proven: RFC 2317

The Alias Reached the Child Zone. Nothing Else Was Proven: RFC 2317

A reverse query for one address can cross two administrative boundaries before it returns a name. RFC 2317 made that path possible for IPv4 blocks smaller than a /24, but the records along the path remain narrow receipts: they show how DNS reached a PTR answer, not who owns the addresses, who may alter the parent, whether a route is authorised, or whether any named service works.

Association Was Mature. The Security Result Was Not: RFC 2367

The Association Was Mature. The Security Result Was Not: RFC 2367

A diagnostic console shows an IPsec Security Association in the `MATURE` state. Its SPI, algorithms, addresses and lifetime are all present. That is useful evidence—but only of what one local Key Engine reported. RFC 2367 drew the interface boundary clearly enough to show why the green row cannot certify the peer, the packet path or the application beyond it.

Address Said “Stay Here.” Only the Router Could Enforce It: RFC 2365

The Address Said “Stay Here.” Only the Router Could Enforce It: RFC 2365

An IPv4 multicast packet can carry a destination inside 239/8 and still escape the region its operator intended. RFC 2365 made that uncomfortable distinction explicit: the address describes an administrative scope, while containment is performed by boundary routers whose interface definitions, control-plane behaviour and running implementation must all be correct.

When a Successful ESRO Result Still Ends in Failure

In ESRO, a performer could finish an operation, send a successful result, and later receive a failure indication even though the invoker had already accepted that result. RFC 2188 made room for both observations to be true. Its most durable lesson is not about a forgotten 1990s transport optimisation, but about evidence: protocol efficiency, handshake design and endpoint knowledge are different things, and one endpoint’s final event does not automatically become the other endpoint’s history.

Backup Route’s Invoice

The Backup Route’s Invoice

A second Internet provider promised resilience, but the extra route appeared only after the first path failed. RFC 2260’s enduring insight was that multihoming never removed the bill for reachability; it decided whether that bill would be paid in global routing state, provider coordination, enterprise addressing, tunnels or less direct paths.

RFC 2187’s Cache Hierarchy Was About Authority, Not Distance

The words *parent* and *sibling* make an Internet cache hierarchy sound like a family tree drawn across the network. RFC 2187 described something less geometric and more operational: a division of authority over what happens after a cache miss. Both kinds of neighbour might satisfy a confirmed hit, but only a parent could be asked to continue toward an uncached object. That boundary made the hierarchy a configured request-handling relationship, while ICP supplied only bounded evidence for choosing among possible next sources.

RFC 2277 Put UTF-8 and Language on the Review Form. Understanding Was Still Elsewhere

A protocol specification arrives for review with three reassuring statements: its text is UTF-8, its natural language can be tagged, and its internationalization choices have their own section. In 1998, RFC 2277 made those statements part of the IETF's standards discipline. They made responsibility visible. They did not show that a particular receiver could decode the bytes, render every character, understand the language, follow the proposed locale rules or achieve the intended result.

RFC 2186 drew a strict boundary between a fast cache hint and proof

In 1997, ICPv2 addressed a narrow operational problem: a Web cache sometimes had to choose among neighbours before a heavier exchange could justify its own delay. The protocol therefore compressed uncertainty into quick, bounded signals. Its historical interest lies as much in what those signals could not establish as in what they could.

Cheapest Plan Was Only a Forecast

The Cheapest Plan Was Only a Forecast

A query optimizer can be perfectly correct about what a query means and still be badly wrong about how long its chosen plan will take. Patricia G. Selinger and the System R team made that tension operational in 1979: let users state the result they want, enumerate plausible physical routes, estimate their cost, and choose before execution begins. The power of that design came from treating the estimate as a decision instrument—not a prophecy.

Tunnel Was One Hop. Its Routes Were Two: RFC 2185

The Tunnel Was One Hop. Its Routes Were Two: RFC 2185

An IPv6 router could see one neat point-to-point link while the packet underneath crossed an independently routed IPv4 network. RFC 2185 made the resulting obligation unusually clear: one control plane had to deliver the packet to the right encapsulator, and another had to carry the outer packet from there. Neither route could keep the other's promise.