Summary

  • RFC 1011は、仕様文書と状態、注記、依存関係、連絡先を分けて記載し、拡大し続ける技術体系の調整を助けた。
  • 「必須」はホストが実装すべきという期待を示す。各機にどのコードが導入され、動いていたかは示さない。

期限を意識した一覧

Joyce ReynoldsとJon Postelが1987年5月に公表した文書の題名は、Official Internet Protocolsだった。これは状態報告として、インターネットで使われるプロトコルを定義した文書を示し、改訂や変更予定についても注記した。すべての機械の状態を記す総合マニュアルというより、動き続けるシステムを日付付きで描いた地図に近い。

文書そのものが限界を明らかにしていた。読者は直近三か月以内の日付の版を使うよう求められた。各項目には仕様、依存関係、実装上の問題、問い合わせ先が記載される。どの文書がプロトコルを定義するかだけでなく、説明に残る課題や、調整を続ける相手も分かる構成だった。

プロトコルには五つの区分があった。「必須」は全ホストが実装すべきもの。「推奨」は実装を促すもの。「選択」はホストに判断を委ねるもの。「実験」は調整された実験への参加に限るもの。「該当なし」は項目自体がプロトコルではないことを示す。これは異なる期待の表現であって、機械が何を動かしているかを測る五段階ではない。

状態区分だけではソフトウェアは動かない

個々の項目を見れば境界が明確だ。IPは必須、TCPとUDPは推奨だった。「Graphics Protocol」は選択だったが、注記には既知の稼働実装がないとある。その注記は項目を消さず、区分も実装を生み出さない。編者は分類と知識の限界を同じ記録に残した。

ここに大事な区別がある。ある仕様にどの区分が割り当てられたかを正確に記録しても、全ホストの振る舞いまでは証明できない。「必須」は相互運用への期待である。実際の運用を確かめるには、実装と観測が必要になる。RFC 1011には、全ホストの調査も、導入済みバージョンの一覧も、すべての必須プロトコルが正しく稼働していたと示す試験記録もない。

仕様と実装は時間をかけて結びついた

RFC 1011は定期的に更新される報告群の一つだった。以前の版は後続版に置き換えられ、新しい版が一覧を更新した。1989年4月のRFC 1100は、より広い標準化手順を説明している。提案は誰でも提出でき、技術グループは勧告を示し、一般方針としては実装経験が得られてから正式標準にする。RFC番号自体は再利用しないが、プロトコルは改良され、別のRFCで再び文書化されるとも述べた。

だからといって標準文書の意味が薄れるわけではない。共通仕様は独立した実装者に同じ挙動を目指す基準を与える。ただし、提案がサービスになるまでには、公開だけでは足りない。版を実装し、ほかのシステムと試験し、経験に基づき直し、ホストが採用する必要がある。1989年のHost Requirements文書は、汎用インターネットホストに求める内容をさらに具体化した。それでも規範的な言葉が示すのは適合ホストがすべきことだ。稼働中の全機器が実行した証拠ではない。

一覧の更新周期にも意味があった。四半期ごとの報告は運用者と実装者が現行文書を見つける助けになるが、日付も有効性の一部だった。発行時に正しかった行も、仕様、注記、実務が変われば古くなる。旧版を使わないよう警告したのは、調整に保守が要ると認めたからだ。

有用な記録であり、稼働ネットワークではない

RFC 1011は調整の道具として読むのがよい。状態を見えるようにし、文書や担当者へつなぎ、不確実性を隠さず示した。勧告や要件は意思決定に影響し得るので、単なる飾りではない。それでも報告書が各ホストに入り、コードを実行させるわけではなかった。

この境界は今もインターネット史を読む際に役立つ。文書番号は実装ではない。標準の状態はパケットキャプチャではない。勧告は導入数ではない。共通ルールは互換性のある選択肢を絞るが、ネットワークを形づくるのは、運用者が選び、相互運用できる状態に保つシステムである。

出典