要約

  • RFC 818のポート107は、ポート23の一般的なリモートログインとは異なり、次のTelnet接続を開始できるUser Telnetアプリケーションを呼び出すための入口だった。
  • BBNのTC68Kは、受信側Server Telnetを疑似端末経由で送信側User Telnetへ接続した。画面は一つでも、TCP状態、Telnet交渉、障害点は二組残った。
  • 成功した試験が示したのは、その時点の具体的な処理連鎖だった。サービス番号は場所を揃えるが、利用者の本人性、次の宛先への許可、最終処理の完了までは決めない。

接続を始めた側が User になる

TelnetのUserとServerを、利用者と支配者のように読むとRFC 818は理解できない。これらは一つの接続における役割である。受動的に待つプロセスがServerで、通信を開始する側がUserになる。同じホストが別の接続で逆側に立っても矛盾しない。

この柔軟性は1980年のRFC 764に既にあった。Telnetの目的は、単に遠隔シェルを開くことではなく、端末装置と端末指向プロセスを共通方式で結ぶことだった。Network Virtual Terminalは、各ホスト固有のキーボードや表示方式を中間表現へ写す。追加機能はオプションとして交渉し、拒否されれば共通のNVTへ戻る。

物理端末を持つホストが通常Userで、サービスを提供するホストがServerだった。ただし端末間やプロセス間の通信では、開始者をUserと見ることができる。ここでの名称は恒久的な機械分類ではない。

それでも通常の遠隔端末アクセスには明確な慣行があった。Serverはポート23で待ち、接続者をTOPS-20のEXECやUnixのshellのような汎用実行環境へ渡した。接続後に利用者がプログラムを選ぶ構造である。

実行環境のない小さなホスト

1982年11月のRFC 818は、その前提を持たないホストを扱った。小型機器は機能が限られ、汎用executiveを備えないことがある。その場合、存在しないログイン環境を装うより、実際に役立つアプリケーションへ専用のwell-known portを与える方が自然だった。

選ばれたのはRemote User Telnet Serviceである。提供するホストはポート107で接続を受け、受信側ではTelnetを使う。入口の先にあるのは、自ら別のTelnet接続を開始できるUser Telnetだった。

「クライアントが待ち受けた」と短く言うだけでは不正確になる。外側には待ち受けるServer Telnetがあり、内側には送信を開始するUser Telnetがある。ポート107が指定したのは、両者を組み合わせた能力への到達点だった。

番号の共有が決める範囲は狭い。ホストが本当にlistenするか、誰を受け入れるか、内側のUserがどの宛先へ接続できるかはローカルな決定として残る。

TC68Kでは既存コードが先にあった

RFC 818の事例はBBNで動いていたTC68Kである。Motorola MC68000を基盤に、ネットワーク接続を一つ、RS-232端末接続を十六、プログラム可能なタイマーを備えた。Micro-Operating System上でIP、ICMP、TCP、Telnetが動いた。

装置には既にUser TC-Telnetがあった。物理的に接続された端末の利用者が、ネットワーク上のホストへ出ていくためのアプリケーションである。またServer Telnetは、ネットワークを知らないプリンタ、プロッタ、コンピュータを前面に出す役目を持った。

複数の建物に置かれたTC68Kを遠隔試験するため、BBNはServer TelnetとUser Telnetをback to backにした。運用者は対象TC68Kへ接続し、その機器のUser TC-Telnetから見ると、すぐ横の端末に座っているように見えた。既存アプリケーションが持つ統計にも到達できた。

追加されたソフトウェアは、RFCの説明ではPseudo Teletypeドライバだけだった。PTYはアプリケーションには端末として見え、実際には二つのプロセス間で文字ストリームを渡した。

ここで標準化されたのは内部管理機構ではない。既存のTelnetを共有境界に使い、サイト固有の組合せは小さなローカル部品で実現した。文書が現実を作ったのではなく、動く部品がポート107の提案を実体化した。

一つのプロンプトは一つのセッションではない

運用者の画面では、入力と応答が連続して見える。内部では、運用者側User Telnetが第一のTCP接続を開始し、TC68KのServer Telnetが終端する。PTYが文字をローカルUser Telnetへ渡し、そのUserが第二のTCP接続を開始する。

第一の接続で受け入れられたオプションは、第二の接続の同意ではない。外側TCPが文字を受領しても、内側の対象アプリケーションが仕事を終えた証拠にはならない。一方の切断後に、もう一方のプロセスや状態が残る可能性もある。

RFC 818は、オプションを常に変換する方式、二接続を貫く認証、暗号化、全障害の伝播規則を規定していない。PTYはプロセス境界を適合させるが、その境界を消去しない。

1983年のRFC 854は、Telnetの対称性を維持しつつ、それが絶対規則ではなく運用原則だと明記した。各接続は独自のNVTから始まり、独自にオプションを交渉する。同じTC68Kが外側にはServer、内側にはUserであることは、関係が二つある以上当然だった。

試験結果の主語を広げない

RFC 818は、この構成によって二つのTC68K間のネットワーク経路が動作していることを確認でき、標準User TC-Telnetが保持する統計へアクセスできたと述べる。単純な到達性確認より、実際のアプリケーション鎖を多く通る試験だった。

成功時に観測できるのは、ポートへ到達したこと、受信Telnetが十分に処理したこと、PTYが文字を渡したこと、送信Userが対象接続を確立したこと、対象が統計を返したことである。この範囲なら強い証拠になる。

しかし別経路、別時間、別プロトコルまで保証しない。すべてのTelnetオプションが端から端へ保存されたとも言えない。プリンタが実際に印刷した証拠でもない。ソケットの相手だけから人間の権限を確定することもできない。

運用画面が一つであるほど、記録は分解する必要がある。入口の認証、PTY生成、宛先選択、外向き接続、対象サービスの応答を別々の出来事として残す。表示上の近さを証拠上の同一性に変えてはならない。

共通のNVTと役割別の責任

RFC 1123は1989年、Telnetをキーボード／表示装置と遠隔コマンドインタプリタを結ぶ標準プロトコルとして整理した。その一方でUser TelnetとServer Telnetの要件を分けた。未知のオプションは拒否し、交渉が成立しなくてもNVTを支え続ける。制御機能には双方共通の義務と、役割に応じた義務があった。

対称性は責任の無差別化ではない。拒否しても相互運用できる最低状態を共有することだった。そのためローカル実装は新しい組合せを試せた。ポート107を実装しないホストも、将来の提案に従わないという理由だけで無効にはならない。

現在のIANA Service Name and Transport Protocol Port Number Registryには、rtelnet、107、Remote Telnet Serviceが残る。これは参照番号の継続であって、現在の利用量、製品対応、安全性の証明ではない。UDP行があることも、接続上のTelnetを求めたRFC 818をUDPサービスに変えない。

文字の先にある機器状態

1997年の実験的なRFC 2217は、access serverのシリアルポートへTelnetで到達する別の利用を扱った。対象はモデムだけでなく、プリンタ、プロッタ、監視装置などにもなり得た。文字ストリームだけでは不足した。

ボーレート、データビット、パリティ、ストップビット、モデム信号、フロー制御はローカル機器の状態である。COM-PORT-OPTIONは標準Telnet交渉を使って明示的な命令と通知を追加した。

サーバの応答は、命令を処理した後に実際に設定した値を知らせた。TCPのACKは既にバイト到着を示している。ここで必要なのは、受領ではなく適用の証拠だった。要求値と実現値が異なる場合も区別できた。

セッション終了時には遠隔サービスを切断し、シリアル設定を既知の管理値へ戻す必要がある。前の利用者の決定が次の利用者へ無言で持ち越されることを防ぐためである。

RFC 2217をRFC 818の直接の後継と主張する根拠はない。比較の意味は、文字の背後でローカル状態を変えるほど、要求、適用、通知、終了の権限を明示しなければならない点にある。

ポートは役割を見つけるが、役割を支配しない

IANAの登録は共通名を保つ。運用者がlistenを決め、入場制御が主体を扱い、User Telnetがローカル方針の範囲で次の接続を開始し、対象がサービスを実行する。最終的な機器やアプリケーションが完了を示す。

RFC 818が示したのは、少ない共通規則で役割を組み替えられることだった。ポート番号を許可に、PTYを本人性に、接続を完了に読み替えれば、その設計の精密さは失われる。