サイト内関連リンク：
RFC 854 TELNET プロトコル仕様(日本語訳)
原文：ftp://ftp.rfc-editor.org/in-notes/rfc855.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
ソーシャルブックマーク：
サイト内関連リンク：
RFC 854 TELNET プロトコル仕様(日本語訳)
This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. 本 RFC は ARPA インターネットコミュニティのための標準を規定する。ARPA インターネット上のホストはこの標準を採用し、実装することを期待される。
The intent of providing for options in the TELNET Protocol is to permit hosts to obtain more elegant solutions to the problems of communication between dissimilar devices than is possible within the framework provided by the Network Virtual Terminal (NVT). It should be possible for hosts to invent, test, or discard options at will. Nevertheless, it is envisioned that options which prove to be generally useful will eventually be supported by many hosts; therefore it is desirable that options should be carefully documented and well publicized. In addition, it is necessary to insure that a single option code is not used for several different options. TELNET プロトコルにおいてオプションを提供する目的は、異なるデバイス間での通信の問題に付いて、ネットワーク仮想端末(NVT)によって提供されるフレームワーク内で可能なものより洗練された解決策をホストが得られるようにすることである。ホストは自由にオプションを考案・評価・破棄できるべきである。それでも一般的に有用であると判明したオプションは、最終的に多くのホストによってサポートされると考えられる。そのためオプションは丁寧に文書化され、広く公開されることが望ましい。さらに、単一のオプションコードが複数の異なるオプションに使用されないことを保証することも必要である。
This document specifies a method of option code assignment and standards for documentation of options. The individual responsible for assignment of option codes may waive the requirement for complete documentation for some cases of experimentation, but in general documentation will be required prior to code assignment. Options will be publicized by publishing their documentation as RFCs; inventors of options may, of course, publicize them in other ways as well. 本文書は、オプションコードの割り当ての手段と、オプションの文書のための標準とを規定する。実験目的などの場合にはオプションコードの割り当ての個々の責任者は文書を完成させる要件を放棄してもよいが、一般にコード割り当てに先立って文書化が必要となるだろう。オプションはその文書を RFC として発行することで公表される。もちろんオプションの考案者は他の方法でそれらを公開してもよい。
Option codes will be assigned by: オプションコードの割り当て担当者：
Jonathan B. Postel
University of Southern California
Information Sciences Institute (USC-ISI)
4676 Admiralty Way
Marina Del Rey, California 90291
(213) 822-1511
Mailbox = POSTEL@USC-ISIF
Documentation of options should contain at least the following sections: オプションの文書は少なくとも以下のセクションを含むべきである：
Some options will require more information to be passed between hosts than a single option code. For example, any option which requires a parameter is such a case. The strategy to be used consists of two steps: first, both parties agree to "discuss" the parameter(s) and, second, the "discussion" takes place. 一部のオプションは、ホスト間で渡される単独のオプションコード以上の情報を必要とするだろう。例えばパラメータを必要とするオプションの場合がそれにあたる。使用される戦略は二つのステップから構成される。最初に両方の参加者がパラメータに付いて "話し合う(discuss)" ことに合意し、次にその "話し合い(discussion)" が行われる。
The first step, agreeing to discuss the parameters, takes place in the normal manner; one party proposes use of the option by sending a DO (or WILL) followed by the option code, and the other party accepts by returning a WILL (or DO) followed by the option code. Once both parties have agreed to use the option, subnegotiation takes place by using the command SB, followed by the option code, followed by the parameter(s), followed by the command SE. Each party is presumed to be able to parse the parameter(s), since each has indicated that the option is supported (via the initial exchange of WILL and DO). On the other hand, the receiver may locate the end of a parameter string by searching for the SE command (i.e., the string IAC SE), even if the receiver is unable to parse the parameters. Of course, either party may refuse to pursue further subnegotiation at any time by sending a WON'T or DON'T to the other party. 第一のステップ(パラメータの話し合いに合意すること)は通常の方法で行われる。一方の参加者が DO (または WILL)に続けてオプションコードを送信することでそのオプションの使用を提案し、もう一方の参加者が WILL (または DO)に続けてオプションコードを返すことで受け入れる。いったん両者がオプションの使用に合意すると、SB コマンド・オプションコード・パラメータ・SE コマンド と続けて使用することで副交渉が行われる。各参加者はそのオプションをサポートしていることを(最初の WILL と DO の交換によって)示しているため、パラメータを解析できると見なされる。その一方で受信側は SE コマンド(つまり文字列 IAC SE)を探すことで、たとえパラメータを解析できなくてもパラメータ文字列の終了を見つけることができる。当然ながら、一方の参加者が他方の参加者に WON'T または DON'T を送信することで、いつでも副交渉の継続を拒否してよい。
Thus, for option "ABC", which requires subnegotiation, the formats of the TELNET commands are: したがって副交渉を必要とするオプション "ABC" の場合、TELNET コマンドの形式は以下のようになる：
Designers of options requiring "subnegotiation" must take great care to avoid unending loops in the subnegotiation process. For example, if each party can accept any value of a parameter, and both parties suggest parameters with different values, then one is likely to have an infinite oscillation of "acknowledgments" (where each receiver believes it is only acknowledging the new proposals of the other). Finally, if parameters in an option "subnegotiation" include a byte with a value of 255, it is necessary to double this byte in accordance the general TELNET rules. "副交渉(subnegotiation)" を要求するオプションの設計者は、その副交渉のプロセスにおける永久ループを避けるように細心の注意を払わなければならない。例えば、それぞれの参加者があるパラメータに任意の値を受け入れることが可能であり、かつ両方の参加者が異なる値のパラメータを提案した場合、"肯定確認応答(acknowledgments)" の無限の繰り返しが発生する可能性がある(それぞれの受信者は他方の新しい提案に肯定応答を返しているだけだと考える)。最後に、オプションの "副交渉(subnegotiation)" におけるパラメータが値 255 を持つ 1 バイトを含む場合、一般的な TELNET の規則に従うためにそのバイトを 2 倍する必要がある。