2. 設計上の諸問題
2A. 基本仮定
Telnet プロセスの機能は、ユーザサイトにある端末を、ネットワーク越しにはサーバサイトに「直接」接続された端末と論理的に等価に見えるようにすることである。この基本機能にはいくつかの含意がある。
i) ユーザは、サーバシステムの端末が生成できるすべてのコードを生成できるようにすべきである。ネットワーク情報センターおよびその他いくつかのサイトに関しては、キー入力の取り決めによって、ユーザが 128 個の ASCII 文字コードすべてをネットワークへの入力として生成できるようにするのが合理的な要件と思われる。文字コードが異なる他のサイトでは、Telnet プロセスがそれらのコードをネットワークに提供することが必要になるかもしれない。
ii) ユーザは、ローカルシステムへエスケープ (escape) して戻れること、あるいはサーバプロセスからサーバシステムへエスケープできることを期待される。
iii) 行単位 (line-at-a-time) システムの Telnet は、文字単位 (character-at-a-time) システムおよび行単位システムと協調動作できること、そして文字単位システムの Telnet は、行単位システムおよび文字単位システムと協調動作できることが望ましい。
2B. エコー制御
Telnet 接続はネットワーク伝送に関していえば実際には全二重 (full duplex) であるため、半二重 (half duplex) や全二重という用語の代わりに、エコー制御 (echo control) という用語を用いる。考慮を要する端末のケースは 3 つある。
- ケース 1 - 文字単位、サーバサイトがエコー
- ケース 2 - 文字単位、ユーザサイトがエコー
- ケース 3 - 行単位、ユーザサイトがエコー
すべての 3 ケースで動作できるサーバサイトもあり得るため、モードを設定する何らかの取り決めが必要である。厳密に言えば、どのキーを叩いたときにどの文字をエコーするかはサーバサイトにとって関知しない事柄であるが、ユーザに見える打ち込み結果の差異はできる限り小さくしたいところである。
2C. 書式制御文字
水平タブ (HT)、垂直タブ (VT)、フォームフィード (FF)、ラインフィード (LF)、キャリッジリターン (CR) という書式制御文字は、上記のケース 2 およびケース 3 において一貫した方法で扱われる必要がある。上記のケース 1 では、状況はより単純である。
2D. ネットワークメッセージ境界
NCP 間プロトコルは、ネットワークメッセージ境界がユーザプロセスから見えないようにするという目標を掲げて規定された。この目標が維持できるのが望ましいが、行単位のシステムの中にはこれが難しいものがあるかもしれない。
2E. 実装上の取り決め
次のような仮定を置けば、上述の問題を解決する取り決めは最も簡単に確立できる。すなわち、サーバサイトが Telnet プロセスから受け取る文字ストリームは、サーバのモニタにおいて「直接」接続された端末からの文字入力が入り込むのと同じ地点に入力され、サーバプロセスからの出力は、通常の文字出力が入り込むモニタ上の地点に入力されると仮定する。サーバの NCP は、通常のモニタ文字出力が取り出される地点で入力を受け取る。言い換えれば、サーバプロセスは NCP バッファから直接入力を得たり NCP バッファへ直接出力したりするのではなく、サーバモニタの文字バッファから入力を取得し、その出力をこれらのバッファへ送ることになる。
一方、Telnet プロセスは、自らのローカル NCP と直接文字ストリームをやり取りすることになる。
両端のユーザプロセスが NCP と直接通信する状況も存在する。したがって、NCP とユーザプロセスとの間の通信については、両方の接続モード (ユーザプロセス-モニタ-NCP、またはユーザプロセス-NCP) を利用可能にすることを勧める。これらのモードは、ユーザプロセスによってプログラム制御下で設定されるものとする。ログイン手続きの間、サーバプロセスが変更するまでの初期のネットワーク上の取り決めとしては、文字をモニタから取得し、文字をモニタへ送るものとする。サーバの NCP もまたモニタと通信する。この方式を図 1 に示す。
このような柔軟性の動機については、以下の議論の中でより明らかになろう。