要約

  • Abhay Bhushan の初期FTPは、全ホストに一つのファイルシステムを課すのではなく、異なるシステムに共通の操作面をつくろうとした。
  • ホスト調査と1972年のワークショップは、実装できる共通項と、パス名やアクセス規則のようにローカルに残す領域を切り分けた。
  • 対応できない要求を明示的に断ることは、意味を変えて受理することより強い相互運用性になり得る。

パス名は誰の言葉か

遠隔のファイルを指定する文字列は、中立な住所ではない。そのホストがディレクトリをどう組み、アカウントをどう表し、既定値をどう補い、利用者に何を許すかが折り畳まれている。1971年のARPANETでは、その差が例外ではなく前提だった。

Abhay Bhushan の仕事を「FTPの最初のコマンドをまとめた」とだけ説明すると、この設計上の判断が抜け落ちる。彼が探したのは、性質の異なるホストが無理なく共有できる境界だった。プロトコルは取得や格納という動作を共通化できる。しかし、その動作が向かう対象の名前と権限まで遠隔ホストから奪うことはできない。

Internet Hall of Fame は、Bhushan をFTPの原仕様の著者とし、1967年から1974年までMITのProject MACに在籍し、20本を超えるRFCを著したと紹介している。初期文書を時系列で読むと、肩書き以上に広い役割が見える。彼は仕様を書くだけでなく、要件を集め、会合を開き、合意しなかった事項も記録に残した。

最初の仕様は「調べること」を残した

1971年4月の RFC 114 は、利用者が遠隔ホストを直接扱う場合と、中間プロセスを介する場合を描いた。中間プロセスは遠隔側のコマンドや慣習の一部を隠せる。統一インターフェースの利点はすでに示されていたが、Bhushan は提案を初期段階のものと位置づけ、ネットワーク上のホストについて要件と能力を調査する必要を示した。

順番が重要である。効率、拡張性、適応性、障害からの回復、特定アプリケーションからの独立は、どれも望ましい。だが、望ましさだけで現存するOSの差を消すことはできない。設計者は先に普遍モデルを宣言せず、接続すべき現実を数え始めた。

RFC 180 のファイルシステム質問票は、その作業を具体化した。当時の小委員会は、命名規則やアクセス制御の慣習を標準化しないと明記している。遠隔ホストを使う人は、そのホストの命名法を知る必要があった。Bhushan の依頼を受けたAlex McKenzieは、正当なファイル名、既定値、ディレクトリ操作、アクセス制限、ファイル表現などを各ホストの担当者に尋ねた。

これは仕様作成後の事務ではない。各ホストの内部では当然に見える前提を、比較可能なデータへ変える設計作業だった。違いが見えれば、共通の必須機能にするのか、交渉対象にするのか、対応不能として返すのかを決められる。

採用されなかった案の価値

1972年の RFC 309 は、データ・ファイル転送ワークショップへの参加を広く呼びかけ、意見書を求め、現在と将来の要求に合わせてプロトコルを改める作業時間を設けた。完成案への賛成を集める会ではなく、異なるアプリケーションとホストが初稿に圧力をかける場だった。

RFC 327 の議事記録には、合意できなかった事柄も残る。より多くの構造を共通に扱う「Network Virtual File Image」が議論されたが、結論は出ず、当面は見送られた。代わりに、データの完全性、文字表現と解釈の明確化、可能な範囲での構造情報の維持、将来の仮想ファイルシステムという、段階の異なる目標が整理された。

同時に実行可能な決定もある。コマンドは印字可能な形式とし、制御接続とデータ接続を分離する。基本的な表現形式を必須にする。要求された構造をサーバーが受け入れられないなら、黙って変換せず拒否して利用者に知らせる。Bhushan は議事録と次の草案を担当した。

仮想化案を採用しなかったことは空白ではない。現時点の合意を越えて仕様が権威を装うのを防いだ。未解決の理想を将来に置いたまま、より小さく確かな約束を導入できたのである。

共通の動詞とローカルな名詞

RFC 171 は、アプリケーションごとの機能から一般的なデータ転送を分け、似た仕組みの乱立を抑えようとした。RFC 172 は、ホスト間の差を隠すのは実用上可能な範囲だとし、部分実装や当事者間で合意した拡張を認め、パス名の方式はサイト固有のままにした。

共通化できたのは主として動詞である。取得する、保存する、一覧する。表現、構造、転送モードも制御会話で選べる。だが、動詞が指す名詞は遠隔ホストの言葉で書かれる。区切り、アカウント修飾、世代番号、暗黙のディレクトリは同じとは限らない。誰がその対象に触れられるかも、転送プロトコルではなくホストの規則が決める。

RFC 354 は、この限定された相互運用を明文化した。サーバーはすべての表現、種類、モード、バイトサイズを受け入れる義務を負わない。一方、受け入れられない選択は利用者に伝えなければならない。否定応答が、次の判断に使える情報になる。

理由の分かる拒否なら、クライアントは要求を変えられる。表面上は成功させて意味を変える変換は、問題を発見地点から遠ざける。限界の可視化は不親切ではなく、信頼性を支える機能だった。

統一し過ぎないことで動き始めた

1985年の RFC 959 は、FTPが長い時間をかけて成熟したことを示す。後年の仕様を1971年へ投影すれば、初期設計で何が未決だったかを見失う。草案、調査、公開ワークショップ、範囲を絞った合意、改訂という順序こそが重要である。

小さな共通面は、各ホストが内部モデルを捨てる前に実装を可能にした。その代償として、クライアントは遠隔の命名規則を学び、能力の組み合わせや拡張を扱うことになった。それでも、完全な仮想ファイルシステムを待てば導入は遅れ、あるいは有力ホストの都合が普遍的ルールとして固定されたかもしれない。

パス名は、インターフェースの約束が止まる地点を示す。ネットワークは操作を届けるが、対象を定義し、解釈し、アクセスを許すのは宛先である。Abhay Bhushan が残した教訓は、統一の量ではなく境界の正確さにある。標準は何を共通化するかだけでなく、何を誰の手元に残すかを明言して初めて長く使える。

参照資料