要約

  • RFC 1096はX-DISPLAY-LOCATIONをTelnetオプション35として定義した。WILL/DOは後の会話を許可するだけで、実際の表示先はSENDへのIS応答として渡された。
  • 値はUnix DISPLAY形式の<host>:<dispnum>[.<screennum>]である。Telnetクライアントは:0のようなローカル表現を書き換える必要があったが、それはホストの認証、所有権、到達性を証明しない。
  • 遠隔アプリケーションは別のX接続を開き、Xサーバー側のアクセス制御と認可を通過しなければならない。場所の受領、setupの受理、利用者が窓を見ることは、それぞれ別の証拠である。

遠隔プロセスに欠けていた座標

利用者はX上のTelnetクライアントから別のホストへ入り、そこでグラフィカルなプログラムを実行する。プロセスは遠隔側にあるのに、表示は利用者のワークステーションへ戻さなければならない。遠隔のshellには、手元のXサーバーを示すDISPLAY値がない場合があった。

1989年3月のProposed StandardであるRFC 1096は、この不足を埋めるためX-DISPLAY-LOCATIONに番号35を割り当てた。Telnetサーバーは、クライアントが動作しているX表示先を問い合わせられる。現在のIANA Telnet Optionsレジストリにも35とRFC 1096の対応は残っている。

ここで運ばれるのは画像でもX要求でもない。既存の接続が、後から別の接続を試すための座標を渡す。利用者には一つの作業に見えても、プロトコル上はTelnetとXの二つの経路がある。

WILLとDOは会話の許可だった

初期状態はWON’T/DON’Tであり、ログインしただけでは表示先を公開しない。RFC 854の語彙に従い、WILLは後で位置を送る用意、DOはそれを受け取る用意を示す。否定形はその役割を断る。

RFC 1096は、WILLとDOが将来の議論について許可を得て与えるためだけに使われると明記する。RFC 855のオプション設計では、まずパラメーターを話題にする合意を作り、その後SBとSEの間で値をやり取りする。二段階は意図的である。

したがって交渉成功が示すのはTelnetの状態だけだ。まだ表示先の正確さも、利用者との関係も、Xサーバーの方針も調べていない。住所を聞く許可と、そこへ入る許可は違う。

SEND/ISには発言順序があった

DOを送った側だけがSENDを発行でき、WILLを送った側だけがISで回答できる。提供側が要求なしに場所を送ることは認められない。合意と値の配送を区別するだけでなく、誰が問い合わせを開始するかも固定していた。

この流れはRFC 1079のTelnet Terminal Speed Optionをほぼ踏襲している。要求された状態文字列をSEND/ISで返す設計を再利用すれば、実装者は既知の状態機械を使える。

ただし、包みが同じでも中身の権限は同じではない。端末速度は一つの接続の属性だが、X表示先は独立したサービスを指す。RFC 1096の例SRI-NIC.ARPA:0.0を受け取った時点で確かなのは、相手がそのNVT ASCII文字列を提示したことだけである。

:0の「ここ」を遠隔地から読める形にする

書式は<host>:<dispnum>[.<screennum>]で、空白などの余分な文字を入れない。ローカルなプログラムなら:0やunix:0.0で十分なことがある。「このホスト」が文脈から分かるためだ。しかし遠隔ホストで同じ表記を読めば、「このホスト」は遠隔側を意味してしまう。

そこでRFC 1096は、Telnetクライアントが送信前に適切な形へ修正するよう求める。これは省略されたスコープを展開する処理であり、身元確認ではない。文書は名前の真正性、DNSの結果、経路、ポート、表示の所有を確認したとは述べていない。

構文が正しくても古い値かもしれず、到達不能かもしれない。到達できてもサーバーが拒否するかもしれない。場所の表現は接続試行を可能にするが、判定を先取りしない。

Xは別の接続として始まった

RFC 1013のX Window System Protocol Version 11では、XクライアントはXサーバーへ独立したIPC接続を確立する。TCPの場合、display Nは6000+N番ポートに対応する。受け取ったhostとdisplay numberは宛先選択に使える。

TelnetのTCPストリームがXへ変身するわけではない。オプション35はトンネルでもプロキシでも転送路でもなく、Xの描画要求を運ばない。遠隔アプリケーションがXクライアントとなり、名前解決、経路、フィルター、listen状態の影響を受ける別の接続を開始する。

この分離は障害解析にも必要だ。IS受領は位置文字列の配送成功を示す。TCPの失敗は後段のネットワークを示し、X setupの拒否はさらに後段の判断である。すべてを「Telnet失敗」と呼ぶと、原因を示す境界が消える。

入場を決めるのはXサーバーだった

Xの接続setupには、バイト順序やプロトコル版とともに、認可プロトコル名と認可データが含まれる。サーバーは理由付きで失敗を返すことも、受理して画面や形式、資源情報を返すこともできる。どの認可方式が有効かはコアプロトコル外の事項とされた。

RFC 1013はホストのアクセス制御リストも別に定義する。X側は自分の規則で接続を拒否できる。TelnetでDO/WILLが成立しても、その規則を通過したことにはならない。

現在のIANA表ではX Display Locationが35、Telnet Authenticationが37である。この現在の分類は35を認証と取り違えないために有用だが、1989年の実装へ後の組合せを投影してはならない。

証拠を順に並べれば誤解は減る。DO/WILLはサブネゴシエーションの許可、SEND/ISは位置の受領、TCP成功はX endpointへの経路、setup受理はXによる接続の受け入れを示す。それでも、目的の窓が作られ利用者に届いたかは観察していない。

人が見る結果は最後に残る

setup後も、アプリケーションは資源を作り、要求を送り、窓をmapしなければならない。正しい画面で使える状態が続き、利用者が実際に認識して初めて、期待した結果について語れる。

分散システムでは、早い成功を最終結論に昇格させやすい。位置を得たから利用可能、接続を得たから機能完了、と短絡する。RFC 1096は一つの仕事だけを担ったため、後続の主張に後続の証拠が必要だと見通しよく示している。

レジストリも導入実績を証明しない。番号と参照先は確認できるが、普及率、特定ホストの挙動、個々の利用者の結果は分からない。公式資料から書けるのは機構と境界の歴史である。

位置情報はTelnetを越えた。だがXを利用する権限は、最後までXの判断だった。

出典