要約

  • RFC 1410は1993年３月版のIAB公式プロトコル標準リストで、この版を同年７月31日以降に使わないよう指示した。
  • 成熟度を上げるたびにIESGの勧告とIABの批准が要った。批准されなければIETFへ差し戻され、時間と独立実装の証拠も審査に加わった。

公式一覧に「この版はいつまで」と明記するのは、権威を弱める行為ではない。現実に合わせるための仕組みだ。1993年３月のRFC 1410は、最新版を確かめるよう促し、７月31日を過ぎたらこの版を使わないよう求めた。標準の状態が動くなら、状態を記す紙にも更新期限がある。

一覧の背後では、主にIETFの作業部会がプロトコルを開発していた。候補はProposed Standard、Draft Standard、Standardの順に進む。各段階の昇格には、まずIESGの勧告が必要で、さらにIABが批准しなければならなかった。IABが批准しない場合、作業はIETFへ戻る。会議で支持されたという一つの記録だけでは、次の段階には進めなかった。

時計にも役割があった。ProposedからDraftまで最短６か月、DraftからStandardまで最短４か月の待機をIABが課した。コミュニティーが反応する時間を確保するためである。文書は別に、Draft入りしたものは重大な異議や欠陥が見つからなければ６か月後にStandardへ進む見込みだとも説明する。「見込み」と最短待機期間を混ぜると、誰も保証していない自動昇格を作ってしまう。

実装も単なる添え物ではなかった。IABの一般的な運用では、ProposedからDraftへ進む前に少なくとも二つの独立実装を求めた。最後の昇格には通常、運用経験と、二つ以上の実装間で動作が合うことの実証が必要だった。一人の著者が整った仕様を書いても、別のチームが同じ動きを作れるかは別の試験である。

判断が難しい場合、IABはIETF、IRTF、IABの専門家から特別審査委員会を組み、具体的な対応を勧告させることもできた。リストには、置き換えられたり使われなくなったりしたプロトコルもHistoricとして残り、前版から動いた項目には星印が付いた。公式表そのものが変更履歴を持っていた。

RFC Editorの記録では現在、この版はHistoricで、RFC 1500に置き換えられたと示される。別のRFC 1311記事が扱ったのはRFC番号とSTD番号の違いだ。今回の焦点は、1993年に誰が昇格を止められ、どんな証拠と待機がその判断を支えたかにある。

IESGが推薦し、IABが差し戻せる。独立したプログラムが互いに通信できるか試す。そして公式リストは数か月で自分の役目を終える。紙に権限を与えながら、紙だけに最後まで任せない仕組みだった。