要約

  • RFC 1073では、クライアントが文字単位の幅と高さを一組で通知し、ローカルのウィンドウが変われば再通知できた。サーバーはNAWSに同意しても値を使わずに済み、後から更新を止めることもできた。
  • DO/WILLはオプションを話す許可、NAWSはクライアントが述べた幾何情報である。サーバー側の端末状態、子プロセスへの合図、アプリケーションの再整形、人が見た結果までは証明しない。

Telnetの基本仕様が定めたNVTには、プリンター幅もページ長も決まっていなかった。最低限の仮想端末を共有することで、異なる機械は互いのローカル事情を抱え込まずに通信できた。しかしグラフィカルなワークステーションが普及すると、Telnetクライアントは固定端末ではなく、セッション中にも形を変える窓の中で動くようになった。

RFC 1073はオプション31をNAWS、Negotiate About Window Sizeとした。設計の焦点は、単により大きな数を送ることではない。窓の大きさを誰が決めるのかを正した。クライアントは自分の窓を全面的に制御し、現在値をサーバーへ知らせる。サーバーはその会話を受け入れるか、値を利用するかを自分で決める。

交渉状態と寸法状態は同じではない

サーバーはDO NAWSで利用を求め、クライアントはWILL NAWSで応じられる。DON'TとWON'Tなら拒否である。RFC 855が示したTelnetオプションの枠組みでは、この段階は双方が拡張構文を理解することを確認する入口だった。詳細な値は、その後のサブネゴシエーションが運ぶ。

したがってDO/WILLを観測しても、幅と高さが送信されたとは限らない。NAWSを受信しても、サーバーが保存したとは限らない。保存されても、端末ドライバー、子プロセス、アプリケーションの順に状態が伝わったとは限らない。許可を結果として扱うと、最初の境界で証拠を過大評価する。

NAWSのデータは幅2オクテットと高さ2オクテットで、Internet標準の順序を用い、単位は文字だった。各軸は65,535まで表現できる。Telnetでは255がIACなので、データ中の255は二重にする必要がある。受信バイト列から論理的な4オクテットを得るには、サブネゴシエーションの境界とエスケープを正しく処理しなければならない。

ゼロはゼロ幅の窓ではない。その軸を送っていないという意味である。サーバーはOS固有の仮定を使え、別途得た端末タイプを手掛かりにすることもできた。ここでゼロを実寸として保存すれば、仕様が残した「不明」を偽の精度に変えてしまう。

80×64は80×24への返事ではなかった

RFCの例では、クライアントが最初に80×24を送り、ユーザーが窓を変えた後に80×64を送る。二度目のDO/WILLはない。ローカル状態が変わったため、既に許可されたオプションで新しい世代を通知したのである。

二つ目の値は、一つ目が適用されたという確認ではない。NAWSには、子プロセスが再描画を終えたことを返す応答もない。ローカル窓の変更時刻、サーバー到着時刻、端末状態の更新時刻、アプリケーションが新しい寸法を読んだ時刻はずれ得る。「現在のウィンドウサイズ」と言うなら、どの主体の、どの時点の値かを付けなければならない。

RFC 1073は情報を明記して「advisory」と呼んだ。サーバーはオプションを受け入れながら値を使わなくてもよい。当時の一部OSはセッション途中の寸法更新ができなかった。その場合、最初に同意したサーバーが後からDON'T NAWSを送り、以後の通知を禁じられる。ローカル窓は変化し続けても、遠隔側は聞くことをやめられた。

この非対称性は欠陥ではない。窓という事実はクライアントに属し、受信と利用の判断はサーバーに属する。

古い方式は権限の向きを誤っていた

先行するNAOLとNAOPは、出力行幅とページサイズを別々に交渉した。RFC 1073は、グラフィカルな窓には意味が合わないとした。双方向だったため、サーバーがクライアントの幅や高さを制御するようにも読めたうえ、各軸は253に限られ、当時広く使われていなかった。

NAWSは二軸を同時に送った。窓は通常、幅と高さが一緒に変わるからだ。さらに重要なのは、ローカル状態を双方の交渉対象にしなかった点である。サーバーはNAWSを求められるが、NAWSでクライアントの窓を変更することはできない。

値は文字セルであり、ピクセルでも物理的な画面寸法でもない。RFCの300×24という例は300列の文字領域を表す。フォント、拡大率、モニター幅を推定する根拠にはならない。

タイプ、速度、幾何は別々の状態だった

RFC 930のTERMINAL-TYPEはサーバーが問い合わせ、クライアントが名前を答える。名前を受け取っても、直ちに処理を変える義務はなかった。RFC 1091は複数のエミュレーションモードを順に提示できるようにしたが、問い合わせの主導権はサーバーに残った。

RFC 1079のオプション32は端末速度を扱う。許可後に要求側が送受信速度のASCII文字列を求め、提供側は自発的に送れない。対応しない速度を安全側へ丸める場合もあった。NAWSは違う。許可後はクライアントが各リサイズを自ら通知でき、データは二つのバイナリ軸だった。

NAWSがゼロを送った軸について、端末タイプが既定値選択の参考になることはある。それでもタイプは現在の幾何を測らない。速度も列数ではない。属性を一つの「端末情報」に溶かさず、別々の由来と更新規則を持たせたことが、判断の根拠を明確にした。

IANAのTelnet Options登録簿では、31がNAWS、32がTERMINAL-SPEEDである。登録は番号と参照文書を証明するが、現在の実装、利用、準拠や個別セッションの挙動は証明しない。

4オクテットの先にローカルな判断が続いた

RFCの実装例は、窓システムからアプリケーションまでを一気に成功扱いしていない。グラフィカル環境がTelnetクライアントへ変更を伝える。4.3BSDならクライアントはSIGWINCHを捕捉し得る。NAWSを送る。サーバーはioctlで端末状態を変え、子プロセス――おそらくシェル――へ信号を送るかもしれない。

窓管理、Telnetクライアント、ネットワーク解析、サーバー端末層、子プロセスは別の所有者である。正しいNAWSはioctl成功を保証せず、更新された端末状態は信号配送を保証せず、信号配送はアプリケーションの処理順を保証しない。整った出力も、人がそれを見た証拠にはならない。

表示崩れの調査では、リサイズイベント、NAWSの生データ、255の処理、サーバー保存値、子への信号、アプリケーションが参照した世代を照合する必要がある。「resize OK」という一つの欄では、どこで古くなったか分からない。

出典と限界

RFC 1073は1988年の提案とCarnegie-Mellonでの当時の利用例を記すが、一般普及を測定していない。RFC 854と855はTelnetの枠組み、RFC 930、1079、1091は隣接する属性交換を示す。いずれも特定のNAWS適用や現行製品の挙動を証明しない。

SSHの疑似端末、レスポンシブWeb、遠隔デスクトップへの直接の系譜を主張する必要もない。歴史的な成果は十分に限定できる。NAWSは変わるローカル状態を持ち運べるようにしながら、その通知を遠隔命令にはしなかった。