要約

  • RFC 1079 の TERMINAL-SPEED は、合意、明示的な要求、端末側からの応答を別々に扱う。
  • 返された文字列はローカルな表示判断の入力になり得るが、ネットワーク経路の事実や TCP・経路制御の権限にはならない。

数字の役目は小さかった

物理端末やモデムの速度は、当時の画面プログラムには実際の問題だった。直接接続された端末のビットレートを保持し、表示遅延用のパディングを調整する OS があり、速い端末と遅い端末では UI を変えるソフトウェアもあった。RFC 1079 が扱ったのはこの端末側の事情である。Telnet に回線調査をさせる提案ではない。

したがって 9600,100 は測定値のように見えても、RFC 1079 では一方のピアが送る NVT ASCII の自己記述である。送信速度と受信速度を十進数とコンマで表しただけだ。パスを探査した結果でも、ルータの観測でも、利用可能容量や次の TCP 配送を約束するものでもない。同じ数字が表示上有用であっても、その数字で接続全体を裁定できるわけではない。

許可と報告を混同しない

RFC 854 の Telnet では、Network Virtual Terminal が共通の土台であり、WILL、WON'T、DO、DON'T が追加の約束を交渉する。RFC 1079 は option 32 の TERMINAL-SPEED にこの文法を使う。

既定は WON'T TERMINAL-SPEED と DON'T TERMINAL-SPEED、すなわち交換なしである。WILL は後のサブネゴシエーションで送る意思、DO は受け取る意思を示すだけで、どちらも速度を含まない。両方が交換された後、DO を送った側だけが IAC SB TERMINAL-SPEED SEND IAC SE で問い合わせることができ、WILL を送った側だけが IAC SB TERMINAL-SPEED IS ... IAC SE で答えられる。応答は自発的に送ってはならない。

実際の値は、先頭ゼロや余分な文字のない二つの十進数をコンマで区切った NVT ASCII である。この狭い形式は相互運用可能な解析を助ける。しかし、端末の物理接続、モデム同期、TCP パス、画面の可読性を証明する形式ではない。形式が正しいことと、世界についての主張が正しいことは別である。

実装の判断はローカルに残る

RFC 1079 は、限られた離散速度しか扱えない実装を想定し、利用可能な値へ安全な方向で近似することを提案する。パディングなら、少なすぎるより多すぎるほうが安全なので切り上げがよい場合がある。この助言は、受け取ったメタデータに対してプログラムが自分の表示をどう選ぶかについてのものだ。回線を変更し、帯域を予約し、ルータを設定し、輻輳を管理せよという命令ではない。

RFC 1079 がモデルとした RFC 930 の端末タイプ選択肢も、許可、SEND、IS を分ける。端末情報の送信は、それ自体で処理変更を意味しない。二つの選択肢は、状態を役に立つ入力として扱いながら、それを全層への命令にしないという同じ節度を示す。

文字列が決められないこと

1200,1200 の受信は、定義された交換である参加者がその文字を送ったことを支えるに過ぎない。端末がその速度で物理接続されていること、モデムが同期していること、TCP に同じ容量があること、パケットが失われないこと、利用者が画面を読んだこと、アプリケーション操作が成功したことは示さない。本人確認、認可、現在の Telnet 利用率の証拠にもならない。

局所属性を数字、数字を測定、測定をネットワーク方針へと膨らませないことが重要だ。RFC 1079 が与えたのは要求された端末メタデータだけである。より大きな結論には別の観測、責任、権限が要る。

出典と証拠の境界

固定した出典は RFC 1079、RFC 854、RFC 930、RFC 1123 である。RFC 1079 は動機、コマンド、既定、構文、実装提案を、RFC 854 は NVT と交渉枠組みを、RFC 930 は歴史的な比較を、RFC 1123 は Telnet 参照内の位置を支える。いずれも現在の導入、特定実装、回線性能、身元、認可、利用結果を支えない。