要約

  • RFC 880の各項目は、状態、定義文書、既知の問題、参考文献、依存先、連絡先を別々に記録し、公式リストへの掲載を万能な保証にしなかった。
  • TCPはRecommendedでも文書上の問題を抱え、TFTPはElectiveでも利用され、GGPはExperimentalでもコア・ゲートウェイで動いていた。
  • 後年、標準化の成熟度と実装要求は別の軸として整備され、定期刊行の総覧はオンライン表に置き換わった。それでも表だけで実行状態は証明できない。

1983年10月のRFC 880 Official Protocols は、きれいな承認済み製品表ではない。ある項目には推奨度があり、その隣に未解決の説明、依存するプロトコル、担当者、場合によっては実際の利用状況が並ぶ。

この構成によって、文書の位置づけと機械の動作が同じ事実に見えるのを防いだ。公式とは、この注釈付き台帳に収録されているという意味だった。安全、適合、導入、稼働までを一括して保証する語ではない。

公式文書は一冊に収まっていなかった

RFC 880は、第一近似として1982年3月のInternet Protocol Transition Workbookを公式プロトコルの基礎とした。しかし、利用中なのに収録されていないプロトコルがあり、収録後に改訂されたものもあった。メール、Telnet、実装者向け情報は別冊に移り、古いオプションは1978年のARPANET手引きに残っていた。

したがって台帳は、単一の永続的な正文を宣言するものではなく、分散した文書群をある時点で照合するものだった。直前のRFC 840も同じ基本形式を持ち、半年後にRFC 880によって廃止された。入れ替わったのは台帳の版であり、全端末のコードではない。

各項目はSTATUS、SPECIFICATION、COMMENTS、OTHER REFERENCES、DEPENDENCIES、CONTACTに分かれる。分類、定義、問題、補足、前提、責任の窓口を別々にしたことで、ひとつの値が他の値を勝手に証明しないようにした。

状態は品質順位ではなく採用条件だった

Requiredは全ホストが実装すべきもの、Recommendedは実装を奨励するもの、Electiveは選択可能なもの、Experimentalは実験参加者が連絡先と調整して扱うもの、Noneはプロトコルではない項目を指した。

IPとICMPはRequired、UDPとTCPはRecommended、TFTPはElective、EGPとGGPはExperimentalだった。Catenet Modelはアーキテクチャ説明なのでNoneだった。

ここに一本の成熟度階段を読むと誤る。Requiredでも特定ホストへの導入を観測したことにはならない。Electiveでも利用者が少ないとは限らない。Experimentalでも運用経路から消えているとは限らない。

RecommendedのTCPには修正点が並んだ

TCP項目はRFC 793を仕様として示し、状態をRecommendedとした。そのCOMMENTSは、多数の訂正が寄せられ、その多くがプロトコル自体より文書の問題だと記した。

イベント処理には明確化が必要だった。Pushはレコード境界のように読める表現を残していた。MSSの既定値、待受サーバー、アイドル接続、クローズ時の未引渡しデータ、順不同セグメント、ユーザー・タイムアウトにも説明不足があった。

推薦と問題一覧は競合しない。推薦は採用方針を調整し、コメントは実装時の不確実性を保存する。Recommendedだけを抜き出すほうが、公式記録を不正確に読むことになる。

Experimentalでもコアで動いていた

EGPは開発中のExperimentalプロトコルだった。GGPもExperimentalだが、当時コア・ゲートウェイで使われていると記された。この一文は台数や稼働率を示さず、相互運用試験でもない。

それでも重要な否定はできる。Experimentalは「実トラフィックなし」という測定結果ではない。制度上の位置と、稼働場所の観測は別だった。

Stream Protocolでは実装が進化し、仕様と一致しない可能性があるとされた。動いていることが適合証明にならない例である。TFTPはElectiveでありながら複数のローカルネットワークで利用中だった。選べることと、選ばれたことも別である。

TelnetのUSE列がオプションの差を残した

Telnet Optionsの表は、RFCやNIC文書の番号、新しい冊子への収録、古い手引きでの位置に加えてUSEを持っていた。Binary Transmission、Echo、Suppress Go Aheadなどは頻繁に実装され、多くの古いオプションは一般利用なしとされた。

オプション群全体はElectiveだったが、RFC 880は各機能の存在をそこから推定しなかった。「Telnet対応」という製品名だけでは、どのオプションを相手が交渉できるか分からない。

USE列は完全な統計ではなく、観測方法や母数も示していない。ただし、文書の存在とは別に動作実態を述べる必要があることは認めていた。

依存先と連絡先が責任範囲を示した

SMTPとTelnetはTCPに、TFTPはUDPに、ゲートウェイ・プロトコルはIPに依存した。上位項目が公式でも、下位の実装と設定が自動的に成立するわけではない。

CONTACTは、実験利用の調整や曖昧な仕様の質問先を示した。ひとりの担当者に全ネットワークを統治する権限を与えるものではなく、分類後にも保守主体が必要だと認める欄だった。

1986年のRFC 991はこの系譜を引き継ぎ、自らを公式ステータス報告と呼んだ。版が続くこと自体、状態には時刻があるという証拠だった。

成熟度と要求度は後に明示的な二軸になった

RFC 1200は1991年、標準化STATEと要求STATUSを分離した。Standard、Draft Standard、Proposed Standard、Experimental、Informational、Historicと、Required、Recommended、Elective、Limited Use、Not Recommendedは異なる分類だった。

RFC 2026は標準化過程と適用範囲を詳しく定め、RFC 6410は後に成熟度を三段階から二段階へ減らした。手続の変更は、導入台数を測る行為ではない。

定期刊行の総覧そのものも鮮度を失った。RFC 7100は2013年、最終版とSTD 1を廃止し、RFC Editorのオンライン一覧へ役割を移した。更新しやすい媒体になっても、一覧は稼働中コードのテレメトリーにはならない。

情報源と限界

根拠はRFC 840、RFC 880、RFC 991、RFC 1200、RFC 2026、RFC 6410、RFC 7100である。現在の導入率、特定製品の適合性、安全性、障害、事業者方針は立証しない。