Summary

  • RFC 880 made an official protocol entry a bundle of separate claims: requirement status, defining document, known problems, other references, dependencies, contact and, in some cases, observed use.
  • Its own rows show why one label was insufficient: TCP was Recommended while carrying documented defects; TFTP was Elective while already used; GGP was Experimental while operating in the core gateways.
  • Later standards-process documents separated maturity from requirement level, and the periodic official summary was eventually retired when an online list displaced it. None of those catalogues could prove running behaviour by themselves.

In October 1983, an implementer looking for the official Internet protocol suite did not receive a clean product matrix. RFC 880, Official Protocols, offered something more candid. It named the specification, assigned a status, listed dependencies and a contact, and then wrote down the awkward parts.

Some specifications were old. Some implementations had moved ahead of their documents. Some protocols were used even though their status was Experimental. Some options had documents but no general use. “Official” described membership in this annotated record. It did not collapse the record into a warranty.

The catalogue began with documents scattered across time

RFC 880 said that, to first order, the official protocols were those in the March 1982 Internet Protocol Transition Workbook. It immediately qualified that statement. Several protocols in use were absent from the workbook. Other workbook protocols had been revised. Mail had moved into a newer volume, Telnet and its most useful options into another booklet, implementation advice into a separate guide, and unrevised material remained in the 1978 ARPANET Protocol Handbook.

The list therefore did not discover one timeless source of truth. It reconciled a moving documentary estate. Its predecessor, RFC 840, had used the same basic design six months earlier and was now obsolete. Replacing RFC 840 with RFC 880 was not an embarrassment. It was evidence that catalogue state had a date.

Every protocol entry had distinct fields. STATUS stated a requirement posture. SPECIFICATION named the defining material. COMMENTS recorded departures, defects and planned work. OTHER REFERENCES supplied explanation or updates. DEPENDENCIES named the protocols beneath the entry. CONTACT named a person who could answer questions.

That schema prevented a common category error. A document could be official without being sufficient. A protocol could be encouraged without being installed. An implementation could run without matching its cited specification. A dependency could be required even when the application above it was optional.

Five statuses described permission, not one ladder of prestige

RFC 880 defined Required, Recommended, Elective, Experimental and None. Required meant all hosts had to implement the protocol. Recommended meant all hosts were encouraged to do so. Elective left implementation to the host. Experimental was for coordinated participants in the experiment. None meant the entry was not itself a protocol.

These were not five grades of technical excellence. IP and ICMP were Required. UDP and TCP were Recommended. TFTP was Elective. EGP and GGP were Experimental. The Catenet Model was None because it described architecture rather than a wire protocol.

A status answered a bounded question about expected implementation. It did not say whether the code was enabled, interoperable, secure, complete or working at this moment. Even Required did not turn a declaration into a socket response.

TCP was Recommended and still arrived with an error list

The TCP row is the clearest antidote to ceremonial readings of “official”. RFC 880 called TCP Recommended and pointed to RFC 793. Its comments then said that many corrections had been received and that most were document bugs rather than protocol bugs.

The entry did not stop at a generic warning. It said the event-processing section needed clarifications. Push still carried language suggesting a record mark even though Push was not a record mark. The Maximum Segment Size default and scope needed work. Idle connections should not be closed merely for being idle. Queued data at close and out-of-order retention needed clearer treatment.

None of this made TCP unofficial. It made the catalogue useful. The status could coordinate an implementation expectation while the comments preserved unresolved interpretation. A procurement form that copied only “Recommended” would discard the very evidence the official row considered important.

Experimental did not mean absent from the network

The routing rows separate classification from execution even more sharply. EGP was Experimental and described as under development. GGP was also Experimental, yet its comments said it was the gateway protocol then used in the core gateways.

That is not proof of how many gateways ran GGP, how well they ran it or how long the arrangement lasted. It is enough to reject a false inference: Experimental did not mean zero operational use. The status governed the conditions under which hosts should adopt or coordinate a protocol; it was not a measurement of packets on the wire.

The reverse mismatch also appeared. The Stream Protocol entry said its implementation had evolved and might no longer be consistent with the specification. Here running code existed, but the catalogue refused to let existence prove conformance.

TFTP supplied a quieter example. It was Elective, while the comments said it was in use on several local networks. Optionality and adoption occupied different fields.

Telnet options needed a use column of their own

RFC 880's Telnet Options table carried columns for an RFC or NIC document, inclusion in the newer Telnet booklet, presence in the old handbook, and USE. Binary Transmission, Echo, Suppress Go Ahead, Status, Timing Mark and Extended Options List were described as frequently implemented. Many other options showed no general use.

The option family as a whole was Elective. Yet the catalogue still distinguished whether a particular option had a document, had been republished, remained only in an old source or was generally used. Formal optionality did not answer feature-level prevalence.

This mattered because a protocol name can hide a large optional surface. “Supports Telnet” did not prove support for every option. A reference to a document did not prove a peer would negotiate it. The USE column was imperfect historical observation, but it acknowledged that running code required a separate claim.

Dependencies and contacts kept the row attached to responsibility

A protocol did not operate alone because it appeared alone in a list. SMTP depended on TCP. TFTP depended on UDP. Telnet depended on TCP. Experimental routing protocols depended on IP. The dependency field showed which lower contracts had to exist before an upper status became meaningful.

The contact field was equally practical. Experimental use was supposed to be coordinated with a contact person. Comments that required clarification had somewhere to go. This did not give one person sovereign authority over every implementation. It kept the catalogue from pretending that classification abolished maintenance, interpretation or local judgment.

Later editions continued the method. RFC 991 called itself an official status report and retained specifications, comments, dependencies and contacts. The succession of reports made revision part of the mechanism.

Maturity and requirement eventually received separate names

By 1991, RFC 1200 explicitly separated a protocol's STATE of standardization from its STATUS as a requirement. Standard, Draft Standard, Proposed Standard, Experimental, Informational and Historic described one axis. Required, Recommended, Elective, Limited Use and Not Recommended described another.

RFC 2026 developed the standards process further. A specification could move through maturity levels, while applicability statements and requirement levels addressed where it should be used. RFC 6410 later reduced the standards track from three maturity levels to two. Changing the process did not make maturity a deployment counter.

The periodic summary itself eventually failed its freshness test. RFC 7100 retired the final Internet Official Protocol Standards summary and STD 1 after the document fell out of use in favour of the RFC Editor's online list. A database was easier to maintain than a periodically replaced monolith. It still reported documentary state, not the state of every implementation.

Sources and limits

This account uses RFC 840, RFC 880, RFC 991, RFC 1200, RFC 2026, RFC 6410 and RFC 7100. They establish catalogue and process history. They do not establish present deployment share, named-product conformance, current security, an outage or an operator's policy.