3. Remote Login - TELNET Protocol (リモートログイン - TELNETプロトコル)
3.1 INTRODUCTION (はじめに)
Telnetは、リモートログインのための標準的なインターネットアプリケーションプロトコルです。これは、クライアント（「ユーザー」）システム上のユーザーのキーボード/ディスプレイをリモートサーバーシステム上のコマンドインタープリターとリンクするためのエンコーディングルールを提供します。Telnetプロトコルのサブセットは、FTPやSMTPなど、他のアプリケーションプロトコル内にも組み込まれています。
Telnetは単一のTCP接続を使用し、その通常のデータストリーム（「ネットワーク仮想端末」または「NVT」モード）は、制御機能を埋め込むためのエスケープシーケンスを持つ7ビットASCIIです。Telnetはまた、多くのオプションモードと機能のネゴシエーションを許可します。
主要なTelnet仕様はRFC-854 [TELNET:1]にあり、オプションは他の多くのRFCで定義されています。参照についてはセクション7を参照してください。
3.2 PROTOCOL WALK-THROUGH (プロトコルの詳細)
3.2.1 Option Negotiation: RFC-854, pp. 2-3 (オプションネゴシエーション)
すべてのTelnet実装は、オプションネゴシエーションとサブネゴシエーションの機構を含まなければなりません (MUST) [TELNET:2]。
ホストは、オプションネゴシエーションループを回避するために、RFC-854のルールを注意深く従わなければなりません (MUST)。ホストは、サポートされていないオプションを拒否しなければなりません (MUST)（つまり、DO/WILLにWONT/DONTで応答する）。オプションネゴシエーションは、Telnet接続の存続期間中、（すべてのリクエストが拒否された場合でも）機能し続けるべきです (SHOULD)。
すべてのオプションネゴシエーションが失敗した場合、Telnet実装はNVTにデフォルト設定し、サポートしなければなりません (MUST)。
議論 (DISCUSSION):
より洗練された「端末」とサポートオプションネゴシエーションが標準になりつつありますが、すべての実装は、あらゆるユーザー-サーバー通信のためにNVTをサポートする準備ができていなければなりません。
3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 (Telnet Go-Ahead機能)
Telnetコマンドgo Ahead (GA)を送信しないホストでは、TelnetサーバーはSuppress Go Aheadオプションをネゴシエートしようと試みなければなりません (MUST)（つまり、「WILL Suppress Go Ahead」を送信する）。ユーザーまたはサーバーTelnetは、Suppress Go Aheadオプションのネゴシエーションを常に受け入れなければなりません (MUST)。
GAが意味を持たない全二重端末を駆動している場合、ユーザーTelnet実装はGAコマンドを無視してもよいです (MAY)。
議論 (DISCUSSION):
Go-Aheadメカニズムが設計された半二重（「ロックキーボード」）の行単位端末は、シーンからほとんど消えました。多くのオペレーティングシステムで、ネイティブの半二重端末をサポートする一部のシステムでも、Go-Ahead信号の送信を実装することは困難であることが判明しました。困難は通常、Telnetサーバーコードが、ユーザープロセスがTelnet接続からの入力を待ってブロックされているかどうかに関する情報にアクセスできないことです。つまり、GAコマンドをいつ送信するかを確実に判断できません。したがって、ほとんどのTelnetサーバーホストはGAコマンドを送信しません。
このセクションのルールの効果は、Telnet接続のいずれかの端がGAコマンドの使用を拒否できるようにすることです。
まだ商業的に重要な半二重端末のクラスがあります：全画面方式で対話する「データエントリ端末」です。ただし、Telnetプロトコルを使用してデータエントリ端末をサポートする場合、Go-Ahead信号は必要ありません。セクション3.3.2を参照してください。
3.2.3 Control Functions: RFC-854, pp. 7-8 (制御機能)
Telnetコマンドのリストは、コード239のEOR（End-of-Record）を含むように拡張されました [TELNET:9]。
ユーザーTelnetとサーバーTelnetの両方は、制御機能EOR、EC、EL、およびBreakをサポートしてもよく (MAY)、AO、AYT、DM、IP、NOP、SB、およびSEをサポートしなければなりません (MUST)。
ホストは、サポートしていないTelnet制御機能を受信して無視できなければなりません (MUST)。
議論 (DISCUSSION):
サーバーTelnetは、サーバーホストに同等のストリーム内機能（多くのシステムでControl-Cなど）がある場合でも、Telnet IP（Interrupt Process）機能をサポートする必要があることに注意してください。Telnet IP機能は、TCPの緊急データの帯域外効果のため、ストリーム内割り込みコマンドよりも強力である可能性があります。
EOR制御機能は、ストリームを区切るために使用できます。重要なアプリケーションは、データエントリ端末のサポートです（セクション3.3.2を参照）。EORがRFC-854で定義されていなかったため、未知のTelnetコマンドを正しく無視する準備ができていないホストがEORを受信するとクラッシュする可能性があるという懸念がありました。そのようなホストを保護するために、End-of-Recordオプション [TELNET:9]が導入されました。ただし、適切に実装されたTelnetプログラムは、この保護を必要としません。
3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10 (Telnet「同期」信号)
「緊急」TCPデータを受信すると、ユーザーまたはサーバーTelnetは、DM（および緊急の終了）に達するまで、Telnetコマンドを除くすべてのデータを破棄しなければなりません (MUST)。
Telnet IP（Interrupt Process）を送信する場合、ユーザーTelnetはその後にTelnet「同期」シーケンスを続けるべきです (SHOULD)。つまり、TCP緊急データとしてシーケンス「IAC IP IAC DM」を送信します。TCP緊急ポインターはDMオクテットを指します。
Telnet IPコマンドを受信すると、サーバーTelnetは出力ストリームをフラッシュするために、ユーザーに戻ってTelnet「同期」シーケンスを送信してもよいです (MAY)。選択は、ローカルユーザーがプロセスを中断したときにサーバーオペレーティングシステムがどのように動作するかと一致するべきです。
Telnet AOコマンドを受信すると、サーバーTelnetは出力ストリームをフラッシュするために、ユーザーに戻ってTelnet「同期」シーケンスを送信しなければなりません (MUST)。
ユーザーTelnetは、Telnet IPを送信するときに出力をフラッシュする機能を持つべきです (SHOULD)。セクション3.4.5も参照してください。
議論 (DISCUSSION):
ユーザーTelnetがサーバー出力データのストリームをフラッシュする方法は3つあります：
(1) IPの後にAOを送信する。
これにより、サーバーホストはそのオペレーティングシステムに「バッファされた出力をフラッシュ」信号を送信します。ただし、AOはローカルで有効にならない可能性があります。つまり、サーバーTelnetがAOを受信して処理し、「同期」を送り返すまで、ユーザーTelnet側で端末出力を停止しません。
(2) IPの後にDO TIMING-MARK [TELNET:7]を送信し、サーバーTelnetからWILL/WONT TIMING-MARKを受信するまで、ローカルですべての出力を破棄します。
DO TIMING-MARKはサーバーでIPの後に処理されるため、それに対する応答は出力データストリームの正しい位置にあるはずです。ただし、TIMING-MARKはサーバーオペレーティングシステムに「バッファされた出力をフラッシュ」信号を送信しません。これが必要かどうかは、サーバーシステムに依存します。
(3) 両方を行う。
最良の方法は完全には明確ではありません。なぜなら、さまざまな方法でTelnet標準に従わない多数の既存のサーバーホストに対応する必要があるためです。最も安全なアプローチは、おそらく(1)、(2)、または(3)を選択するためのユーザー制御可能なオプションを提供することです。
3.2.5 NVT Printer and Keyboard: RFC-854, p. 11 (NVTプリンターとキーボード)
NVTモードでは、Telnetは上位ビットが1の文字を送信すべきではなく (SHOULD NOT)、パリティビットとして送信してはなりません (MUST NOT)。上位ビットをアプリケーションに渡す実装は、バイナリモードをネゴシエートすべきです (SHOULD)（セクション3.2.6を参照）。
議論 (DISCUSSION):
実装者は、RFC-854の厳密な読み方では、NVT ASCIIを期待するクライアントまたはサーバーが上位ビットが設定された文字を無視できることに注意する必要があります。一般的に、バイナリモードは、Telnetで拡張（7ビットを超える）文字セットの送信に使用されることが期待されています。
3.2.6 Telnet Command Structure: RFC-854, p. 12 (Telnetコマンド構造)
Telnetコマンドコードの最近の拡張は、TN3270拡張機能の一部として、End-of-Record (EOR - コード239)を追加しました [TELNET:9]。
3.2.7 Telnet Binary Option: RFC-856 (Telnetバイナリオプション)
ホストがバイナリモードをネゴシエートする場合、データストリーム内のTelnetコマンドを識別するために、IAC文字（255）を2倍にしなければなりません (MUST)。
データパスを変更せずにバイナリオプションをネゴシエートできることが重要です。これが不可能な場合、実装はバイナリオプションを拒否すべきです。
議論 (DISCUSSION):
バイナリオプションをオンにすると、すべてのオクテット値が透過的になります。したがって、Telnetは255の値を持つデータオクテットをTelnetコマンドと区別できなければなりません。これは、IAC（255）の2倍化によって行われます。
バイナリモードの実装には注意が必要です。一部のシステムでは、バイナリデータを通過させながら、バンド内Telnet制御文字（特にInterrupt Process）を認識する必要があります。
3.2.8 Telnet Terminal-Type Option: RFC-1091 (Telnet端末タイプオプション)
実装は、端末タイプオプション [TELNET:10]をサポートすべきです (SHOULD)。
議論 (DISCUSSION):
端末タイプオプションにより、サーバーはユーザーの端末タイプを決定できます。
(以下続く...)
3.3 SPECIFIC ISSUES (個別の問題)
3.3.1 Telnet End-of-Line Convention (Telnet行末規則)
Telnetプロトコルは、「行末」を意味するシーケンスCR LFを定義しています。端末入力の場合、これはユーザー端末で押されるコマンド完了または「行末」キーに対応します。ASCII端末では、これはCRキーですが、「Return」または「Enter」とラベル付けされることもあります。
サーバーTelnetがリモート端末からの入力としてTelnet行末シーケンスCR LFを受信すると、その効果は、ユーザーがローカル端末で「行末」キーを押した場合と同じでなければなりません (MUST)。特にASCIIを使用するサーバーホストでは、TelnetシーケンスCR LFの受信は、ローカルユーザーがローカル端末でCRキーを押すのと同じ効果を引き起こさなければなりません。したがって、CR LFとCR NULは、Telnet接続を介して入力として受信されたときに、ASCIIサーバーホストで同じ効果を持たなければなりません (MUST)。
ユーザーTelnetは、CR LF、CR NUL、およびLFのいずれかの形式を送信できなければなりません (MUST)。ASCIIホスト上のユーザーTelnetは、ユーザーが「行末」キーを押したときにCR LFまたはCR NULのいずれかを送信するユーザー制御可能なモードを持つべきであり (SHOULD)、CR LFがデフォルトであるべきです (SHOULD)。
3.3.2 Data Entry Terminals (データエントリ端末)
Telnetが設計された行指向および文字指向のASCII端末に加えて、「データエントリ端末」またはDETとして知られるビデオディスプレイ端末のいくつかのファミリーがあります。IBM 3270ファミリーはよく知られた例です。
3.3.3 Option Requirements (オプション要件)
すべてのTelnet実装は、バイナリオプション [TELNET:3]とSuppress Go Aheadオプション [TELNET:5]をサポートしなければならず (MUST)、Echo [TELNET:4]、Status [TELNET:6]、End-of-Record [TELNET:9]、およびExtended Options List [TELNET:8]オプションをサポートすべきです (SHOULD)。
ユーザーまたはサーバーTelnetは、ローカルオペレーティングシステムが対応する機能を提供する場合、Window Sizeオプション [TELNET:12]をサポートすべきです (SHOULD)。
3.3.4 Option Initiation (オプション開始)
Telnetプロトコルがクライアント/サーバー状況で使用される場合、サーバーは期待する端末対話モードのネゴシエーションを開始すべきです (SHOULD)。
3.3.5 Telnet Linemode Option (Telnet Linemodeオプション)
重要な新しいTelnetオプション、LINEMODE [TELNET:12]が提案されています。LINEMODEオプションは、ユーザーTelnetとサーバーTelnetが、サーバーではなくクライアントが端末文字処理を実行することに合意するための標準的な方法を提供します。
3.4 TELNET/USER INTERFACE (TELNET/ユーザーインターフェース)
3.4.1 Character Set Transparency (文字セットの透過性)
ユーザーTelnet実装は、任意の7ビットASCII文字を送受信できるべきです (SHOULD)。可能であれば、ユーザーホストのオペレーティングシステムによる特別な文字解釈はバイパスされるべきであり (SHOULD)、これらの文字が接続上で便利に送受信できるようにします。
一部の文字値は「コマンドモードへのエスケープ」として予約されなければなりません (MUST)。従来、この文字を2倍にすることで、データとして入力できます。使用される特定の文字はユーザーが選択可能であるべきです (SHOULD)。
3.4.2 Telnet Commands (Telnetコマンド)
ユーザーTelnetプログラムは、ユーザーにTelnet制御機能IP、AO、またはAYTのいずれかを入力する機能を提供しなければならず (MUST)、EC、EL、およびBreakを入力する機能を提供すべきです (SHOULD)。
3.4.3 TCP Connection Errors (TCP接続エラー)
ユーザーTelnetプログラムは、トランスポート層によって報告されるTCPエラーをユーザーに報告すべきです (SHOULD)。
3.4.4 Non-Default Telnet Contact Port (非デフォルトTelnet接続ポート)
ユーザーTelnetプログラムは、ユーザーがサーバーTelnetホストで非標準の接続ポート番号をオプションで指定できるようにすべきです (SHOULD)。
3.4.5 Flushing Output (出力のフラッシュ)
ユーザーTelnetプログラムは、IPが送信されたときに出力をフラッシュすべきかどうかをユーザーが指定できる機能を提供すべきです (SHOULD)。セクション3.2.4を参照してください。
3.5 TELNET REQUIREMENTS SUMMARY (TELNET要件のまとめ)
| 機能 | セクション | MUST | SHOULD | MAY | SHOULD NOT | MUST NOT |
|---|---|---|---|---|---|---|
| オプションネゴシエーション | ||||||
| オプションネゴシエーション実装 | 3.2.1 | ✓ | ||||
| ネゴシエーションループ回避 | 3.2.1 | ✓ | ||||
| サポートされていないオプションを拒否 | 3.2.1 | ✓ | ||||
| 接続中いつでもネゴシエーション可能 | 3.2.1 | ✓ | ||||
| NVTにデフォルト設定 | 3.2.1 | ✓ | ||||
| Term-Typeオプションで公式名を送信 | 3.2.8 | ✓ | ||||
| Term-Typeオプションで任意の名前を受け入れ | 3.2.8 | ✓ | ||||
| Binary、Suppress-GAオプションを実装 | 3.3.3 | ✓ | ||||
| Echo、Status、EOL、Ext-Opt-Listオプション | 3.3.3 | ✓ | ||||
| 適切な場合Window-Sizeオプションを実装 | 3.3.3 | ✓ | ||||
| サーバーがモードネゴシエーションを開始 | 3.3.4 | ✓ | ||||
| ユーザーが初期ネゴシエーションを有効/無効化可能 | 3.3.4 | ✓ | ||||
| 制御機能 | ||||||
| SE NOP DM IP AO AYT SBをサポート | 3.2.3 | ✓ | ||||
| EOR EC EL Breakをサポート | 3.2.3 | ✓ | ||||
| サポートされていない制御機能を無視 | 3.2.3 | ✓ | ||||
| DMまで緊急データを破棄 | 3.2.4 | ✓ | ||||
| IP、AO、AYTの後に「Synch」を送信 | 3.2.4 | ✓ | ||||
| エンコーディング | ||||||
| NVTモードで上位ビットを送信しない | 3.2.5 | ✓ | ||||
| 上位ビットをパリティビットとして送信しない | 3.2.5 | ✓ | ||||
| 常にIACデータバイトを2倍化 | 3.2.6 | ✓ | ||||
| バイナリモードでIACデータバイトを2倍化 | 3.2.7 | ✓ | ||||
| 行末 | ||||||
| サーバーでEOLはローカルの行末と同じ | 3.3.1 | ✓ | ||||
| ASCIIサーバーはCR LFまたはCR NULをEOLとして受け入れ | 3.3.1 | ✓ | ||||
| ユーザーTelnetはCR LF、CR NUL、LFを送信可能 | 3.3.1 | ✓ | ||||
| ASCIIユーザーはCR LF/CR NULを選択可能 | 3.3.1 | ✓ | ||||
| ユーザーTelnetのデフォルトモードはCR LF | 3.3.1 | ✓ | ||||
| ユーザーTelnetインターフェース | ||||||
| すべての7ビット文字の入出力 | 3.4.1 | ✓ | ||||
| ローカルOSの解釈をバイパス | 3.4.1 | ✓ | ||||
| エスケープ文字 | 3.4.1 | ✓ | ||||
| ユーザー設定可能なエスケープ文字 | 3.4.1 | ✓ | ||||
| IP、AO、AYTを入力可能 | 3.4.2 | ✓ | ||||
| EC、EL、Breakを入力可能 | 3.4.2 | ✓ | ||||
| TCP接続エラーをユーザーに報告 | 3.4.3 | ✓ | ||||
| オプションの非デフォルト接続ポート | 3.4.4 | ✓ | ||||
| IP送信時の出力フラッシュを指定可能 | 3.4.5 | ✓ | ||||
| 出力モードを手動で復元可能 | 3.4.5 | ✓ |