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):
RFC-1091 [TELNET:10]は、RFC-930で定義された端末タイプオプションの以前のバージョンを更新したものです。以前のバージョンは、複数の端末タイプをサポートできるサーバーホストが、それぞれの物理端末に固有のタイプがあるという前提のもとで、特定のクライアント端末のタイプを知ることを可能にしていました。しかし今日では、「端末」は実際にはPC上で動作する端末エミュレータプログラムであることが多く、一定範囲の端末タイプをエミュレートできる場合があります。そのためRFC-1091は、ユーザーTelnetとサーバーTelnetの間でより一般的な端末タイプのネゴシエーションを行えるように仕様を拡張しました。
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)。
Telnet行末シーケンスCR LFは、端末からコンピュータへの通信ではないTelnetデータの送信に使用しなければなりません (MUST)（例えば、サーバーTelnetが出力を送信する場合や、Telnetプロトコルが別のアプリケーションプロトコルに組み込まれる場合）。
議論 (DISCUSSION):
任意のTelnetクライアントとサーバーの相互運用を可能にするため、Telnetプロトコルは行終端子の標準表現を定義しました。ASCII文字集合には明示的な行末文字が含まれていないため、システムごとにCR、LF、CR LFシーケンスなど異なる表現が選ばれてきました。Telnetプロトコルは、ネットワーク伝送の標準としてCR LFシーケンスを選択しました。
残念ながら、RFC-854 [TELNET:1]のTelnetプロトコル仕様は、クライアントが「行末」キーを表すためにサーバーへ何を送るべきかという点において、いくぶん曖昧であることが判明しました。その結果、深刻かつ継続的な相互運用性の問題が生じ、さらにユーザーおよびサーバーTelnetの誤った実装によって事態は悪化しました。
Telnetプロトコルは完全に対称なモデルに基づいていますが、リモートログインセッションでは、端末側のユーザーの役割とサーバーホストの役割は異なります。例えばRFC-854は、サーバー出力としてのCR、LF、CR LFの意味は定義していますが、ユーザーが端末上の「行末」キーを押したときにユーザーTelnetが何を送るべきかは規定していません。これが論争の的となっている点です。
ユーザーが「行末」キーを押したとき、一部のユーザーTelnet実装はCR LFを送信し、別の実装はCR NULを送信します（RFC-854の同じ一文の異なる解釈に基づいています）。上述のとおり、正しく実装されたASCIIサーバーホストにとって、この2つは等価です。それ以外のサーバーについては、ユーザーTelnet側にモードが必要となります。
CRが押されたときにCR NULのみを送るユーザーTelnetが存在することは、非ASCIIホストにジレンマを生みます。すなわち、入力中のCR NULをCR LFと等価に扱って「素の」CRを入力する可能性を排除するか、あるいは相互運用性を完全に失うかのいずれかです。
ホストA上のユーザーがTelnetでサーバーホストBにログインし、そこからBのユーザーTelnetプログラムを実行してサーバーホストCにログインすると仮定します。理想的には、B上のサーバー/ユーザーTelnetの組み合わせは可能な限り透過的であるべきです。つまり、AがCに直接接続しているかのように振る舞うべきです。特に、正しい実装であれば、BはTelnet行末シーケンスに対して透過的であり、CR LFがCR NULに（またはその逆に）変換され得る点を除いては変更を加えません。
実装 (IMPLEMENTATION):
Telnetの行末問題を理解するには、Telnetとローカルオペレーティングシステムの関係について少なくとも大まかなモデルを持つ必要があります。サーバーTelnetプロセスは通常、擬似端末としてオペレーティングシステムの端末ドライバソフトウェアに結合されます。サーバーTelnetが受信したTelnet行末シーケンスは、実際にローカル接続された端末で行末キーを押したのと同じ効果を持たなければなりません。
対話的な文字単位アプリケーション（エディタなど）をサポートするオペレーティングシステムは、通常、端末I/Oに対して2つの内部モードを提供します。1つは、行末やその他の書式規則に関するローカルの取り決めがデータストリームに適用される書式化モードであり、もう1つは、アプリケーションが入力の各文字に直接アクセスできる「生 (raw)」モードです。サーバーTelnetは、これらのモードがリモート端末に対してもローカル端末と同じ効果を持つように実装されなければなりません。例えば、ASCIIホスト上のサーバーTelnetがCR LFまたはCR NULを受信したとします。生モードではCR文字がアプリケーションに渡され、書式化モードではローカルシステムの行末規則が使用されます。
3.3.2 Data Entry Terminals (データエントリ端末)
議論 (DISCUSSION):
Telnetが設計された行指向および文字指向のASCII端末に加えて、「データエントリ端末」またはDETとして知られるビデオディスプレイ端末のいくつかのファミリーがあります。IBM 3270ファミリーはよく知られた例です。
汎用DETをサポートするために、2つのインターネットプロトコルが設計されてきました。SUPDUP [TELNET:16, TELNET:17]とDETオプション [TELNET:18, TELNET:19]です。DETオプションは、Telnet接続上でデータエントリ端末を駆動するために（サブ）ネゴシエーションを使用します。SUPDUPは完全に独立した端末プロトコルであり、ネゴシエーションによってTelnetから移行できます。SUPDUPとDETオプションはいずれも特定の環境では成功裏に使用されましたが、どちらも一般的な受容や広範な実装には至りませんでした。
Telnetを介したIBM 3270ファミリーのサポートのために、これとは異なるDET対話手法が発展しました。ただし同じ手法は任意のDETにも適用可能です。その考え方は「ネイティブDET」モードに入り、そこではネイティブDETの入出力ストリームがバイナリデータとして送信されるというものです。Telnet EORコマンドは、このバイナリストリーム内で論理レコード（例えば「画面」）を区切るために使用されます。
実装 (IMPLEMENTATION):
ネイティブDETモードへの出入りの規則は次のとおりです。
o サーバーは、端末タイプオプション [TELNET:10]を用いてクライアントがDETであることを知ります。
o 慣例として（必須ではありませんが）、両端はEORオプション [TELNET:9]をネゴシエートします。
o 両端はバイナリオプション [TELNET:3]をネゴシエートしてネイティブDETモードに入ります。
o いずれかの端がバイナリモードから抜けるようネゴシエートすると、もう一方も追随し、モードは通常のNVTに戻ります。
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)。
議論 (DISCUSSION):
End-of-Recordオプションは、TelnetがクラッシュせずにTelnet EORを受信できることを示すにすぎない点に注意してください。したがって、すべてのTelnetはEnd-of-Recordオプションのネゴシエーションを受け入れる用意があるべきです。セクション3.2.3の議論も参照してください。
3.3.4 Option Initiation (オプション開始)
Telnetプロトコルがクライアント/サーバー状況で使用される場合、サーバーは期待する端末対話モードのネゴシエーションを開始すべきです (SHOULD)。
議論 (DISCUSSION):
Telnetプロトコルは完全に対称に定義されていますが、その応用は通常は非対称です。双方が必要な非デフォルトの端末モードのネゴシエーションを開始しなかったために、リモートログインが失敗した事例が知られています。一般に、優先されるモードを決定するのはサーバーであるため、サーバーがネゴシエーションを開始する必要があります。ネゴシエーションは対称であるため、ユーザー側が開始することも可能です。
クライアント（ユーザーTelnet）は、オプションネゴシエーションの開始を有効化および無効化する手段をユーザーに提供すべきです (SHOULD)。
議論 (DISCUSSION):
ユーザーは、制御ストリームにTelnetを使用するもののTelnetオプションはサポートしないアプリケーションサービス（FTPやSMTPなど）に接続する必要がある場合があります。オプションネゴシエーションの開始を無効化できれば、ユーザーTelnetをこの目的に使用できます。
3.3.5 Telnet Linemode Option (Telnet Linemodeオプション)
議論 (DISCUSSION):
重要な新しいTelnetオプション、LINEMODE [TELNET:12]が提案されています。LINEMODEオプションは、ユーザーTelnetとサーバーTelnetが、サーバーではなくクライアントが端末文字処理を実行することに合意するための標準的な方法を提供します。クライアントは1行分のテキストを整えたうえで、（通常は）1つのTCPセグメントでその行をサーバーへ送信します。このオプションはTelnetセッションのパケットオーバーヘッドを大幅に削減し、輻輳したネットワークや遅延の大きいネットワークにおいてはるかに優れた応答性をユーザーに提供します。
LINEMODEオプションは、ローカル文字処理とリモート文字処理の動的な切り替えを可能にします。例えば、全画面エディタの実行中はTelnet接続が自動的に1文字単位モードへネゴシエートし、エディタ終了後にlinemodeへ戻ります。
本RFCの発行時点で、ホストはこのオプションのクライアント側を実装すべきであり、サーバー側を実装してもよいと考えられます。サーバー側を適切に実装するには、サーバーが入力文字処理を一切行わないようローカルシステムに指示し、代わりに現在の端末状態を記憶して、状態が変化したときにサーバーTelnetプロセスへ通知できる必要があります。これにより、例えばパスワードのエコーや全画面エディタが正しく処理されるようになります。
3.4 TELNET/USER INTERFACE (TELNET/ユーザーインターフェース)
3.4.1 Character Set Transparency (文字セットの透過性)
ユーザーTelnet実装は、任意の7ビットASCII文字を送受信できるべきです (SHOULD)。可能であれば、ユーザーホストのオペレーティングシステムによる特別な文字解釈はバイパスされるべきであり (SHOULD)、これらの文字が接続上で便利に送受信できるようにします。
一部の文字値は「コマンドモードへのエスケープ」として予約されなければなりません (MUST)。従来、この文字を2倍にすることで、データとして入力できます。使用される特定の文字はユーザーが選択可能であるべきです (SHOULD)。
バイナリモードの接続では、ホストのオペレーティングシステムがキーボードから任意の8ビット値を直接入力することを許さない場合、ユーザーTelnetプログラムはこれらの値を入力するためのエスケープ機構を提供してもよいでしょう (MAY)。
実装 (IMPLEMENTATION):
透過性の問題はサーバー側ではそれほど切迫していませんが、実装者は次のような点の処理に注意すべきです。すなわち、NVT ASCIIのみを期待するプログラムにデータが届く前に（規格に準拠しない古いクライアントが送出した）パリティビットをマスクして取り除くこと、および8ビットのデータストリームを要求するプログラムを正しく扱うことです。
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)（[INTRO:1]の「TCP/アプリケーション層インターフェース」の節を参照）。
3.4.4 Non-Default Telnet Contact Port (非デフォルトTelnet接続ポート)
ユーザーTelnetプログラムは、ユーザーがサーバーTelnetホストで非標準の接続ポート番号をオプションで指定できるようにすべきです (SHOULD)。
3.4.5 Flushing Output (出力のフラッシュ)
ユーザーTelnetプログラムは、IPが送信されたときに出力をフラッシュすべきかどうかをユーザーが指定できる機能を提供すべきです (SHOULD)。セクション3.2.4を参照してください。
サーバーからTelnet信号を受信するまでユーザーTelnetがローカルに出力を破棄するような出力フラッシュ方式では、サーバーが期待される信号を送信しなかった場合に備えて、通常の出力に手動で復帰する手段をユーザーに提供すべきです (SHOULD)。
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 | ✓ |