サイト内関連リンク：
RFC 855 TELNET オプション仕様(日本語訳)
原文：ftp://ftp.rfc-editor.org/in-notes/rfc854.txt
ソーシャルブックマーク：
サイト内関連リンク：
RFC 855 TELNET オプション仕様(日本語訳)
この RFC は ARPA インターネットコミュニティのための標準を規定する。ARPA インターネット上のホストはこの標準を採用し、実装することを期待される。
TELNET プロトコルの目的は、極めて一般的な双方向の 8 ビット志向通信機能を提供することである。その第一の目標は、端末装置と端末志向プロセスとを互いにインターフェイスする標準的手法を与えることである。このプロトコルは端末-端末通信("リンク")や、プロセス-プロセス通信(分散コンピューティング)に利用されることも見込んでいる。
TELNET 接続は、TELNET 制御情報を散りばめられたデータを送信するために使用される Transmission Control Protocol (TCP) 接続である。
TELNETプロトコルは３つの主要な着想に基いて構築されている。第一に "ネットワーク仮想端末" の概念; 第二にオプション交渉の原則; そして第三に、端末とプロセスとの対称的ビューである。
注意：通常 "ユーザー" ホストは物理的端末が取り付けられたホストであり、"サーバー"ホストは何らかのサービスを提供しているホストである。端末-端末間通信やプロセス-プロセス間通信の場合にも適用可能な別の考え方をすると、"ユーザー" ホストとは、通信を始めたホストである。
使用オプションを設定する場合の基本的戦略は、参加者のどちらか(あるいは両方)が、あるオプションが効果を持つという要求を発することである。その後もう一方の参加者は、その要求を受入れても拒否しても良い。もしその要求が受入れられると、その要求は即座に効果を現す。もしそれが拒否されると、その接続においてそのオプションに関連する部分は NVT 向けに規定されたままとなる。明らかに、参加者は有効化する要求を常に拒否しても良く、また全ての参加者は NVT をサポートする準備が出来ていなければならないため、オプションを無効化する要求を決して拒否してはならない。
オプション交渉の文法は、両方の参加者があるオプションを同時に要求した場合、各々が相手側の要求をそのオプションの肯定承認と見なすことが出来るように設計されている。
各々の参加者はもう一方の参加者から可能な最高のサービスを得ようと試みるため、TELNET 接続が最初に確立したとき、オプション要求は一時的に混乱するだろう。しかしその後でも、接続の特徴を動的に修正することでローカルの状態変化に合せるためにオプションを利用して良い。例えば NVT が使用する通信規則は(後で説明するように)、BASICのような "行単位(line at a time)" のアプリケーションの多くにはうまく適合するが、NLS のような "文字単位(character at a time)" のアプリケーションの多くには不十分にしか適合しない。ローカルプロセスのために "文字単位" の規則が適切な時には、サーバーはそれに必要とされる余分なプロセッサのオーバーヘッドを捧げるという選択をしてもよく、その場合は適切なオプションを交渉するかもしれない。しかしながらその場合でも、余分なプロセッサのオーバーヘッドを永久に負うのではなく、綿密な制御が不要になった時点で NVT に切り替える(すなわち交渉する)ことも出来る。
プロセスがオプションを単に再要求することによって拒否応答する場合、そのプロセスによって開始された要求は、終わりの無い要求のループを発生させる可能性がある。そのようなループの発生を防ぐため、一度拒否された要求は、何らかの変化があるまで繰り返すべきではない。これを操作上で見ると、プロセスが別のプログラムを実行した場合か、与えられたプロセスとオプションとの文脈において意味を持つ何かまたは別の命令をユーザーが与えた場合と考えることが出来る。良い経験則は、接続相手からの後続の情報の結果としてか、ローカルの人間の介入による要求があった場合かにのみ再要求を行うべきということである。
オプション交渉で利用可能な限定された文法のために、オプションの設計者が制約を感じるべきではない。この単純な文法の目的は、オプションを持つことを容易にすることである -- それに付いて知らないことを明言するのも同様に容易であるため。ある特定のオプションが "DO, DON'T, WILL, WON'T" で可能なものより豊富な交渉構造を必要とする場合の適切な方法は、両参加者がそのオプションを理解できることを確認するために "DO, DON'T, WILL, WON'T" を使用し、それが成功した後、よりエキゾチックな文法を自由に使用出来るようにすることである。例えば参加者は、行の長さを変更(確定)する要求を送っても良い。それが受け入れられれば、実際に行の長さを交渉するために別の文法を使用できる -- このような "副交渉(sub-negotiation)" には、許される最小限の行長、許される最大限の行長、望ましい行長等のフィールドが含まれるかもしれない。重要な概念は、両参加者がその拡張された文法を解析する能力があるという(通常の)交渉が事前に成立するまで、このような拡張された交渉は決して開始されるべきではないということである。
要約すると、どちらかの参加者からオプション XXX を実行したいという希望(提案)を示すために WILL XXX が送信され、DO XXX と DON'T XXX がそれに対する肯定と否定である。同じくもう一方の参加者(すなわち DO の受信者)がオプション XXX を実行し始めるという希望(要求)を示すために DO XXX が送信され、WILL XXX と WON'T XXX がそれに対する肯定と否定である。全てのオプションが有効でない時に残るものが NVT であるので、DON'T 応答と WON'T 応答とが行われても、両端末がその接続を処理できる状態は保たれることが保証される。従って全てのホストは、サポートしないオプションを全く認識せず、理解できない全てのオプション要求を単に拒否する(すなわち断る)ような TELNET プロセスを実装しても良い。
TELNET プロトコルはユーザー-ユーザー(リンク)とサーバー-サーバー(分散コンピューティング)とを容易かつ自然に網羅するために、可能な限りサーバー-ユーザーが対称的になるように作られてきた。オプションはその目的を推進することを期待される(しかし絶対必要条件ではない)。どのような場合でも、この対称性は厳しい規則というより、むしろ運用上の原則であることが明示的に確認されている。
新しいオプションを確立する手続きに関する情報として、関連文書 "TELNET オプション仕様(TELNET Option Specifications)" を参考にするべきである。
ネットワーク仮想端末(NVT)は双方向キャラクタデバイスである。NVT はプリンタとキーボードとを持つ。プリンタは入力データに応答し、キーボードは TELNET 接続上で送信される出力データや、"エコー" が望まれる場合には NVT のプリンタへも送られる出力データを生成する。"エコー" がネットワークを通ることは期待されないだろう("リモート" エコーモードの操作を有効にするオプションは存在するが、いかなるホストもこのオプションの実装を要求されない)。ここでの修正を除いて、コードセットは 8 ビットフィールドに置かれる 7 ビット USASCII である。いかなるコード変換もタイミングの考慮もローカルの問題であり、NVT には影響を与えない。
この規則の動機は、"エコー"がネットワークを通らないというデフォルトの NVT 仕様と相まって、ネットワーク入力割り込みを処理することが一部のホストにとって高コストだからである。そのため、ある程度のデータを送信元でバッファすることは合理的である。多くのシステムは、各入力行の終わりに何らかの処理アクションを行う(ラインプリンタやパンチカードでさえ、たびたびこのように動作する傾向がある)ので、通信は行の終わりで発生するべきである。一方でユーザーまたはプロセスは、時に行が終わっていない状態のデータを提供することが必要、または望ましいということを見いだすかもしれない。ゆえに実装者は、バッファされている全てのデータを即座に送信するためのローカルな合図の手段を提供するように警告される。
通常サーバーホストは処理を開始するために(行末またはローカル定義の文字に加えて)特別な合図を必要としないため、この規則には、端末が行末毎に TELNET GA 命令を送信することを要求する意図はない。むしろこの TELNET GA は、IBM 2741 のような "ロック可能" なキーボードを持つ物理的に半二重の端末をユーザーのローカルホストが操作することを助けるために設計されている。この種の端末の説明は、GA 命令の適切な利用を説明する助けになるかもしれない。
端末-コンピュータの接続は、常にそのユーザーかそのコンピュータの制御下にある。どちらも相手から一方的に制御を奪うことはできず、むしろ制御の終わりには明示的にその制御を戻さなければならない。端末側においてハードウェアは、"行" が終わるたびに(すなわち、ユーザーによって "新規行(New Line)" キーが押された時に)制御を戻すように構成される。これが起こったとき、取り付けられた(ローカルの)コンピュータは入力データを処理し、出力を生成するべきかどうかを決め、出力を生成するべきではない場合は端末に制御を戻す。出力を生成するべき場合、すべての出力が送信されるまでそのコンピュータによって制御が保持される。
ネットワークを通してこのタイプの端末を使用することの難しさは明らかなはずである。"ローカル"のコンピュータは、もはや行末の合図を知った後に制御を保持するかどうかを決定することはできず、その決定はデータを処理している"リモート" のコンピュータによってのみ可能である。ゆえに TELNET GA 命令は、"リモート" の(サーバー)コンピュータが "ローカル" の(ユーザー)コンピュータに、その端末のユーザーへ制御を渡す時であることを知らせることが出来るメカニズムを提供する。これは、ユーザーが端末の制御を与えられるべき時に(そして、その時にのみ)送信されるべきである。GA 命令の早まった送信は出力をブロックする結果となり、ユーザーは送信システムが停止したと思い込み、手動で回線を切るかもしれないということに注意してほしい。
当然ながら、これはユーザーからサーバーへの通信には適用されない。この方向において GA はいつ送信されても良いが、全く送られなくても良い。同様に TELNET 接続がプロセス間通信に使用される場合、GA はどちらの方向にも送られる必要はない。最後に端末間通信の場合、GA は一方向にも双方向にも必要とされない。ホストが端末間通信をサポートすることを計画している場合、TELNET 接続上で GA が送られる時を手動で知らせる手段をユーザーに提供することが推奨される。しかしながら、これは TELNET プロセスの実装者に課される必要条件ではない。
少なくとも概念上、TELNET モデルの対称性は TELNET 接続の各々の端に NVT が存在することを必要とすることに注意してほしい。
* 注意: "印字位置"は、重打ちや <文字1>BS<文字2>...のようなシーケンスの結果として、いくつかの複数の文字を含んでも良い。
この問題に対処するために、TELNET の "Synch" メカニズムが導入されている。Synch シグナルは、TELNET 命令 DATA MARK と、それに関連する TCP の Urgent 通知とから成る。Urgent 通知(これは TELNET 接続に付随するフロー制御には支配されない)は、それを受け取ったプロセスがデータストリームの特別な処理を呼び出すために使用される。このモードにおいてデータストリームは、間にある邪魔なデータを捨てられながら、以下で定義されている "興味深い(interesting)" シグナルを即座にスキャンされる。TELNET 命令 DATA MARK(DM) はデータストリーム内の同期マークであり、何らかの特別なシグナルが既に発生しており、受信者はデータストリームの通常の処理に戻ることが出来るということを示す。
Synch は Urgent フラグがセットされた TCP 送信操作により実現され、最後の(または唯一の)データオクテットとして DM が送信される。
DM が見つかる前に TCP が Urgentデータの終わりを示した場合、 TELNET は DM が見つかるまでそのデータストリームの特別な処理を続けるべきである。
DM が見つかった後に TCP がさらに Urgent データを示した場合、その原因は後続の Synch によるものだけである。TELNET はもうひとつの DM を見つけるまでそのデータストリームの特別な処理を続けるべきである。
TCP Urgent モードの送信操作における唯一の文字として Data Mark (DM) を送信する。
Urgent は TELNET プロセスを覚醒させるべきである。IP は、その次に上位のレベルのプロトコルを覚醒させるべきである。
| 名称 | コード | 意味 |
| NULL (NUL) | 0 | 無操作 |
| 改行(Line Feed)(LF) | 10 | 水平位置を保ちながらプリンタを次の行に進める。 |
| 復帰(Carriage Return)(CR) | 13 | プリンタを現在行の左端に移動する。 |
| ベル(BELL)(BEL) | 7 | 聞こえるか目に見えるシグナルを生成する(印字ヘッドは移動しない)。 |
| バックスペース(Back Space)(BS) | 8 | 印字ヘッドを左端に向かって1文字分移動する。 |
| 水平タブ(Horizontal Tab)(HT) | 9 | プリンタを次の水平タブ位置に移動する。両方の参加者がタブ位置をどのように決定・確立するかは、まだ規定されていない。 |
| 垂直タブ(Vertical Tab)(VT) | 11 | プリンタを次の垂直タブ位置に移動する。両方の参加者がタブ位置をどのように決定・確立するかは、まだ規定されていない。 |
| 改ページ(Form Feed)(FF) | 12 | 水平位置を保ちながらプリンタを次のページに移動する。 |
NVT モデルの対称性を維持するために、"CR LF" や "CR NUL"は(デフォルトの ASCII モードにおいて)両方向で要求されることに注意してほしい。例えある状況(例えばリモートエコーと go ahead 抑制オプションが効いている状況)では文字が実際のプリンタに送られないことが分かっているとしても、それでもなお一貫性のために、このプロトコルはデータストリーム中で LF に続けてではなく CR に続けて NUL が挿入されることを要求する。逆に、データストリーム内で CR の後に受信した NUL は(別の方法で明示的に指定されたオプションの取り決めが無い場合には)、NVT がローカルの文字セットに変換する前に捨てられるべきである。
全ての TELNET 命令は少なくとも２バイトのシーケンスから成る。命令コードの後に "コマンドとして解釈(Interpret as Command)"(IAC）エスケープ文字が続く。オプション交渉を扱う命令は３バイトのシーケンスで、３バイト目が参照されるオプションのコードである。この形式は、"データ空間" がより広範囲に使用されても、予約された命令の値を持つデータとの衝突が最小にになるように選ばれた。そのような衝突は、不便で非能率的な、データバイトをデータストリームに "エスケープする" 作業を必要とする。現状の設定では、唯一 IAC のみがデータとして送信される場合に二重化される必要があり、その他の 255 個のコードは透過的に渡すことが出来る。
以下は定義済み TELNET 命令である。これらのコードとコードシーケンスとは、直前に IAC が来た場合にだけ示されている意味を持つことに注意してほしい。
| 名称 | コード | 意味 |
| SE | 240 | 副交渉の終わり |
| NOP | 241 | 無操作 |
| Data Mark | 242 | Synch のデータストリーム部分。 これは常に TCP Urgent 通知を伴うべきである。 |
| Break | 243 | NVT 文字 BRK |
| Interrupt Process | 244 | IP 機能 |
| Abort output | 245 | AO 機能 |
| Are You There | 246 | AYT 機能 |
| Erase character | 247 | EC 機能 |
| Erase Line | 248 | EL 機能 |
| Go ahead | 249 | GA シグナル |
| SB | 250 | 後に続くのが示されたオプションの副交渉であることを表す |
| WILL (オプションコード) | 251 | 示されたオプションの実行開始、または実行中かどうかの確認を望むことを表す |
| WON'T (オプションコード) | 252 | 示されたオプションの実行拒否または継続実行拒否を表す |
| DO (オプションコード) | 253 | 示されたオプションを実行するという相手側の要求、またはあなたがそれを実行することを期待しているという確認を表す |
| DON'T (オプションコード) | 254 | 示されたオプションを停止するという相手側の要求、またはあなたがそれを実行することをもはや期待しないという確認を表す |
| IAC | 255 | データバイト 255 |
TELNET の TCP 接続は、ユーザーのポート U とサーバーのポート L との間で確立される。サーバーはそのような接続を、そのウエルノウンポート L で待ち受ける。TCP 接続は全二重であり、ポートの組で識別されるので、サーバーはポート L と別のユーザーポート U とを含む多くの同時接続を確立することが出来る。