要約

  • RFC 1280はリアルタイムの実装台帳ではなく、定期更新される調整用の記録だった。現行版を探すよう求め、1992年7月31日以降はこの版を使わないよう明記した。
  • STATEは標準化の成熟段階、STATUSは実装の要求水準を示す。どちらも単独では導入や運用の成功を証明しない。

一覧が役立つほど、古くなった一覧は危険にもなる。プロトコルが標準化のどこにいるかを判断する人には、個別のRFCを一つずつ探す代わりに共通の参照先が必要だった。RFC 1280はプロトコルをまとめ、標準化の段階を説明し、実装要求のラベルを添えた。しかし、自らの権威にも期限を設けた。1992年3月版はおよそ四半期ごとの発行を想定し、7月31日を過ぎたら使用しないよう指示している。

これは、8月1日にすべてのプロトコルが変わるという意味ではない。区切られたのは、一覧が裏付けられる時点だ。IABはNetwork Information CenterまたはIANAから最新版を入手し、最近の変更欄を確認するよう求めた。9月にはRFC 1360がRFC 1280を置き換えた。公式の記録も、記載時点では正しく、後の判断には古いことがある。

一覧には二つの座標があった。STATEは仕様の成熟度で、standard、draft standard、proposed standard、experimental、informational、historicを区別する。STATUSはrequired、recommended、elective、limited use、not recommendedという実装要求を表す。提案段階でも実装は任意かもしれず、情報文書が利用を推奨することもある。成熟度は標準化の進み具合、要求水準は特定のシステムに期待される採用の度合いである。

どちらも稼働中の機器を数えたものではなかった。RFC 1280は、IESGの推薦やIABの承認を得ずに広く実装され、重要になったベンダー・プロトコルがあると認めている。逆に「experimental」は研究を記録する区分であり、本番利用の推薦ではない。RFCとして公開されたことも、標準化が進んだことも、普及の証拠にはならない。独立実装、相互運用性、運用実績は別の記録で確かめる必要がある。

参照先の更新時期も揃っていなかった。Assigned Numbers、Gateway Requirements、Host Requirementsはそれぞれ別に改訂され、食い違う場合はより新しい文書を優先するよう定められていた。RFC 1280は各プロトコルの現行仕様を探す案内役だが、関連文書を同時に更新する仕組みではない。RFC 1310が標準化プロセスを説明し、定期的な一覧を仕様状態の公式な記録と位置付けたとしても、その記録には日付と適用範囲がある。過去の一行から現在の動作や導入、サービス応答までは推定できない。

出典：RFC 1280、RFC 1310、RFC 1360。