要約

  • RFC 1は設計責任を分けていた。BBNがInterface Message Processor（IMP）のソフトウェアを仕様化し、各ホストのチームが自分たちのコンピューターでネットワークを利用するためのソフトウェアを合意する。
  • Steve Crockerは提案を暫定的なものとし、反応を求めた。RFC 3は、文章として公開されるだけで権威ある決定のように受け取られやすいと指摘し、未完成の考えを議論に出すための文書シリーズだと説明した。
  • RFC 6の修正、RFC 11が記録したUCLAのGORDO実装、RFC 33が示す後の改訂は、作業が続いていたことを物語る。全ホストがRFC 1を変更せず採用したことは証明しない。

パケット網の上に、ホスト間の合意が必要だった

初期のARPA Networkには、技術上の明確な境界があった。Bolt, Beranek and Newmanは、拠点間でメッセージを運ぶIMPのソフトウェアを仕様化した。IMPに接続されたコンピューターには、接続の開始、リンクの識別、遠隔ホストから受け取ったデータの扱いを定めるソフトウェア上の約束が別途必要だった。

1969年4月7日付のRFC 1で、Steve Crockerはこのホスト間の問題を共有文書にまとめようとした。IMPのメッセージ形式に触れたうえで、接続要求、テレタイプ端末のようなセッション、大容量ファイル転送、エラー検査、対話操作に必要となるホストソフトウェアを描いた。キー入力のたびにネットワークを往復させず、端末の即時反応を利用者の近くで処理するローカル・フロントエンドの案も検討した。

これは、一つの層で一度だけ決めれば済む問題ではなかった。IMPの転送方法と、ホストOSの振る舞いは、責任も障害の形も異なる。メッセージが相手のIMPに届いても、二つのOSがセッションの開始方法や受信内容の解釈を共有していなければ、利用者間の通信は成立しない。

Crockerの序文は提案の状態を率直に記す。いくつかの暫定合意に至った一方、未解決の問いが残り、ここに書かれた内容の多くは確定していない。この文書の価値は、作業が収束する前の状態を残している点にもある。完成仕様として読めば、記録された不確実性を消してしまう。

最初の文書が提案したこと

RFC 1は、ホスト間の論理リンクを使って通信を組み立てた。OS同士の制御に一つのリンクを確保し、残りを利用者のセッションに使う案を説明している。接続の一つは電話回線につないだテレタイプのように振る舞い、並行するファイル用接続は、端末向けのバッファリングや割り込み処理に頼らず大きなデータを送る構想だった。

ネットワーク遅延があっても遠隔作業を使いやすくする方法も検討した。DELと呼ばれる当時の言語で小さなローカル・フロントエンドを記述し、一般的な端末反応を利用者側で処理する案である。ただし、その仕様はまだ協議中とされ、全ホストに導入済みの機能ではなかった。

最初の実験も範囲が限られている。Crockerは、SRIでの検索システムとDELフロントエンドの作業、UCLAとUtahでNLSを使う計画を記した。これらは参加者が何を作ろうとしていたかを示す。全サイトの導入台帳でも、最初の四つのホストがすべての案を実装したという証拠でもない。

したがって、最初のRFCは標準化機関が発した命令ではない。設計上の選択肢を見える形にし、訂正を促し、離れた場所にいる技術者が具体的な文書をもとに議論するための場だった。

文書シリーズは異論を記録しやすくした

RFC 1の二日後、Bill DuvallがRFC 2を執筆した。タイトルも「Host Software」だった。続くRFC 3は、初期の文書作成ルールを説明する。どのサイトの誰でもノートを出せること、完成度より速報性を優先すること、タイトルは重複してよいこと。通し番号はSRIのBill Duvallが割り当てた。

RFC 3は、技術ガバナンスで今も起こる問題も記録していた。文章にして公表すると、それだけで権威あるものと読まれがちだという。緩やかな形式を設けたのは、まだ権威を持たない考えの交換と議論を促すためだった。番号は文書を探しやすくするが、その問いへの答えを決めるものではない。

これは、完成した標準化手続きを小さくしたものではなかった。初期RFCには提案、質問、実装の詳細、回答の呼びかけが同居している。その共通の価値は、異なるコンピューターとOSを維持しながら相互運用しなければならないサイト間で、技術的な考え方を可視化したことにあった。

改訂と実装は、異なる証拠を与える

Bob Kahnとの会話をCrockerが記録した4月10日付のRFC 6には、Host–IMPのリンク・フィールドを5ビットにし、変換を示すビットを加えた変更が記されている。小さな仕様変更だが、時期が重要だ。RFC 1の公開から数日後にも、その要素は議論され、変更されていた。

8月にはGerard DelocheのRFC 11が、ホスト間の手順とUCLAのSDS Sigma 7用タイムシェアリング・システムGORDOでの実装を説明した。接続の種類、制御メッセージ、チェックサム、バッファ、利用者とIMPインターフェースの間でメッセージを受け渡すプログラムが記録されている。同月のRFC 13はRFC 11を参照し、補助接続でのファイル転送終端を示すゼロ長メッセージを提案した。

ここから分かるのは、考えが名前のある実装で具体化され、特定の課題に応じた追加提案へ進んだことだ。全ホストがGORDOの手順を使ったことや、ネットワークの設計変更が止まったことまでは示さない。実装記録は、あるサイトで案が動いたことを提案書より強く示すが、全体の採用数を補ってはくれない。

RFC 33はその違いを明示する。1970年2月の同文書は、RFC 11の旧プロトコルから多くの変更があり、前年12月のネットワーク会議がその背景にあると記した。添付資料だけではNetwork Control Programを書くのに情報が足りないとも述べ、反応を求めた。実際の接続と利用が始まっていても、ホスト間プロトコルの改訂と文書化は続いていた。

RFC 1の意義は、最終版だったことではない

RFC 1の歴史的な意味は、すべてのフィールドや手順が永続した点にはない。全ホストで実装が固まる前に、共通の設計課題を議論可能にしたことにある。責任範囲を示し、選択肢を出し、不確実性も見えるまま残した。

それはプロトコルの展開とは別の成果だ。文書は共通の問題を定義できる。改訂は意見の隔たりを狭められる。コードは一つのシステムが動くことを示せる。繰り返しの相互接続試験によって、独立したシステムがメッセージを互換的に解釈すると分かる。これらはつながっているが、一つの証拠が次の段階まで証明するわけではない。

初期資料が示す調整の過程は、創業神話より具体的だ。BBNがIMP層を仕様化し、各ホストのグループがその上のソフトウェアを詰め、RFCは番号付きの持ち運べる議論の場を提供した。実装と後続文書が、試された方法と変更点を残した。最初の番号は過程を始めたのであって、終わらせたのではない。

出典

Crockerによる暫定的なホストソフトウェア案の一次資料は RFC 1である。RFC 2にはBill Duvallの「Host Software」が掲載され、RFC 3は初期の文書作成ルールを説明する。RFC 6は後のHost–IMPに関する議論を記録する。DelocheのRFC 11は手順とGORDOの実装を、CerfのRFC 13は補助転送の終端記号案を示す。CrockerらのRFC 33は後の変更と未解決点を記録した。1971年のRFC 170索引には初期ノートの日付が載っている。