Summary

  • RFC 1280 was a public coordination snapshot, not a live inventory: it asked readers to seek the current edition and forbade use of this copy after 31 July 1992.
  • Its STATE described a protocol's standardization maturity; STATUS described how a class of systems was expected to implement it. Neither label alone proved deployment or operational success.

A catalog can become dangerous precisely because it is useful. An operator checking a protocol's place in the Internet standards process needed a common reference, not a pile of isolated RFCs. RFC 1280 tried to supply that reference: it gathered protocol entries, explained the stages of standardization, assigned requirement labels and pointed readers toward documents that governed details. But the memo also printed a stop date on its own authority. The March 1992 edition said it was intended to appear about quarterly and should not be used after 31 July.

That expiry was not a claim that every listed protocol would change on 1 August. It marked the limit of the directory's evidence. The IAB described a living coordination job; readers were told to obtain the current copy from the Network Information Center or IANA and to consult each entry's recent-change notes. RFC 1360, issued in September, later replaced RFC 1280. A standards list could therefore be authoritative as the publication of record and still be wrong for a decision made after its stated horizon.

The inventory also separated two labels that are easy to collapse. STATE meant maturity: standard, draft standard, proposed standard, experimental, informational or historic. STATUS meant requirement level: required, recommended, elective, limited use or not recommended. A proposed-standard protocol could be elective; an informational specification could be recommended for use. One axis described where the specification sat in a process. The other described how strongly a class of systems was expected to implement or use it.

Neither axis was a census. RFC 1280 said a few protocols had become widely implemented without IESG recommendation or IAB ratification, including vendor protocols important to the community. Conversely, the “experimental” label documented research rather than endorsing operational deployment. The list warned readers not to infer adoption from publication status—or popularity from a standards-track label. Implementation evidence, interoperability tests and operational experience belonged to other records.

The memo also warned that neighboring references did not update together. Assigned Numbers, Gateway Requirements and Host Requirements were revised on different schedules; where they differed, the most recent document was to prevail. RFC 1280 identified itself as the guide to the current RFC for each protocol, not as a frozen replacement for every underlying specification. The directory organized evidence, but it did not make that evidence simultaneous.

This is the more durable lesson than any individual row in the 1992 tables: a status label needs an object, a meaning and a date. RFC 1310 described the standards process and called the periodic standards RFC the authoritative statement for a particular specification. RFC 1280 supplied that snapshot while naming its expiration. A historic directory entry can explain what the IAB recorded then; it cannot establish what a protocol does now, what operators installed, or whether a service worked.

Sources: RFC 1280; RFC 1310; RFC 1360.