要約

  • RFC 854では端末の振る舞いを交渉できる。どちらの端もオプションを要求し、相手は受諾も拒否もできた。
  • Network Virtual Terminalが共通の戻り先として残るため、機能差があっても最低限の接続規約を保てた。

分析

遠隔端末の接続では、異なるキーボード、画面、操作方法を前提にした機械が向き合う。ネットワークがバイトを運んでも、各機器のローカルな違いは消えない。TELNETは共通の出発点を定め、そこからの変更を両端で交渉する方式を採った。

その方式が長く使われる形になったのは1983年5月だ。Jon PostelとJoyce Reynoldsは、先行するRFC 764を置き換えるRFC 854を公表した。TELNETは利用者側の端末システムと遠隔サーバーを結ぶ、双方向・8ビットバイト指向の通信手段として定義された。中心に置かれたNetwork Virtual Terminal（NVT）は、異なるホスト同士が特殊な機能を決める前に、基本セッションを始めるための共通規約だった。

NVTは下限であり、端末が同一だという主張ではない。RFC 854は双方のどちらからでもオプションを要求できるようにした。四つのコマンドで責任の向きを分ける。DOは相手にオプションの実行を求め、WILLは自分が実行すると伝える。DONTとWONTはそれぞれ要求や応答を取り下げる。拒否された場合、その部分はNVTの規約に戻る。接続を切らずに「できない」と答えられた。

オプションは接続全体の一括スイッチではないので、この区別が重要だった。通信方向ごとに状態は異なり得る。一方が文字のエコーを引き受けても、もう一方は断れる。片側がバイナリー転送を求め、相手は既定の扱いを続けることもできる。RFC 856のバイナリー転送、RFC 857のエコー、RFC 858のSuppress Go Aheadは、共通ストリームの周囲で変更を交渉する例だ。RFC 855はオプションのコマンド、既定値、動機を記録するよう求め、提案・試験・廃止の余地を残した。RFC 880はTELNETのオプションを選択的機能として掲げている。

対称な仕組みには落とし穴もあった。双方が確認を新しい要求と誤解すれば、応答が終わらない。RFC 854はその循環を防ぐ規則を置いた。ホストは現在の状態を知らせるためだけに要求してはならず、すでに有効なモードへの要求には再応答しない。双方の同時要求は互いへの肯定確認になり得る。無効化の要求は拒めない。両端がNVTに戻れることが前提だからだ。

ここでは制御の所在が明瞭だ。規格が共通のバイト語彙とフォールバックを定め、各実装は自分が任意機能を提供できるかを決める。相互運用性は全機能がどこでも動くという想定ではなく、両端が合意した共通部分から生まれる。

後年の記録は、成功を限定して読む必要も示す。1989年のRFC 1123は、交渉機構の実装、未対応オプションの拒否、接続中の交渉継続、失敗時のNVT対応をホストに求めた。同時に、行末の扱いなど残る曖昧さを記録した。1990年のRFC 1143は交渉状態を実装するための体系的なQ方式を示す。共通の戻り先や循環防止があっても、実装差や端末間の不整合はなくならなかった。

RFC 854の成果は「一つの規格ですべての端末が互換になった」ことではない。異なるシステムが何なら一緒にできるかを、規律ある手順で確かめられるようにした。基準は拒否を可能にし、交渉は拡張を可能にする。その境界は通信上で確認できた。

出典