Summary

  • RFC 1 divided the design problem: BBN had specified the Interface Message Processor (IMP) software, while the host groups had to agree on the software that would let their computers use the network.
  • Steve Crocker called the material tentative and invited reactions. RFC 3 later explained that the series was meant to circulate timely, sometimes unpolished ideas precisely because readers could mistake a written note for an authoritative decision.
  • Changes in RFC 6, UCLA’s GORDO implementation in RFC 11, and further revisions described in RFC 33 show a working process. They do not prove that RFC 1 itself was adopted unchanged at every site.

The missing agreement sat above the packet network

The first ARPA Network design had a physical and logical division. Bolt, Beranek and Newman specified the IMPs—the machines that moved messages between sites. The computers attached to them still needed software conventions for opening connections, identifying links and deciding what a remote host would do with incoming data.

RFC 1, dated 7 April 1969, was Steve Crocker’s attempt to put that host-to-host problem into a shared document. It described the IMP’s message format and sketched host software for connection requests, terminal-like sessions, larger file transfers, error checking and interactive use. It also considered a local front end that could handle immediate console responses without sending every keystroke across the network.

Those details matter because “the network protocol” was not one decision made at one layer. IMP forwarding and host software had different authors, responsibilities and failure modes. A message could reach another IMP while the two host operating systems still lacked a mutually understood way to open a session or interpret the exchange.

Crocker’s introduction gives the proposal’s status in unusually direct language: the group had reached some tentative agreements, encountered open questions, and little in the note was firm. The document is valuable partly because it preserves the work before closure. Treating it as a completed specification would erase the uncertainty it records.

What the first note actually proposed

RFC 1 organized communication around logical links between pairs of hosts. It described reserving one link for host operating-system control and using other links for user sessions. A connection could behave like a dial-up teletype session; a parallel file-like connection would allow larger transfers without terminal-oriented buffering and interrupt handling.

The memo also explored how to make remote interactive work feel usable despite network delay. One proposal was to send a small program for a local front end, written in a language then called DEL, so that routine terminal behavior could be handled near the user. The document described this as an approach under discussion, not as a feature already deployed across the network.

Its initial experiments were similarly bounded. Crocker reported work at SRI on a retrieval system and DEL front end, and described planned use involving UCLA and Utah. These statements show what participants were trying to build. They are not a site-by-site installation ledger, nor do they show that all four initial hosts had implemented every proposal.

That distinction changes how the famous first RFC should be read. It was not a command issued by a standards authority. It was a compact place to expose design choices, invite correction and give a distributed group something concrete to examine.

The series made disagreement easier to record

Two days after RFC 1, Bill Duvall wrote RFC 2, also titled “Host Software.” RFC 3 then set out documentation conventions. It said anyone at any site could produce a note, that notes should favor timeliness over polish, and that a title did not need to be unique. Bill Duvall at SRI assigned serial numbers.

RFC 3 also named a problem that remains familiar in technical governance: readers tend to treat a published statement as authoritative simply because it is written down. The stated purpose of the loose format was to encourage exchange and discussion of ideas that were deliberately less than authoritative. In other words, the serial number made a note retrievable; it did not settle the question it described.

This was not a finished standards process in miniature. The early notes mixed proposals, questions, implementation details and requests for response. Their common value came from making technical reasoning visible across sites that had to interoperate while retaining separate computers and operating systems.

Revision and implementation are different kinds of evidence

RFC 6, Crocker’s 10 April account of a conversation with Bob Kahn, records a change to the Host–IMP link field: it had become five bits, with a bit to indicate conversion. The detail is small; its timing is revealing. A design element described in RFC 1 was still being discussed and revised days later.

By August, Gerard Deloche’s RFC 11 described Host–Host procedures and their implementation in GORDO, UCLA’s time-sharing system for the SDS Sigma 7. It specified connection types, control messages, checksums, buffers and the programs that moved messages between users and the IMP interface. RFC 13, also in August, referred back to RFC 11 and proposed a zero-length message to mark the end of a file transfer over an auxiliary connection.

These records show ideas becoming more concrete in a named implementation and then attracting a focused follow-on proposal. They do not establish that every host used GORDO’s procedures or that the network had stopped changing. A working implementation is stronger evidence of operation at one site than a proposal alone, but it is not a network-wide adoption count.

RFC 33 makes the distinction explicit. In February 1970 it reported many changes from the older protocol in RFC 11, linked those changes to a December network meeting, and said the attached paper did not yet contain enough information to write a Network Control Program. It asked for responses. The network had working connections and real use, yet the host protocol was still being revised and documented.

Why the first RFC matters without being the final word

RFC 1’s historical importance is not that its every field or procedure became permanent. Its importance is that it made a cross-host design problem discussable before there was a settled implementation everywhere. The memo recorded who was responsible for which layer, offered candidates for agreement and left its uncertainties visible.

That is a different kind of achievement from deploying a protocol. A paper can frame a common problem; a revision can narrow disagreement; code can show that one system works; repeated interoperability can show that independent systems share an interpretation. These are connected stages, but one does not certify the next.

The early record therefore supports a more precise account of how coordination began. BBN specified the IMP layer. Host groups worked through the software above it. RFCs supplied a serial, portable discussion surface. Implementations and later notes supplied evidence of what had been tried and changed. The first number opened that process; it did not finish it.

Sources

The original RFC 1 is the primary source for Crocker’s tentative host-software proposal. RFC 2 records Bill Duvall’s “Host Software” note; RFC 3 explains the early documentation conventions. Crocker’s RFC 6 records a subsequent Host–IMP discussion. Deloche’s RFC 11 describes procedures and the GORDO implementation; Cerf’s RFC 13 proposes an EOF message for auxiliary transfers. Crocker and colleagues’ RFC 33 documents later changes and continuing uncertainty. The 1971 RFC 170 index provides a dated catalogue of the first notes.