3. 提案する Telnet の取り決め
3A.
サーバサイトは初期状態として、明示的に指示されない限り、エコーはユーザサイトのプロセスが行うものと仮定すること。ユーザサイトが文字単位で送信できる場合、接続とログインが確立された後、ユーザはサーバサイトへのコマンドによってサーバサイトエコー (server-site-echo) へ切り替え、その後 (サーバサイトには見えないように) ローカルの Telnet にコマンドを送って、そちらのエコーモードも変更することができる。
3B.
サーバプロセスは、「直接」接続された端末が生成できるのと同じ文字セットを受け取るものと仮定すること。(最低でも 128 文字の ASCII を勧める。) ユーザの Telnet は、大文字・小文字のコードおよび制御コードの両方を生成できるようにするため、2 文字のシーケンスを認識しなければならないかもしれない。単一の文字サイズしか持たない端末のために、ユーザが大文字または小文字のいずれかをデフォルトのサイズとして設定でき、さらにサイズ切り替え文字 (case shift character) を指定できるようにすることを勧める。また、ユーザが、直後に叩く文字を対応する制御文字コードへ変換することを指示するための文字を指定できることも望ましい。後者の取り決めにより、端末で直接生成された制御コードがユーザシステムに認識され、ユーザシステムへのエスケープが可能になる。すべての制御コードがネットワークに入ること、そしてネットワークからの出力がサーバプロセスに入る前にサーバのモニタへ流れ込むことを許す取り決めを作れば、多くの既存システムへのエスケープを生成する簡単なメカニズムが得られる。(システムによっては問題はこれよりも複雑であり、後述する。)
3C.
HT、VT、FF のローカルエコーの意味についてネットワーク標準を確立するか、あるいはこれらの文字の意味をサーバプロセスへ送るための取り決めを確立することを勧める。たとえば NLS(NIC) はプリントヘッドの位置を追跡する必要があり、そのような取り決めがない場合、これらの文字コードを空白とラインフィードに変換してしまう。これは、出力時のページの見た目が入力時の見た目と異なる可能性があることを意味する。出力時のページが入力時の通りに整形されれば、ユーザにとって有用であろう。
3D.
LF 文字は、「直接」サーバシステムに接続された端末でラインフィードキーが叩かれた場合と同様に扱われること。
3E.
キャリッジリターン (CR) 文字は、かなり厄介な問題の源となり得る。たとえば入力時に、異なるシステムや、同一システムでも時点によって、端末やユーザプロセスに対して異なるコードをエコーしたり伝送したりしうる。モニタシステムの中には、何もエコーしないもの、CR のみをエコーするもの、CRLF をエコーするものがある。ユーザプロセスに対しては、CR、CRLF、または行末コード (end of line, EOL) を伝送するシステムもある。ユーザプロセスはエコーを制御したり、エコーに付け加えたりすることもある。ネットワーク接続の各端で存在しうる組み合わせ、およびそれらの相互関係を考えると、2A の定義と 2E の実装上の取り決めを仮定しない限り、混乱が生じうる。これらの仮定が意味するのは、CR が叩かれたときには、ネットワーク上には CR が 1 つ送られるということである。ユーザのモニタシステムや端末制御ハードウェアが CR を CRLF や EOL に変換する場合は、Telnet プログラムがそれを CR に戻さなければならない。CR がサーバのモニタに到達すれば、モニタがサーバプロセスのために適切に処理する。
エコーがサーバシステムによって処理される場合は、正しいコード (またはコード群) がエコーされる。ユーザの Telnet は、CRLF を受信した際に、特定の端末のキャリッジ移動のタイミングに対応できるよう、適切なヌル文字 (null) でパディングできる。
エコーがユーザシステムによって処理される場合は、ユーザの Telnet やシステムがサーバシステムと同じエコーの取り決めを用いるのが理想的である。これは、Telnet が接続しうる各種システムのエコー取り決めの表を持つか、サーバシステムやサーバプロセスからこの情報を取得できるか、あるいはその逆が可能であるかのいずれかを意味する。
初期の Telnet プロトコルとしては、これはおそらく必要ない。ユーザシステムはデフォルトの動作として、受信した CR ごとに CRLF をエコーすればよい。このデフォルトは、われわれの知るすべての状況および NIC に対して満足のいくものであるはずだ。
3F.
文字単位システムおよび行単位システムとの通信のために、Telnet プロセスは (ユーザが割り当て可能な) ある文字を認識する必要があるかもしれない。われわれはこれをストリーム終端 (end of stream, EOS) と呼ぶ。この文字は、以下の議論で定義する機能を持つものである。重要なのは、ネットワーク機能としてのストリーム終端 (end-of-stream) と、ユーザまたはサーバシステムの機能としての行末 (end-of-line) を区別することである。まず行単位システムを考えよう。われわれは行単位システムの経験が乏しいため、以下はさらなる研究と明確化を要する。われわれの理解では、行単位システムは、CR のような文字やブレーク信号を、ユーザプロセスを起こして 1 行のテキストを伝送させるコードとして認識する。NLS(NIC) の観点から重要なのは、ユーザが適切な場合には CR で終端されたテキスト行を入力でき、それ以外の場合には CR で終端されないテキストを入力できることである。(NLS(NIC) におけるステートメントは長さが「任意」の文字列であり、CR を含む必要はない。出力時には、行はユーザの (ユーザが定義可能な) ページ境界で折り返される。)
要求されるものの一例として、ユーザシステムが CR を行末として認識する場合を考えよう。この場合、Telnet は CR を受信したときに起こされる。この場合、CR コードはそのまま Telnet の出力バッファに入れられることを勧める。CR の前に EOS 文字がある場合は、CR を Telnet の出力バッファに入れるべきではない。ネットワークを通じた伝送は、EOS を受信したとき、あるいは Telnet の出力バッファが満杯になったときに自動的に行われる。行単位システムから文字単位システムへの伝送では、1 文字をネットワークに通すのに 3 つのキーを叩くという不格好な操作が必要になりうる。
次に、文字単位システムから行単位のサーバシステムへの伝送を考えよう。記述しようとしている問題と同様の問題が、行単位システム間にも存在する。CR とは異なる EOS 文字の定義があれば、1 行分の内容は EOS を受信するまでバッファリングされ、EOS を付けずに送信できる。サービスを提供するシステムは、行が送られたことをどうやって知ればよいのか。1 つの方法は、サービスを提供する側の NCP がメッセージ境界を認識することである。しかしこの取り決めは設計目標の一つに反する。もう 1 つの方法は、ユーザの Telnet が自らの NCP に INS コマンドの送信を要求することである。INS タイプの制御コマンドの送信はネットワークに競合状態 (race conditions) を持ち込みうるため、Telnet プロセスでの利用を確定する前に研究されるべきである。われわれの知る行単位システムの中には行末信号を認識する専用ハードウェアを持つものがあるため、ソフトウェアの制御信号によってこのハードウェアと互換性を保つ何らかの方法が必要である。この問題は NWG 小委員会でのさらなる研究に委ねる。
3G.
さて、リモートのサーバシステムにおける割り込みやエスケープの問題に戻ろう。出力中に入力キーボードをロックアウトしないシステムでは、上述のメカニズムと取り決めは十分と思われる。ただし、エスケープ信号が特殊なブレーク信号 (break signal) である場合は別であり、この後者の場合はさらなる研究を要する。出力が行われている間は入力を許さないシステムでは、そのような端末の使用形態の結果を受け入れ、エスケープコードを送れるようになるまで出力が止まるのを待つ覚悟が必要かもしれない。キーボードがロックされていてもユーザのシステムへエスケープ用のブレーク信号を送れる場合は、それによって出力が端末へ届くのを防ぐことはできるが、ユーザが Telnet プロセスに指示してサーバサイトへ割り込みまたはエスケープ信号を送れるようになるまで、サーバサイトからの出力を受け取り続ける覚悟がなければならない。これもさらなる研究を要する問題である。
ネットワーク情報センターのオンラインシステム (Online System) は文字単位のモニタシステム上で稼働しており、本書で確立した取り決めはそのアクセスに対して十分である。これらの取り決めは附属書 A にまとめられている。