Summary

  • RFC 825 required an RFC to state its intent because the same numbered series carried specifications, discussions, information, changing status notes and meeting reports. The number located a document; it did not identify one universal level of authority.
  • Public files, mailing-list announcements and a conservative ASCII page format made the record portable across equipment. Ease of retrieval widened access without manufacturing consensus, adoption or conformance.
  • Later documents defended one archive while separating document identity from standards identity. Reliable use therefore needs the RFC number together with status, date, stream or process, supersession and implementation evidence.

The missing field was more important than the number

The fictional procurement clause is not wrong because RFC 825 is obscure. It is wrong because “compliant” has no defined object. RFC 825 did not specify a network protocol for a product to implement. It offered guidance about RFCs themselves. A document number can make a reference exact while the proposition built on that reference remains false.

RFC 825 began from a practical fact. People published RFCs for different reasons: to circulate information, to start or continue a discussion, or to specify a protocol. A single cover and a single sequence of numbers therefore contained acts with different consequences. The series needed a field that told the reader which act was intended.

The memo required that statement on the title page or in the first or second paragraph. It did not require one formula word for word. It required the general intent to be clear. That distinction mattered: the common rule was a disclosure requirement, not an attempt to force every contribution into identical prose.

Five forms divided the work without dividing the shelf

RFC 825 supplied five examples. A Specification said that the memo specified a standard for the ARPA Internet community and that hosts were expected to adopt and implement it. A Discussion focused attention on a problem and possible solutions while expressly saying that none was yet intended as a standard. Consensus might emerge later; publication did not claim that it already existed.

An Information memo invited reaction to material that might be interesting even when it was not central to the Internet research programme. A Status memo described projects accurately as of its publication date while warning that the information could change and later RFCs could reflect the change. A Report recorded a meeting: important decisions, limits or expansions of optional protocol features, policy questions, technical topics and work still unfinished.

Those categories were not merely literary genres. They allocated evidentiary weight. A discussion proved that an idea had entered public consideration, not that peers had accepted it. A status memo supplied a dated snapshot, not a permanent fact. A meeting report could prove that a decision was recorded, but the scope of that decision still depended on the meeting and the process behind it. A specification made a stronger claim, yet implementation and adoption remained separate evidence.

Putting every category in one series preserved a common retrieval path. Keeping the intent visible prevented the common path from flattening their authority.

The old page was a compatibility layer

RFCs were stored as public-access files. A short message to a distribution list announced that a memo was available. Interested people copied the file and printed or displayed it on their own equipment. That distribution model depended on documents surviving machines that did not share fonts, screens, printers or text software.

RFC 825 responded with a narrow representation contract: ASCII characters; no more than 58 lines followed by a form feed on each page; no more than 72 characters followed by carriage return and line feed on each line; no overstriking or underlining. Headers, footers, page numbers and indentation all counted within the limits.

These constraints can look quaint when separated from their transport purpose. In context, they were an access mechanism. The archive did not require a particular word processor or display. A person could retrieve a stable file and see roughly the same record on different equipment.

Portability did not change the memo's intent. ASCII did not make an Information note a standard. A distribution-list announcement did not constitute a vote. Public access did not prove that anyone had implemented the proposal. The format made the evidence travel; it did not decide what the evidence meant.

A serial number identified a document, not a protocol state

By 1995 the confusion had become explicit enough for RFC 1796 to carry the title Not All RFCs are Standards. It described the RFC series as the publication channel for Internet standards and for other publications. Publication as an RFC, it said, did not itself confer recognition as a standard.

The failure often occurred during citation. Each RFC had a status relative to the standards process, but references sometimes retained the number and omitted the status. The pointer remained technically correct while its authority grew in the retelling. What looked like harmless compression was a change in the claim.

RFC 1796 separated two numbering systems. RFC numbers identified documents. STD numbers identified standard protocols, and the relationship was not one to one. A standard could be specified by more than one RFC, while a document retained its RFC number when it received an additional STD identity. Asking “which RFC?” and asking “which standard?” were related questions, not synonyms.

This is an unusually clean example of a thin registry. The RFC number coordinates uniqueness and retrieval. It should not be asked to encode every later fact about status, revision, adoption and implementation. Those facts belong in linked records whose provenance and dates remain visible.

One archive was stronger because it admitted weaker claims

RFC 1796 considered the objection that standards and non-standards publications should live in separate series. Its answer was not to pretend that the distinction did not matter. It was to improve status visibility while retaining one archive.

The single series made documents easier to find and file servers easier to organise. The authors observed that limited-scope subseries tended to vanish. They also preferred an openly retrievable experimental, privately developed or unsuccessful specification to one hidden in a private repository. A deployed product was easier to understand when its specification could be found, even if that specification had never become an Internet Standard.

Broad preservation and strict endorsement are therefore compatible. The archive can accept a discussion without blessing its conclusion. It can preserve a failed proposal without deleting the failure. It can keep a historic specification available after operators move on. The value comes from refusing to make visibility depend on victory.

The price is metadata discipline. If a search result, quotation or procurement rule strips away status, date and supersession, the single archive is made to look like a single tier of authority. That is not an archive defect. It is an interpretation defect.

Standards authority came from another chain of evidence

RFC 2026 later described the standards process in much greater detail. It still treated the RFC series as the publication channel for standards documents and other material. It labelled Experimental, Informational and Historic as non-standards-track categories, and said that an Informational specification did not represent community consensus or recommendation.

For an Internet Standard, the required evidence was different: technical competence, public review, repeated revision, multiple independent interoperable implementations, operational experience, usefulness, support and formal adoption through the relevant process. Publication was part of the chain, not a substitute for it.

RFC 8729 preserved the architectural idea in a later institutional form. One RFC Series could receive documents through distinct streams with distinct approval processes. Only the IETF stream could approve Standards-Track and Best Current Practice RFCs under that framework. The common publisher and archive did not erase the source of approval.

This separation is useful far outside the RFC Series. A record can establish that something was written. A process record can establish who reviewed or approved it. Tests can establish behavior under named conditions. Deployment evidence can establish that someone actually used it. None should impersonate the others.

Citation needs a status-bearing chain

A defensible reference should preserve at least the RFC number, title, date, status or category relevant to the claim, cited section and any known replacement. If the claim concerns a standard, it should also identify the standards-series or process evidence. If it concerns working behavior, it needs implementation or operational evidence beyond publication.

The same discipline should govern negative conclusions. Informational does not mean technically poor. Experimental does not mean unused. Historic does not erase the document or prove that every mechanism vanished. Standards Track does not certify a product. Each label narrows the claim; none completes every later inquiry.

RFC 825's lasting achievement was not its page width. It was the decision that a common archive must expose difference instead of converting difference into hierarchy by accident. The number preserved where the document lived. Intent told the reader what the document was trying to do. Everything stronger still had to be earned elsewhere.

Sources