History of the Internet

Link Wrote the Message. The User Still Had to Send It: RFC 2368

The Link Wrote the Message. The User Still Had to Send It: RFC 2368

RFC 2368 turned a web-era address link into a compact message template: recipient, selected headers and even a short body could arrive prefilled. Its decisive safeguard was the remaining gap. Resolving `mailto:` created a draft, not a transmission, and the user still owned the decision to edit, approve or abandon it.

Identifier Looked Like Email. It Was Not a Mailbox: RFC 2377

The Identifier Looked Like Email. It Was Not a Mailbox: RFC 2377

RFC 2377 tried to make LDAP naming deployable by borrowing names the Internet already had. Its most revealing warning concerned a value that looked perfectly familiar: `uid=mailbox-shaped-identifier` could name a directory entry without being a working email address. Reuse lowered coordination cost, but resemblance did not merge identity, directory placement and delivery.

Craig Partridge and the Gigabit That Did Not Need a New Internet

In 1989, one gigabit per second sounded large enough to indict an architecture. Craig Partridge answered by refusing to let the unit make the decision. He converted the rate into packets, instructions, memory touches, buffers and round trips, then asked which component actually failed. The exercise did not make high-speed networking easy. It made the burden of proof specific: speed alone was not a mandate to replace the Internet.

Envelope Overruled the Document: RFC 2376

The Envelope Overruled the Document: RFC 2376

RFC 2376 gave XML two places to declare its character encoding: the transport envelope and the document itself. In one common case, a missing value outside the document defeated an explicit declaration inside it. The history is a compact lesson in where protocol authority actually lives.

Manager Deleted the Row. The Circuit Could Still Exist: RFC 2366

The Manager Deleted the Row. The Circuit Could Still Exist: RFC 2366

RFC 2366 gave operators a common SNMP view of multicast over ATM. Its most revealing rule was not a counter or an address: a client, server or MCS row could disappear while associated virtual-circuit rows still existed or were in use. The management model could forget a parent before the network had finished with its children.

Group Number Stayed the Same. The Membership Did Not: RFC 2375

The Group Number Stayed the Same. The Membership Did Not: RFC 2375

RFC 2375 gave early IPv6 multicast services durable names across several scopes. It also drew a line that operations still depends on: the same group number at another scope is another group, and a node has to join it separately. The registry named the destination. It did not populate it.

Hierarchy Was in the Address. The Router Did Not Read It: RFC 2374

The Hierarchy Was in the Address. The Router Did Not Read It: RFC 2374

RFC 2374 divided an IPv6 address into a public hierarchy, a site hierarchy and an interface identifier. Then it stated the more important rule: routers would match prefixes on arbitrary bit boundaries without knowing that internal structure. The labels organised allocation. Running routes decided delivery.

Codec Had a Name. The Decoder Had Not Arrived: RFC 2361

The Codec Had a Name. The Decoder Had Not Arrived: RFC 2361

In 1998, the Internet learned how to point at multimedia formats that had grown up somewhere else. RFC 2361 carried Microsoft's WAVE numbers and AVI FourCC values into MIME's vendor tree. The bridge solved an identification problem. It did not ship software, inspect the body, make an obsolete contact current or prove that pressing play would work safely.

Srinivasan Keshav and the Two Packets That Made a Hidden Queue Observable

The queue was inside a router, beyond the sender's sight. Srinivasan Keshav's answer was not to ask the router for a declaration, but to create a tiny event whose deformation could travel back as evidence: send two packets together and examine the distance between their acknowledgements. The elegance survives only with its conditions attached. The spacing revealed a service rate under a particular scheduler model; it did not make the whole network transparent.

Address Did Not Say Which Machine Would Answer: RFC 2373

The Address Did Not Say Which Machine Would Answer: RFC 2373

IPv6 anycast reused an ordinary unicast-shaped address for an extraordinary promise: deliver this packet to one member of a configured set. RFC 2373 made the economy possible by leaving the winning machine out of the address. The route chose it.

Counter Rose. The Cause Did Not: RFC 2358 and Fast Ethernet

The Counter Rose. The Cause Did Not: RFC 2358 and Fast Ethernet

When Ethernet became ten times faster, its management vocabulary had to change without pretending that every new number was a diagnosis. RFC 2358 preserved one Ethernet identity across speeds, added evidence for 100 Mb/s operation and drew a durable line between a measured symptom and the cause an operator still had to prove.

Commit Line Was Not the Business Receipt: RFC 2371

The Commit Line Was Not the Business Receipt: RFC 2371

In a distributed purchase, the machines can agree on COMMIT while the customer is still staring at a timed-out page. RFC 2371 drew that boundary with unusual precision. Its Transaction Internet Protocol coordinated transaction managers; it did not carry the order, define the business operation or guarantee that the caller received the result.

Address Moved. The Key Did Not: RFC 2356

The Address Moved. The Key Did Not: RFC 2356

A laptop leaving a private network in 1998 acquired a new address and, to an ordinary firewall, appeared to become someone else. RFC 2356 proposed a more durable name: let the packet present a cryptographic key identifier that survived the move. That separation was powerful, but it did not make trust automatic. Authentication, authorization, Mobile IP registration, address binding, traversal and final delivery remained different receipts.

Unsubscribe Button Was Not the Unsubscribe Receipt: RFC 2369

The Unsubscribe Button Was Not the Unsubscribe Receipt: RFC 2369

In 1998, a mailing-list command could arrive inside an ordinary message without looking like a command at all. RFC 2369 gave mail clients a small set of structured headers from which they could build a consistent interface. Its deeper achievement was also its limit: the header could tell a client where an action might begin, but it could not testify that the action had finished.

Jeffrey C. Mogul and the Busy Receiver That Delivered No Packets

The processor was not idle. It was obeying every new arrival with such urgency that the work already admitted could not finish. Jeffrey C. Mogul and K. K. Ramakrishnan called the failure receive livelock: a receiver visibly running at full speed while useful delivery falls to zero. Their correction began with a severe accounting rule—activity at the entrance is not throughput at the exit.

Packet Diagram Was Correct. The Implementations Still Disagreed: RFC 2360

The Packet Diagram Was Correct. The Implementations Still Disagreed: RFC 2360

A protocol can assign every bit and still leave its most consequential decision unwritten. When a count is wrong, an option is unknown or memory runs out, does the receiver salvage the message, discard it, reset the session or preserve the old state? In 1998, RFC 2360 treated those questions as part of the protocol rather than housekeeping left to each programmer.

Repair Packet Joined the Congestion: RFC 2354

The Repair Packet Joined the Congestion: RFC 2354

A damaged media stream seems to ask for an obvious remedy: send something extra. In 1998, RFC 2354 showed why that instinct was incomplete. A retransmission, parity packet or redundant encoding consumes the same path that lost the original. Repair can recover a unit before playout, arrive too late to matter, or add enough load to deepen the loss. The protocol question was therefore never simply how to make UDP reliable. It was how to spend delay and bandwidth without mistaking more traffic for more truth.

Before Reliable Multicast Could Become a Standard, It Had to Prove It Would Not Become Everyone Else’s Congestion: RFC 2357

Reliable multicast promised to send one copy of a file and let the network distribute it to many receivers. RFC 2357 asked who would pay when that economy multiplied feedback, prolonged a transfer or crowded out unrelated traffic. Its answer was unusual for 1998: publication status itself would carry an evidentiary burden.

One Idle Link, Two Histories: RFC 2353

When an idle HPR/IP link stopped sending liveness traffic, silence saved packets and preserved ambiguity. One endpoint could retire the link while its neighbour still treated the same identity as active. RFC 2353 did not hide that split; it specified how to discover and reconcile it.

Company Register Was Supposed to Settle the Domain Name. It Only Moved the Boundary: RFC 2352

The Company Register Was Supposed to Settle the Domain Name. It Only Moved the Boundary: RFC 2352

In 1998, an independent RFC proposed giving each legally registered organisation a domain path derived from its formal name, legal form and jurisdiction. The promise was clean: let company and trademark authorities decide entitlement, then let DNS carry the result. The attached RFC Editor's note identified the harder truth. Encoding a legal record into a hierarchy would not erase naming politics, migration cost or registry discretion; it would redistribute them across a longer institutional chain.