General Considerations (一般的な考慮事項)

TELNET接続 (TELNET Connection) は、データとTELNET制御情報 (Control Information) が混在して送信される伝送制御プロトコル (TCP, Transmission Control Protocol) 接続です。

TELNETプロトコルは3つの主要なアイデアに基づいて構築されています: 第一に「ネットワーク仮想端末」(Network Virtual Terminal) の概念、第二に交渉されたオプション (Negotiated Options) の原則、第三に端末とプロセスの対称的な視点 (Symmetric View) です。

TELNET接続が最初に確立されたとき、各端は「ネットワーク仮想端末」(Network Virtual Terminal, NVT) で発信および終端すると想定されます。NVTは、標準的なネットワーク全体の正規端末 (Canonical Terminal) の中間表現 (Intermediate Representation) を提供する仮想デバイス (Imaginary Device) です。これにより、「サーバー」(Server) と「ユーザー」(User) ホストが互いの端末の特性と端末処理規約に関する情報を保持する必要がなくなります。ユーザーとサーバーの両方のすべてのホストは、ローカルデバイスの特性と規約をマッピングして、ネットワーク上でNVTを扱っているように見せかけ、各ホストは相手側も同様のマッピングを行っていると想定できます。NVTは、過度に制限的 (ホストがローカル文字セットにマッピングするための十分に豊富な語彙を提供しない) であることと、過度に包括的 (控えめな端末を持つユーザーにペナルティを課す) であることの間のバランスを取ることを意図しています。

注意: 「ユーザー」ホストは、物理端末が通常接続されているホストであり、「サーバー」ホストは通常何らかのサービスを提供しているホストです。別の観点として、端末間またはプロセス間通信でも適用可能ですが、「ユーザー」ホストは通信を開始したホストです。
交渉されたオプションの原則は、多くのホストがNVT内で利用可能なサービスを超えて追加のサービスを提供したいと考え、多くのユーザーが洗練された端末を持ち、最小限ではなく洗練されたサービスを望んでいるという事実を認識しています。TELNETプロトコル内で独立しているが構造化されているのは、さまざまな「オプション」(Options) であり、これらは承認され、「DO, DON'T, WILL, WON'T」構造 (後述) とともに使用されて、ユーザーとサーバーがTELNET接続により精巧な (またはおそらく単に異なる) 規約のセットを使用することに合意できるようにします。このようなオプションには、文字セット (Character Set) の変更、エコーモード (Echo Mode) などが含まれる可能性があります。

オプションの使用を設定するための基本戦略は、いずれかの当事者 (または両方) がオプションを有効にする要求を開始することです。もう一方の当事者は、要求を受け入れるか拒否できます。要求が受け入れられた場合、オプションはすぐに有効になります。拒否された場合、接続の関連する側面はNVTに指定されているままです。明らかに、当事者は常に有効化の要求を拒否することができ、すべての当事者がNVTをサポートする準備をしなければならないため、オプションを無効にする要求を拒否してはなりません (must never)。

オプション交渉の構文は、両当事者が同時にオプションを要求する場合、各当事者が相手の要求を自分の要求への肯定的な確認として見るように設定されています。
交渉構文の対称性は、終了しない確認ループ (Nonterminating Acknowledgment Loops) につながる可能性があります -- 各当事者が着信コマンドを確認ではなく確認されなければならない新しい要求として見ています。このようなループを防ぐために、以下のルールが優先されます:

a. 当事者はオプションステータスの変更のみを要求できます。つまり、当事者は単に自分がどのモードにあるかを発表するために「要求」を送信してはなりません (may not)。

b. 当事者がすでに入っているモードに入る要求のように見えるものを受信した場合、その要求を確認すべきではありません (should not)。この非応答は、交渉での終わりのないループを防ぐために不可欠です。モードが変更されなくても、モード変更の要求には応答を送信することが要求されます (required)。

c. 一方の当事者が第二の当事者にオプションコマンドを送信するときは常に、要求として、または確認として、そしてオプションの使用が最初の当事者から第二の当事者に送信されるデータの処理に何らかの影響を与える場合、コマンドはそれが有効になることが望まれるポイントでデータストリームに挿入されなければなりません (must)。(要求の送信と確認の受信の間に時間が経過することに注意してください。確認は否定的である可能性があります。したがって、ホストはユーザーから「不確実期間」(Uncertainty Period) を隠すために、オプションを要求した後、要求が受け入れられるか拒否されるかを知るまでデータをバッファリングすることを望むかもしれません。)

TELNET接続が最初に確立されたとき、各当事者が相手から可能な限り最高のサービスを得ようとするため、オプション要求が行き来する可能性があります。しかし、それを超えて、オプションは変化する局所条件に合わせて接続の特性を動的に変更するために使用できます。たとえば、NVT (後で説明するように) は、BASIC のような多くの「1行ずつ」(Line at a Time) アプリケーションには適しているが、NLS のような多くの「1文字ずつ」(Character at a Time) アプリケーションにはあまり適していない伝送規律を使用します。サーバーは、ローカルプロセスに適している場合、「1文字ずつ」規律に必要な追加のプロセッサオーバーヘッドを割り当てることを選択し、適切なオプションを交渉する可能性があります。しかし、詳細な制御が不要になったときにNVTに切り替える (つまり、交渉する) ことで、追加の処理オーバーヘッドを永続的に負担することはありません。

プロセスが拒否に対して単にオプションを再要求することで応答する場合、プロセスによって開始された要求は終了しない要求ループを刺激する可能性があります。このようなループが発生するのを防ぐために、何かが変わるまで拒否された要求を繰り返すべきではありません (should not)。操作上、これはプロセスが別のプログラムを実行しているか、ユーザーが別のコマンドを与えたか、または与えられたプロセスと与えられたオプションのコンテキストで意味のあるものであることを意味する可能性があります。経験則として、再要求は接続の他端からの後続情報の結果として、またはローカルな人間の介入によって要求されたときにのみ発生すべきです。

オプション設計者は、オプション交渉に利用可能なやや限定的な構文に制約されていると感じるべきではありません。単純な構文の意図は、オプションを持つことを簡単にすることです -- それらについて無知を公言することが対応して簡単であるためです。特定のオプションが「DO, DON'T, WILL, WON'T」内で可能なものよりも豊富な交渉構造を必要とする場合、適切な方法は「DO, DON'T, WILL, WON'T」を使用して両当事者がオプションを理解していることを確立し、これが達成されると、より複雑な構文を自由に使用できます。たとえば、当事者は行の長さ (Line Length) を変更 (確立) する要求を送信する可能性があります。受け入れられた場合、実際に行の長さを交渉するために異なる構文を使用できます -- このような「サブ交渉」(Sub-Negotiation) には、最小許容、最大許容、希望する行の長さのフィールドが含まれる可能性があります。重要な概念は、このような拡張交渉は、何らかの事前の (標準) 交渉が両当事者が拡張構文を解析できることを確立するまで決して開始すべきではないということです。

要約すると、WILL XXXはいずれかの当事者によって送信され、その当事者がオプションXXXの実行を開始したいという希望 (申し出, Offer) を示し、DO XXXとDON'T XXXがその肯定的および否定的な確認です。同様に、DO XXXは相手側 (つまり、DOの受信者) にオプションXXXの実行を開始することを希望 (要求, Request) することを示すために送信され、WILL XXXとWON'T XXXが肯定的および否定的な確認です。NVTはオプションが有効になっていないときに残るものであるため、DON'TとWON'T応答は接続を両端が処理できる状態に保つことが保証されます。したがって、すべてのホストは、サポートされていないオプションを完全に認識しないTELNETプロセスを実装でき、理解できないオプション要求に対して単に拒否を返す (つまり、拒否する) ことができます。

可能な限り、TELNETプロトコルはサーバー-ユーザー対称的に作成されているため、ユーザー-ユーザー (リンキング, Linking) およびサーバー-サーバー (協力プロセス, Cooperating Processes) のケースを簡単かつ自然にカバーします。オプションがこの意図をさらに進めることが望まれますが、絶対に必要ではありません。いずれにせよ、対称性は鉄則ではなく動作原理であることが明示的に認められています。

新しいオプションを確立する手順に関する情報については、付随文書「TELNETオプション仕様」(TELNET Option Specifications) を参照してください (should)。