Summary

  • RFC 1011 separated a protocol’s specification from its status, comments, dependencies and contact, making a large and changing technical system easier to coordinate.
  • Its “required” label stated what hosts were expected to implement. It did not show which code was installed or running on any host.

A list that had to expire

The May 1987 memo by Joyce Reynolds and Jon Postel was called Official Internet Protocols. It described itself as a status report: it identified the documents that specified protocols used in the Internet and added comments about revisions or planned changes. This was more like a dated map of a moving system than a single manual declaring every machine’s state.

The document made that limitation visible. Readers were told to use a copy dated within the preceding three months. Its entries could point to a specification, identify dependencies, note implementation problems, and name a contact. A reader could learn not only which document described a protocol but also where the description was incomplete or where further coordination belonged.

Each protocol received one of five labels. Required meant all hosts must implement it. Recommended encouraged implementation. Elective left the choice to hosts. Experimental meant implementation belonged in a coordinated experiment. None marked an entry that was not itself a protocol. These were different expectations, not five measurements of what machines were doing.

The status did not install the software

The distinction is clearest in the rows. IP was required. TCP and UDP were recommended. The memo’s “Graphics Protocol” entry was elective, while its comment said there were no known active implementations. The comment did not erase the entry; the label did not summon an implementation. The authors recorded both the category and the limit of their knowledge.

That small pairing matters. A protocol catalog can be authoritative about the state assigned to a specification and still be unable to certify the behavior of every host. “Required” is a policy about compatibility expectations. To establish operational reality, one needs implementation and observation. RFC 1011 offered no complete host census, no inventory of installed versions, and no test receipt proving that every required protocol ran correctly.

Specification and implementation met over time

RFC 1011 sat inside a recurring publication sequence. Earlier status reports were replaced; later reports revised the list. By April 1989, RFC 1100 described the broader standardization procedure: proposals could come from anyone, technical groups supplied recommendations, and the general policy was to wait for implementation experience before naming a protocol an official standard. It also said an RFC number was never reused, even as a protocol could be improved and documented in later RFCs.

This did not make writing standards irrelevant. A common specification let independent implementers aim at the same behavior. But the path from proposal to service ran through more than publication: a version had to be implemented, tested against other systems, revised when experience exposed problems, and adopted by hosts. The 1989 Host Requirements documents made many of those expectations more concrete for full-function Internet hosts. Even there, normative language described what a conforming host should do; it was not evidence that every deployed machine complied.

The list’s rhythm therefore carried meaning. A quarterly status report could help operators and implementers find the current document, but its date was part of its truth. A row that was correct when printed could become stale as specifications, comments and practice changed. The warning not to use an old copy was an admission that coordination required maintenance.

A useful record, not a running network

RFC 1011 is best read as a coordination instrument. It made status legible, connected entries to documents and people, and exposed uncertainty instead of hiding it. Those functions could shape decisions; a recommendation or requirement was not empty rhetoric. Yet the report itself did not cross into each host and make the decision real.

That boundary is still useful when reading Internet history. A document number is not an implementation. A standards label is not a packet capture. A recommendation is not a deployment count. Shared rules can narrow the space of compatible choices, but the network exists through the systems that operators choose to run and keep interoperable.

Sources