Summary

  • RFC 1410, the March 1993 edition of the IAB's official protocol standards list, instructed readers not to use that edition after 31 July 1993. A published status table came with its own shelf life.
  • Advancement required an IESG recommendation and IAB ratification. The IAB could return a proposal to the IETF, while minimum waiting periods and implementation evidence stood between each maturity level.

The most arresting instruction in a book of official standards was a deadline for the book itself. The March 1993 RFC 1410 told readers to check whether their copy was current and to stop using that edition after 31 July. The Internet Architecture Board maintained a list of protocol status, but the list was a dated view of a changing process. Its authority was precise enough to include an expiry date.

The process behind the table was more demanding than a name in a column. Most protocol development happened in IETF working groups. A candidate passed through Proposed Standard, Draft Standard and Standard. At each move, the Internet Engineering Steering Group had to recommend advancement and the IAB had to ratify it. If the IAB withheld ratification, the proposal went back to the IETF for further work. The recommendation and the ratification were separate decisions by different bodies.

The guide put time between them too. The IAB imposed at least six months before a Proposed Standard could advance to Draft Standard, then at least four months before a Draft Standard could become a Standard. These were minimum delays for community consideration, not automatic promotion dates. The document separately said that Draft status warned of likely advancement in six months unless major objections or flaws appeared. That expectation did not erase the four-month floor or guarantee a favorable decision.

Paperwork still had to meet running software. As a general IAB practice, a Proposed Standard would not advance to Draft without at least two independent implementations. The move from Draft to Standard generally required operational experience and demonstrated interoperability of two or more implementations. A single enthusiastic implementer could submit a good document; the later maturity claims asked whether separate programs could actually speak the same protocol.

When the correct decision remained uncertain, the IAB could convene experts from the IETF, IRTF and IAB as a special review committee. That panel would recommend an explicit action to the IAB. The route brought more technical judgment into the room while leaving the final ratification step in the stated chain.

The table itself was not a trophy cabinet reserved for winners. The edition kept protocols marked Historic when they had been superseded or were otherwise unused. An asterisk marked a row newly added, moved or otherwise changed from the preceding edition. Those details gave the list two jobs: show the present official classification and expose that classification as something revised over time.

This history has a sharp boundary. RFC 1410 described the March 1993 IAB procedure and list; the RFC Editor record now marks the edition Historic and superseded by RFC 1500. The existing story of RFC 1311 explains why an RFC number and an STD number were different. RFC 1410 supplies another question: who could move a protocol from one status to the next, on what evidence, and before which date could a reader trust the printed answer?

The answer was neither one committee's stamp nor one successful demonstration. The IESG had to recommend, the IAB could send the work back, the clock had to run, and independently built code had to behave together. Then the status list itself had to be replaced. That is a surprisingly candid design for an official document: it carried authority for its moment and told its reader when that moment ended.