この文書はRFC854の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの文書の配布を制限しません。


Network Working Group                                          J. Postel
Request for Comments: 854                                    J. Reynolds
                                                                     ISI
Obsoletes: NIC 18639                                            May 1983

                     TELNET PROTOCOL SPECIFICATION
                      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イン
ターネット上のホストがこの標準を取り入れ実装することを期待されます。

INTRODUCTION
はじめに

   The purpose of the TELNET Protocol is to provide a fairly general,
   bi-directional, eight-bit byte oriented communications facility.  Its
   primary goal is to allow a standard method of interfacing terminal
   devices and terminal-oriented processes to each other.  It is
   envisioned that the protocol may also be used for terminal-terminal
   communication ("linking") and process-process communication
   (distributed computation).
   TELNETプロトコルの目的はかなり一般的な、双方向性の、8ビットバ
   イト指向の通信機能を供給することです。その主なゴールはお互いに端末装
   置の接続標準方法と端末志向のプロセスを許すことです。プロトコルは端末
   −端末通知(「リンク」)とプロセス−プロセス通信(分散計算)に使われ
   るかもしれないことが心に描かれます。

GENERAL CONSIDERATIONS
一般的な考察

   A TELNET connection is a Transmission Control Protocol (TCP)
   connection used to transmit data with interspersed TELNET control
   information.
   TELNET接続は、点在したTELNET制御情報と共にデータを伝達す
   るために使われる伝送制御プロトコル(TCP)接続です。

   The TELNET Protocol is built upon three main ideas:  first, the
   concept of a "Network Virtual Terminal"; second, the principle of
   negotiated options; and third, a symmetric view of terminals and
   processes.
   TELNETプロトコルは3つの主な考えの上に構築されます:最初の考え
   は「ネットワーク仮想端末」;2番目はオプション交渉;3番目は端末とプ
   ロセスの対称な観点。

   1.  When a TELNET connection is first established, each end is
   assumed to originate and terminate at a "Network Virtual Terminal",
   or NVT.  An NVT is an imaginary device which provides a standard,
   network-wide, intermediate representation of a canonical terminal.
   This eliminates the need for "server" and "user" hosts to keep
   information about the characteristics of each other's terminals and
   terminal handling conventions.  All hosts, both user and server, map
   their local device characteristics and conventions so as to appear to
   be dealing with an NVT over the network, and each can assume a
   similar mapping by the other party.  The NVT is intended to strike a
   balance between being overly restricted (not providing hosts a rich
   enough vocabulary for mapping into their local character sets), and
   being overly inclusive (penalizing users with modest terminals).
   1.  TELNET接続が最初に確立される時、各終端が「ネットワーク仮想
   端末」あるいはNVTの始点と終点と考えられます。NVTは標準を供給す
   る仮想の装置、標準的端末のネットワーク規模の中間の表現です。これは
   「サーバ」ホストと「ユーザ」ホストがお互いに他の端末の特徴と、端末処
   理規約を記憶する必要をなくします。すべてのホスト、ユーザとサーバの両
   方は、ネットワーク上でNVTを扱っているように思われるように、ローカ
   ル装置の特徴と規約を変換し、そしてそれぞれが他者も類似の変換をしてい
   ると仮定します。NVTは過度な限定(ローカルな文字セットへの変換のた
   めの十分豊かな語彙を用意しない)と、過度の包含(質素な端末のユーザに
   ペナルティーを課す)の間のバランスを得るように意図されます。

      NOTE:  The "user" host is the host to which the physical terminal
      is normally attached, and the "server" host is the host which is
      normally providing some service.  As an alternate point of view,
      applicable even in terminal-to-terminal or process-to-process
      communications, the "user" host is the host which initiated the
      communication.
      ノート:「ユーザ」ホストは物理的端末が通常付加されているホストで、
      そして「サーバ」ホストは通常あるサービスを供給しているホストです。
      端末から端末やプロセスからプロセスへの通信に適用可能な他の言い方と
      して、「ユーザ」ホストは通信を始めたホストです。

   2.  The principle of negotiated options takes cognizance of the fact
   that many hosts will wish to provide additional services over and
   above those available within an NVT, and many users will have
   sophisticated terminals and would like to have elegant, rather than
   minimal, services.  Independent of, but structured within the TELNET
   Protocol are various "options" that will be sanctioned and may be
   used with the "DO, DON'T, WILL, WON'T" structure (discussed below) to
   allow a user and server to agree to use a more elaborate (or perhaps
   just different) set of conventions for their TELNET connection.  Such
   options could include changing the character set, the echo mode, etc.
   2.  オプション交渉の原則は多くのホストがNVTで利用可能なサービスに
   追加のサービスを供給するのを望み、多くのユーザーは精巧な端末を持ち、
   最小であるより簡潔なサービスを望むであろうという事実です。独立に、し
   かし構造化して、TELNETプロトコルに様々な「オプション」があり、
   それらは認可され、(後で述べる)"DO, DON'T, WILL, WON'T"構造体で、ユー
   ザとサーバがより巧妙な(あるいは異なった)協定を使うのを許すのに、使
   われます。このようなオプションは文字セットはエコーモードなどの変更を
   含みます。

   The basic strategy for setting up the use of options is to have
   either party (or both) initiate a request that some option take
   effect.  The other party may then either accept or reject the
   request.  If the request is accepted the option immediately takes
   effect; if it is rejected the associated aspect of the connection
   remains as specified for an NVT.  Clearly, a party may always refuse
   a request to enable, and must never refuse a request to disable some
   option since all parties must be prepared to support the NVT.
   オプションの使用を設定する基本的な戦略はいずれか(あるいは両方)が何
   かのオプションが効力を発するという要請を始める事です。他方は要請を受
   け入れるか、拒絶するかもしれません。もし要請が受け入れられるなら、オ
   プションはすぐに効力を発します;もし拒絶されるなら、接続の関連機能は
   NVTで指定たままです。明らかに、一方が機能を利用可能にする要請を断
   るかもしれなくて、そして全ユーザとサーバがNVTをサポートする用意が
   できているに違いないので、オプショの利用停止要請を断ってはなりません。

   The syntax of option negotiation has been set up so that if both
   parties request an option simultaneously, each will see the other's
   request as the positive acknowledgment of its own.
   オプション交渉の文法は、もし両者が同時にオプションを求めるなら、それ
   ぞれが要請で積極的確認という事です。

   3.  The symmetry of the negotiation syntax can potentially lead to
   nonterminating acknowledgment loops -- each party seeing the incoming
   commands not as acknowledgments but as new requests which must be
   acknowledged.  To prevent such loops, the following rules prevail:
   3.  交渉文法の対称性は潜在的に終了しないループを発生します−両者が受
   信要請を確認ではなく新しい要求と認識し確認をする。このようなループを
   妨げるために、次の規則を使います:

      a. Parties may only request a change in option status; i.e., a
      party may not send out a "request" merely to announce what mode it
      is in.
      a. ただオプション状態の変更を求めるだけかもしれません;すなわち、
      今のモードを示す「要請」を送らないかもしれません。

      b. If a party receives what appears to be a request to enter some
      mode it is already in, the request should not be acknowledged.
      This non-response is essential to prevent endless loops in the
      negotiation.  It is required that a response be sent to requests
      for a change of mode -- even if the mode is not changed.
      b. もしすでにそのモードになっているモードに入る要請と思われるもの
      を受け取るなら、要請に確認をすべきではありません。この非応答は交渉
      で果てしないループを防ぐために不可欠です。モード変更の要請に応答は
      要求されます−たとえモードが変わらなくても。

      c. Whenever one party sends an option command to a second party,
      whether as a request or an acknowledgment, and use of the option
      will have any effect on the processing of the data being sent from
      the first party to the second, then the command must be inserted
      in the data stream at the point where it is desired that it take
      effect.  (It should be noted that some time will elapse between
      the transmission of a request and the receipt of an
      acknowledgment, which may be negative.  Thus, a host may wish to
      buffer data, after requesting an option, until it learns whether
      the request is accepted or rejected, in order to hide the
      "uncertainty period" from the user.)
      c. 一方が他方にオプションコマンドを送る時はいつでも、要請か確認か
      によらず、送ってるデータにデータ処理へのオプション使用の影響に関わ
      らず、コマンドが効力を発する事が切望される要点のデータ流に挿入され
      なくてはなりません。(要請を転送してから、否定的なのを含む、確認ま
      で時間が経過することが指摘されます。それで、ホストは要請を送った後
      要請が確認されたか拒否されたか知るまで、ユーザに「不確定期間」を隠
      すために、データをバッファに入れることを望むかもしれません)。

   Option requests are likely to flurry back and forth when a TELNET
   connection is first established, as each party attempts to get the
   best possible service from the other party.  Beyond that, however,
   options can be used to dynamically modify the characteristics of the
   connection to suit changing local conditions.  For example, the NVT,
   as will be explained later, uses a transmission discipline well
   suited to the many "line at a time" applications such as BASIC, but
   poorly suited to the many "character at a time" applications such as
   NLS.  A server might elect to devote the extra processor overhead
   required for a "character at a time" discipline when it was suitable
   for the local process and would negotiate an appropriate option.
   However, rather than then being permanently burdened with the extra
   processing overhead, it could switch (i.e., negotiate) back to NVT
   when the detailed control was no longer necessary.
   オプション要請は、TELNET接続が最初に確立される時に、各パーティ
   が他パーティから最良の可能なサービスを得ようと試みるため、行われる可
   能性が高いです。それ以降も、しかしながら、オプションがダイナミックに
   接続の特徴を修正するために、ローカル状態の変更を要求するため、使うこ
   とができます。例えば、NVTは、後に説明するように、BASICのよう
   な多くの「1度に1行」アプリケーションで適切な送信規則を使いますが、
   NLSのような多くの「1度に1文字」アプリケーションに不完全です。サー
   バは「1度に1文字」規則のために捧げる余分のプロセッサオーバーヘッド
   を選ぶかも知れず、適切なオプション交渉を要求します。しかしながら、永
   久に余分の処理オーバーヘッドで悩ませられるより、詳細な制御がもう必要
   でない時NVTに切り替えることができます(すなわち、交渉します)。

   It is possible for requests initiated by processes to stimulate a
   nonterminating request loop if the process responds to a rejection by
   merely re-requesting the option.  To prevent such loops from
   occurring, rejected requests should not be repeated until something
   changes.  Operationally, this can mean the process is running a
   different program, or the user has given another command, or whatever
   makes sense in the context of the given process and the given option.
   A good rule of thumb is that a re-request should only occur as a
   result of subsequent information from the other end of the connection
   or when demanded by local human intervention.
   プロセスによって始められた要請が、もしプロセスがただ選択を再度要求す
   ることで拒絶応答をするなら、終了しない要請ループを起こすことが可能で
   す。このようなループが存在するのを阻止するために、拒絶された要請は、
   何かが変化するまで、繰り返されるべきではありません。操作上、これはプ
   ロセスが異なったプログラムを動かすか、ユーザが異なるコマンドを与えた
   か、与えられたプロセスやオプションの状況で意味をなす何かを意味します。
   経験的に再要請は、他の接続の終端からの情報の結果か、ローカルな人間の
   干渉によってだけ起こるべきということです。

   Option designers should not feel constrained by the somewhat limited
   syntax available for option negotiation.  The intent of the simple
   syntax is to make it easy to have options -- since it is
   correspondingly easy to profess ignorance about them.  If some
   particular option requires a richer negotiation structure than
   possible within "DO, DON'T, WILL, WON'T", the proper tack is to use
   "DO, DON'T, WILL, WON'T" to establish that both parties understand
   the option, and once this is accomplished a more exotic syntax can be
   used freely.  For example, a party might send a request to alter
   (establish) line length.  If it is accepted, then a different syntax
   can be used for actually negotiating the line length -- such a
   "sub-negotiation" might include fields for minimum allowable, maximum
   allowable and desired line lengths.  The important concept is that
   such expanded negotiations should never begin until some prior
   (standard) negotiation has established that both parties are capable
   of parsing the expanded syntax.
   オプションデザイナーがオプション交渉で可能な幾分限定された文法によっ
   て制約を受けているように感じるべきではありません。単純な文法の意図は
   オプションを持つことを容易にする事です−それらを無視することが比較的
   容易である時からです。もしある特定のオプションが「DO, DON'T, WILL,
   WON'T」で可能なのより豊かな交渉構造体を必要とするなら、適切な方針は
   「DO, DON'T, WILL, WON'T」を使って両者がオプションを理解することを確
   認し、これが達成されてからよりエキゾチックな文法を自由に使います。例
   えば、(確定した)行長を変える要請を送るかもしれません。もしこれが受
   け入れられるなら、異なった文法が実際に行長を交渉するのに使うことがで
   きます−このような「副交渉」は最小許容、最大許容、望ましい行長のフィー
   ルドを含むかもしれません。重要な概念はこのような拡大された交渉が決し
   て、ある事前の(標準)交渉で両者が文法解析を確認するまで、始まるべき
   ではないということです。

   In summary, WILL XXX is sent, by either party, to indicate that
   party's desire (offer) to begin performing option XXX, DO XXX and
   DON'T XXX being its positive and negative acknowledgments; similarly,
   DO XXX is sent to indicate a desire (request) that the other party
   (i.e., the recipient of the DO) begin performing option XXX, WILL XXX
   and WON'T XXX being the positive and negative acknowledgments.  Since
   the NVT is what is left when no options are enabled, the DON'T and
   WON'T responses are guaranteed to leave the connection in a state
   which both ends can handle.  Thus, all hosts may implement their
   TELNET processes to be totally unaware of options that are not
   supported, simply returning a rejection to (i.e., refusing) any
   option request that cannot be understood.
   まとめると、オプションXXXをはじめたい側が要望(提案)を示すためWILL
   XXXを送り、DO XXXとDON'T XXXがその肯定応答と否定応答です;同様に他者
   (受信側)のオプションXXXを実行を要望(提案)するためDO XXXを送り、
   WILL XXX and WON'T XXXがその肯定応答と否定応答です。オプションが使用
   可能ではない時、NVTが残るものなので、DON'TとWON'T応答は接続を両端
   が扱うことができる状態を残すことを保証します。それで、すべてのホスト
   は理解できないオプションの要請に単純に拒否(すなわち、拒否する)を返
   して、サポートされないオプションにまったく気が付かないTELNETプ
   ロセスを実装してもよいです。

   As much as possible, the TELNET protocol has been made server-user
   symmetrical so that it easily and naturally covers the user-user
   (linking) and server-server (cooperating processes) cases.  It is
   hoped, but not absolutely required, that options will further this
   intent.  In any case, it is explicitly acknowledged that symmetry is
   an operating principle rather than an ironclad rule.
   可能な限り、TELNETプロトコルは、容易にユーザ−ユーザ(リンク)
   やサーバ−サーバ(プロセス協調)に対応するように、ツーザ−サーバを対
   称的に作りました。将来のオプションがこの意志を継ぐことは望まれますが、
   絶対的に必要ではありません。どんなケースででも、対称が厳しい規則と言
   うより、運営上原則で、明示的応答確認が出されます。

   A companion document, "TELNET Option Specifications," should be
   consulted for information about the procedure for establishing new
   options.
   関連文書、「TELNETオプション仕様」、が新しいオプションを確立す
   る手続きについての情報のために調べられるべきです。

THE NETWORK VIRTUAL TERMINAL
ネットワーク仮想端末

   The Network Virtual Terminal (NVT) is a bi-directional character
   device.  The NVT has a printer and a keyboard.  The printer responds
   to incoming data and the keyboard produces outgoing data which is
   sent over the TELNET connection and, if "echoes" are desired, to the
   NVT's printer as well.  "Echoes" will not be expected to traverse the
   network (although options exist to enable a "remote" echoing mode of
   operation, no host is required to implement this option).  The code
   set is seven-bit USASCII in an eight-bit field, except as modified
   herein.  Any code conversion and timing considerations are local
   problems and do not affect the NVT.
   ネットワーク仮想端末(NVT)は双方向性が特徴の装置です。NVTはプ
   リンターとキーボードを持っています。プリンタは入力データに応答し、
   キーボードはTELNET接続上で送られるデータを生成し、もし「エコー」
   が要請されたら、同様に、NVTのプリンターに、切望されるなら送られる
   外向的なデータを引き起こします。「エコー」はネットワークを通過しない
   ことが期待されます(「遠隔」エコーモードを可能にするためのオプション
   があるが、ホストがこのオプションを実装するように要求されません)。
   コードセットは、ここで修正される以外は、8ビットフィールドで7ビット
   のUSASCIIです。コード変換とタイミングの考慮がローカルな問題であり、
   NVTに影響を与えません。

   TRANSMISSION OF DATA
   データの伝達

      Although a TELNET connection through the network is intrinsically
      full duplex, the NVT is to be viewed as a half-duplex device
      operating in a line-buffered mode.  That is, unless and until
      options are negotiated to the contrary, the following default
      conditions pertain to the transmission of data over the TELNET
      connection:
      ネットワークを通してのTELNET接続が本質的に全二重であるが、
      NVT行バッファモードで運用する半二重の装置だと見なされるはずで
      す。すなわち、オプションが反対に交渉されるまで、次のデフォルト条
      件がTELNET接続上のデータの送信に関係します:

         1)  Insofar as the availability of local buffer space permits,
         data should be accumulated in the host where it is generated
         until a complete line of data is ready for transmission, or
         until some locally-defined explicit signal to transmit occurs.
         This signal could be generated either by a process or by a
         human user.
         1)  ローカルなバッファ空間が許す限り、完全な1行のデータが送
         信のために準備でるか、信号を送るローカルに定義された明白な信
         号が起こるまで、データが、生成されるホストで蓄積されるべきで
         す。このシグナルはプロセスや人間のユーザーによって生成できま
         す。

         The motivation for this rule is the high cost, to some hosts,
         of processing network input interrupts, coupled with the
         default NVT specification that "echoes" do not traverse the
         network.  Thus, it is reasonable to buffer some amount of data
         at its source.  Many systems take some processing action at the
         end of each input line (even line printers or card punches
         frequently tend to work this way), so the transmission should
         be triggered at the end of a line.  On the other hand, a user
         or process may sometimes find it necessary or desirable to
         provide data which does not terminate at the end of a line;
         therefore implementers are cautioned to provide methods of
         locally signaling that all buffered data should be transmitted
         immediately.
         この規則の動機は、あるホストにとって、ネットワーク入力割込み処
         理の高コストと、「エコー」がネットワークを通らないというデフォ
         ルトNVT仕様からです。それで、情報がでデータの量をバッファす
         ることが合理的です。多くのシステムが入力行の終わりで何かの処理
         をします(ラインプリンタやカードパンチさえしばしばこのように作
         動する傾向があります)、それで行の終わりで送信が起るべきです。
         他方、ユーザーあるいはプロセスが時々行の終わりで終わらないデー
         タを供給する必要があるか、あるいは望ましいことを見いだすかもし
         れません;それ故に実装者がローカルにすべてのバッファに入れられ
         たデータがすぐに伝達されるべきと合図する方法を供給するように注
         意されます。

         2)  When a process has completed sending data to an NVT printer
         and has no queued input from the NVT keyboard for further
         processing (i.e., when a process at one end of a TELNET
         connection cannot proceed without input from the other end),
         the process must transmit the TELNET Go Ahead (GA) command.
         2)  プロセスがNVTプリンターにデータを送り終わり、NVTキー
         ボードから待ち行列に入れられた入力なしに、これ以上の処理がない
         時(すなわち、TELNET接続の一方のプロセスが他から入力無し
         で先に進めない時)、プロセスはTELNET Go Ahead(GA)コマン
         ドを送信しなくてはなりません。

         This rule is not intended to require that the TELNET GA command
         be sent from a terminal at the end of each line, since server
         hosts do not normally require a special signal (in addition to
         end-of-line or other locally-defined characters) in order to
         commence processing.  Rather, the TELNET GA is designed to help
         a user's local host operate a physically half duplex terminal
         which has a "lockable" keyboard such as the IBM 2741.  A
         description of this type of terminal may help to explain the
         proper use of the GA command.
         この規則は、サーバーホストが通常処理の開始に特別な信号(行終了
         や他のローカルに定義された文字の追加)を必要としないので、TELNET
         GAコマンドが各行の終わりに端末から送られることを要求するように
         意図されません。どちらかと言うとTELNET GAはユーザーのローカルホ
         ストがIBM 2741のような「ロック可能」キーボードを持つ物理的に半
         二重の端末を操作するのを手伝うよう意図されます。このタイプの端
         末の記述がGAコマンドの適切な使用を説明するのを手伝うかもしれま
         せん。

         The terminal-computer connection is always under control of
         either the user or the computer.  Neither can unilaterally
         seize control from the other; rather the controlling end must
         relinguish its control explicitly.  At the terminal end, the
         hardware is constructed so as to relinquish control each time
         that a "line" is terminated (i.e., when the "New Line" key is
         typed by the user).  When this occurs, the attached (local)
         computer processes the input data, decides if output should be
         generated, and if not returns control to the terminal.  If
         output should be generated, control is retained by the computer
         until all output has been transmitted.
         端末コンピュータ接続は常にユーザーあるいはコンピュータの制御の
         下にあります。いずれも一方的に他から制御を奪うことができません;
         それよりも、制御側が明示的にその制御を放棄しなくてはなりません。
         端末において、ハードウェアは「行」が終了する毎に制御を放棄する
         ように構成されます(すなわち、「ニュー・ライン」キーがユーザー
         によってタイプされる時)。これが起こる時、接続(ローカル)コン
         ピュータは入力データを処理し、出力が生成されるべきであるかどう
         か決め、もしそうでなければ端末に制御を返します。もし出力が生成
         されたら、すべての出力が伝達されるまで、制御がコンピュータによっ
         て維持されます。

         The difficulties of using this type of terminal through the
         network should be obvious.  The "local" computer is no longer
         able to decide whether to retain control after seeing an
         end-of-line signal or not; this decision can only be made by
         the "remote" computer which is processing the data.  Therefore,
         the TELNET GA command provides a mechanism whereby the "remote"
         (server) computer can signal the "local" (user) computer that
         it is time to pass control to the user of the terminal.  It
         should be transmitted at those times, and only at those times,
         when the user should be given control of the terminal.  Note
         that premature transmission of the GA command may result in the
         blocking of output, since the user is likely to assume that the
         transmitting system has paused, and therefore he will fail to
         turn the line around manually.
         ネットワークを通してこの種の端末を使う難しさは明白になるべきで
         す。「ローカル」コンピュータはもう「行末」シグナルを見た後で制
         御を維持するべきかどうか決めることが可能ではありません;この決
         断はただデータを処理している「遠隔」コンピュータによってされる
         ことができるだけです。それ故に、「遠隔」(サーバ)コンピュータ
         が「ローカル」(ユーザ)コンピュータに端末ユーザに制御を手渡す
         時間であるという信号を送ることができるメカニズムTELNET GAコマン
         ドを供給します。これはこの時に、そしてこの時にだけ伝達されるべ
         きで、その時ユーザに端末制御を与えられるべきです。GAコマンドの
         早すぎる送信が出力を阻止するかもしれず、ユーザが信号を送ってい
         るシステムが中断したと考える可能性が高いので、それ故に彼が手作
         業で回線を切る可能性が高いことに注意してください。

      The foregoing, of course, does not apply to the user-to-server
      direction of communication.  In this direction, GAs may be sent at
      any time, but need not ever be sent.  Also, if the TELNET
      connection is being used for process-to-process communication, GAs
      need not be sent in either direction.  Finally, for
      terminal-to-terminal communication, GAs may be required in
      neither, one, or both directions.  If a host plans to support
      terminal-to-terminal communication it is suggested that the host
      provide the user with a means of manually signaling that it is
      time for a GA to be sent over the TELNET connection; this,
      however, is not a requirement on the implementer of a TELNET
      process.
      前述は、もちろん、ユーザーからサーバーへの方向の通信には適用しませ
      ん。この方向で、GAがいつでも送られるかもしれませんが、送る必要があ
      りません。同じく、もしTELNET接続がプロセスからプロセスへの通
      信に使われるなら、GAはいずれかの方向ででも送る必要がありません。最
      後に、端末から端末への通信のために、一方向にも双方向にも、GAが必要
      ありません。もしホストが端末から端末への通信をサポートすることを計
      画するなら、ホストが手作業でTELNET接続上でGAを送る時間である
      と合図する手段をユーザーに提供することが提案されます、これは、しか
      しながら、TELNETプロセスの実装上の必要条件ではありません。

      Note that the symmetry of the TELNET model requires that there is
      an NVT at each end of the TELNET connection, at least
      conceptually.
      TELNETモデルの対称が、少なくとも概念的に、それぞれのTELN
      ET接続の終わりにNVTがあることを要求することを注意を払ってくだ
      さい。

   STANDARD REPRESENTATION OF CONTROL FUNCTIONS
   制御機能の標準表現

      As stated in the Introduction to this document, the primary goal
      of the TELNET protocol is the provision of a standard interfacing
      of terminal devices and terminal-oriented processes through the
      network.  Early experiences with this type of interconnection have
      shown that certain functions are implemented by most servers, but
      that the methods of invoking these functions differ widely.  For a
      human user who interacts with several server systems, these
      differences are highly frustrating.  TELNET, therefore, defines a
      standard representation for five of these functions, as described
      below.  These standard representations have standard, but not
      required, meanings (with the exception that the Interrupt Process
      (IP) function may be required by other protocols which use
      TELNET); that is, a system which does not provide the function to
      local users need not provide it to network users and may treat the
      standard representation for the function as a No-operation.  On
      the other hand, a system which does provide the function to a
      local user is obliged to provide the same function to a network
      user who transmits the standard representation for the function.
      この文書のはじめにで述べられるように、TELNETプロトコルの主な
      ゴールは、端末装置の標準接続と、ネットワークを通しての端末指向のプ
      ロセスの準備とです。この種の相互接続の初期の経験がある特定の機能が
      たいていのサーバーに実装されるが、これらの機能を呼び出す方法が広く
      異なることを示しました。いくつかのサーバーシステムと相互に作用する
      人間のユーザーのために、これらの相違は大いに失望です。TELNET
      は、従って、下に記述されるように、これらの機能の5つ標準的な表現を
      定義します。標準表現が標準的だが、必須ではない、意味を持ちます(例
      外的に、割り込みプロセス(IP)機能がTELNETを使う他のプロト
      コルで必要かもしれません)、すなわち、ローカルユーザに機能を供給し
      ないシステムがネットワークユーザにも供給する必要がなく、機能の標準
      表現を無視するかもしれません。他方、ローカルユーザに機能を供給する
      システムが、機能の標準表現を送ってくるネットワークユーザに同じ機能
      を供給しなければなりません。

      Interrupt Process (IP)
      割り込みプロセス(IP)

         Many systems provide a function which suspends, interrupts,
         aborts, or terminates the operation of a user process.  This
         function is frequently used when a user believes his process is
         in an unending loop, or when an unwanted process has been
         inadvertently activated.  IP is the standard representation for
         invoking this function.  It should be noted by implementers
         that IP may be required by other protocols which use TELNET,
         and therefore should be implemented if these other protocols
         are to be supported.
         多くのシステムがユーザープロセスの処理の中断や割込みや中止や停
         止機能を供給します。この機能は、ユーザが自分のプロセスが無限ルー
         プになったり、意図しないプロセスが活性化されたと信じる時に、頻
         繁に使われます。IPはこの機能を呼び出す標準表現です。IPがT
         ELNETを使う他のプロトコルに必要かもしれなくて、従ってこれ
         らの他のプロトコルがサポートされるなら実装されるべきである事を、
         実装者に指摘します。

      Abort Output (AO)
      出力中止(AO)

         Many systems provide a function which allows a process, which
         is generating output, to run to completion (or to reach the
         same stopping point it would reach if running to completion)
         but without sending the output to the user's terminal.
         Further, this function typically clears any output already
         produced but not yet actually printed (or displayed) on the
         user's terminal.  AO is the standard representation for
         invoking this function.  For example, some subsystem might
         normally accept a user's command, send a long text string to
         the user's terminal in response, and finally signal readiness
         to accept the next command by sending a "prompt" character
         (preceded by <CR><LF>) to the user's terminal.  If the AO were
         received during the transmission of the text string, a
         reasonable implementation would be to suppress the remainder of
         the text string, but transmit the prompt character and the
         preceding <CR><LF>.  (This is possibly in distinction to the
         action which might be taken if an IP were received; the IP
         might cause suppression of the text string and an exit from the
         subsystem.)
         多くのシステムが、プロセスが出力を生成し実行が完了する(あるい
         はある停止ポイントに達する)が、ユーザ端末に出力しないままでい
         る機能を供給します。さらに、この機能は一般に、生成されたがまだ
         ユーザ端末上に印刷(又は表示)されていない出力をクリアします。
         AOはこの機能を呼び出す標準表現です。例えば、いずれかのサブシ
         ステムが通常ユーザーのコマンドを受け入れて、応答でユーザ端末に
         長いテキスト文字列を送って、そして、ユーザ端末に(<CR><LF>で始
         まる)「プロンプト」文字を送ることにで、次のコマンドを受け入れ
         る用意を示すかもしれません。AOをテキスト文字列の送信の間に受
         信すると、合理的な実装がテキスト文字列の残りを抑制しますが、
         <CR><LF>とプロンプト文字を送ります。(これは、もしIPを受信し
         た場合にとるかもしれない行動と多分異なります;IPはテキスト文
         字列の抑圧とサブシステムからの退場を起こすかもしれません)。

         It should be noted, by server systems which provide this
         function, that there may be buffers external to the system (in
         the network and the user's local host) which should be cleared;
         the appropriate way to do this is to transmit the "Synch"
         signal (described below) to the user system.
         この機能を供給するサーバーシステムは、システムの外部にバッファ
         があるかもしれなくて(ネットワークとユーザローカルホストに)、
         これをクリアするべきです;これをする適切な方法はユーザーシステ
         ムに(下に記述された)「Synch」シグナルを伝達することです。

      Are You There (AYT)
      そこにいますか(AYT)

         Many systems provide a function which provides the user with
         some visible (e.g., printable) evidence that the system is
         still up and running.  This function may be invoked by the user
         when the system is unexpectedly "silent" for a long time,
         because of the unanticipated (by the user) length of a
         computation, an unusually heavy system load, etc.  AYT is the
         standard representation for invoking this function.
         多くのシステムが、システムがまだ起きていて動作しているのを示す、
         目に見える証拠(つまり印刷可能な)をユーザに供給する機能を供給
         します。この機能は、(ユーザが)予期しない計算時間や、異常に重
         いシステム負荷などによって、システムが長時間予期せぬ「無言」で
         あるときに、ユーザーによって呼び出されるかもしれません。AYT
         はこの機能を呼び出す標準表現です。

      Erase Character (EC)
      消去文字(EC)

         Many systems provide a function which deletes the last
         preceding undeleted character or "print position"* from the
         stream of data being supplied by the user.  This function is
         typically used to edit keyboard input when typing mistakes are
         made.  EC is the standard representation for invoking this
         function.
         多くのシステムがユーザが供給したデータストリームから最後の前に
         削除されていない文字を削除する機能あるいは「印刷位置」*機能を供
         給します。この機能は、典型的にタイピングミスをした時、編集キー
         ボード入力で使われます。ECはこの機能を呼び出す標準表現です。

            *NOTE:  A "print position" may contain several characters
            which are the result of overstrikes, or of sequences such as
            <char1> BS <char2>...
            *ノート:「印刷位置」がいくつかの文字を含むかもしれず、重ね
            打ちや、<char1> BS <char2>...の様な列を発生します。

      Erase Line (EL)
      行消去(EL)

         Many systems provide a function which deletes all the data in
         the current "line" of input.  This function is typically used
         to edit keyboard input.  EL is the standard representation for
         invoking this function.
         多くのシステムが現在の入力「行」のすべてのデータを削除する機
         能を供給します。この機能は典型的に編集キーボード入力で使われ
         ます。ELはこの機能を呼び出す標準表現です。

   THE TELNET "SYNCH" SIGNAL
   TELNET同期信号

      Most time-sharing systems provide mechanisms which allow a
      terminal user to regain control of a "runaway" process; the IP and
      AO functions described above are examples of these mechanisms.
      Such systems, when used locally, have access to all of the signals
      supplied by the user, whether these are normal characters or
      special "out of band" signals such as those supplied by the
      teletype "BREAK" key or the IBM 2741 "ATTN" key.  This is not
      necessarily true when terminals are connected to the system
      through the network; the network's flow control mechanisms may
      cause such a signal to be buffered elsewhere, for example in the
      user's host.
      たいていのタイムシェアリングシステムが端末ユーザに「暴走」プロセス
      の制御を取り戻すことを可能にするメカニズムを供給します;上に記述さ
      れたIPとAO機能はこれらのメカニズムの例です。このようなシステム
      は、ローカルに使われる時、ユーザによって供給されたシグナルのすべて
      にアクセスを持ちます、これらが標準的な文字であったり、テレタイプ
      「ブレーク」キーやIBM2741の「ATTN」のキーのように特別な
      「アウトバンド」あったりします。これは、端末がネットワークを通して
      システムに接続している時、必ずしも真ではありません;ネットワークの
      フロー制御装置メカニズムはこのようなシグナルを、例えばユーザホスト
      で、バッファするかもしれません。

      To counter this problem, the TELNET "Synch" mechanism is
      introduced.  A Synch signal consists of a TCP Urgent notification,
      coupled with the TELNET command DATA MARK.  The Urgent
      notification, which is not subject to the flow control pertaining
      to the TELNET connection, is used to invoke special handling of
      the data stream by the process which receives it.  In this mode,
      the data stream is immediately scanned for "interesting" signals
      as defined below, discarding intervening data.  The TELNET command
      DATA MARK (DM) is the synchronizing mark in the data stream which
      indicates that any special signal has already occurred and the
      recipient can return to normal processing of the data stream.
      この問題に対処するために、TELNET「Synch」メカニズムが導入さ
      れます。Synch信号がTELNETコマンドDATA MARKと結び付けられた
      TCP緊急通知から成り立ちます。TELNET接続に関してフロー制
      御の適用を受けていない緊急通知は、それを受け取るプロセスにデータ
      流の特別扱いを呼び出すために使われます。このモードで、間のデータ
      を捨て、下に定義される「面白い」シグナルに対するデータ流がすぐに
      走査されます。TELNETコマンドDATA MARK(DM)はデータ流の同期
      マークで、特別なシグナルすでに生じていて、受信者がデータ流の標準的
      な処理に戻ることができます。

         The Synch is sent via the TCP send operation with the Urgent
         flag set and the DM as the last (or only) data octet.
         SynchはTCP送信オペレーションで緊急フラグ設定で送られ、DMは最
         後の(又は唯一の)データオクテットとして送られます。

      When several Synchs are sent in rapid succession, the Urgent
      notifications may be merged.  It is not possible to count Urgents
      since the number received will be less than or equal the number
      sent.  When in normal mode, a DM is a no operation; when in urgent
      mode, it signals the end of the urgent processing.
      いくつかのSynchが連続して送られる時、緊急通知は統合されるかもしれ
      ません。緊急通知の受信数は送信数以下なので、緊急通知の数を数える事
      はできません。標準モードで、DMは何もしません;緊急モードでDMは緊急
      処理の終わりを示します。

         If TCP indicates the end of Urgent data before the DM is found,
         TELNET should continue the special handling of the data stream
         until the DM is found.
         もしTCPが、DMが見つかる前に、緊急データの終わりを示すなら、TE
         LNETが、DMが見つかるまでデータ流の特別扱いを続けるべきです。

         If TCP indicates more Urgent data after the DM is found, it can
         only be because of a subsequent Synch.  TELNET should continue
         the special handling of the data stream until another DM is
         found.
         もしTCPが、DMが見つかった後も、緊急データを示すなら、それは
         次のSynchのためです。TELNETが、もう1つのDMが見つかるまで、
         データ流の特別扱いを続けるべきです。

      "Interesting" signals are defined to be:  the TELNET standard
      representations of IP, AO, and AYT (but not EC or EL); the local
      analogs of these standard representations (if any); all other
      TELNET commands; other site-defined signals which can be acted on
      without delaying the scan of the data stream.
      「面白い」シグナルが以下に定義されます:IPとAOとAYTのTEL
      NET標準表現(ECとELは含まない);これらの標準表現のローカル
      な類似物;すべての他のTELNETコマンド;データ流走査を遅らせず
      に作用する他のサイトで定義した信号。

      Since one effect of the SYNCH mechanism is the discarding of
      essentially all characters (except TELNET commands) between the
      sender of the Synch and its recipient, this mechanism is specified
      as the standard way to clear the data path when that is desired.
      For example, if a user at a terminal causes an AO to be
      transmitted, the server which receives the AO (if it provides that
      function at all) should return a Synch to the user.
      SYNCHメカニズムの1つの効果がSynch送信者と受信者間で(TELNET
      コマンド以外)本質的にすべて文字を捨てることであるので、このメカニ
      ズムはデータパスをきれいにする標準的方法として明示されます。例えば、
      もし端末のユーザーがAOを送るなら、AOを受け取るサーバは(もしそ
      の機能を供給するなら)、ユーザにSynchを返すべきです。

      Finally, just as the TCP Urgent notification is needed at the
      TELNET level as an out-of-band signal, so other protocols which
      make use of TELNET may require a TELNET command which can be
      viewed as an out-of-band signal at a different level.
      最後に、TCP緊急の通知がTELNETレベルでアウトバンド信号とし
      て必要なので、TELNETを利用する他のプロトコルが異なるレベルの
      アウトバンド信号と見なせるTELNETコマンドを明示的に必要とする
      かもしれません。

      By convention the sequence [IP, Synch] is to be used as such a
      signal.  For example, suppose that some other protocol, which uses
      TELNET, defines the character string STOP analogously to the
      TELNET command AO.  Imagine that a user of this protocol wishes a
      server to process the STOP string, but the connection is blocked
      because the server is processing other commands.  The user should
      instruct his system to:
      取り決めをする事で、[IP、Synch]の連続がこのようなシグナルとし
      て用れるはずです。例えば、TELNETを使う何か他のプロトコルが文
      字列STOPをTELNETコマンドAOに同様に定義すると考えてくだ
      さい。このプロトコルのユーザがサーバがSTOP文字列を処理すること
      を望むが、接続が、サーバが他のコマンドを処理しているから、阻止され
      ると想像してください。ユーザはシステムに以下に指示するべきです:

         1. Send the TELNET IP character;
         1. TELNET IP文字を送信;

         2. Send the TELNET SYNC sequence, that is:
         2. 以下のTELNET SYNCの連続を送信:

            Send the Data Mark (DM) as the only character
            in a TCP urgent mode send operation.
            TCP緊急のモード送信オペレーションで唯一の文字とし
            てデータマーク(DM)を送信

         3. Send the character string STOP; and
         3. 文字列STOPを送信;そして

         4. Send the other protocol's analog of the TELNET DM, if any.
         4. もしあれば、他のプロトコルのTELNET DM同様のものを送信

      The user (or process acting on his behalf) must transmit the
      TELNET SYNCH sequence of step 2 above to ensure that the TELNET IP
      gets through to the server's TELNET interpreter.
      ユーザ(あるいは彼の代理として動くプロセス)はサーバのTELNE
      TインタプリタがTELNET IPを得ることを保証するため、ステッ
      プ2のTELNET SYNCHの連続を送信しなくてはなりません。

         The Urgent should wake up the TELNET process; the IP should
         wake up the next higher level process.
         緊急通知はTELNETプロセスを目ざめさせるべきです;IPは次
         の上位レベルのプロセスを目ざめさせるべきです。

   THE NVT PRINTER AND KEYBOARD
   NVTプリンターとキーボード

      The NVT printer has an unspecified carriage width and page length
      and can produce representations of all 95 USASCII graphics (codes
      32 through 126).  Of the 33 USASCII control codes (0 through 31
      and 127), and the 128 uncovered codes (128 through 255), the
      following have specified meaning to the NVT printer:
      NVTプリンタは特定されていない幅とページ長さを持ち、そしてすべて
      の95のUSASCII図形(コード32から126まで)の表示を作り出すこ
      とができます。33のUSASCII制御コード(0から31までと127)と
      128の対応していないコード(128から255まで)について、次の
      様にNVTプリンターでの意味を指定します:

         NAME                  CODE         MEANING
         名前                  コード       意味

         NULL (NUL)              0      No Operation
                                        操作なし
         Line Feed (LF)         10      Moves the printer to the
                                        next print line, keeping the
                                        same horizontal position.
                                        水平位置を保持して、次の印刷行に
                                        プリンタを動かします。
         Carriage Return (CR)   13      Moves the printer to the left
                                        margin of the current line.
                                        現在の行の左にプリンタを動かしま
                                        す。

         In addition, the following codes shall have defined, but not
         required, effects on the NVT printer.  Neither end of a TELNET
         connection may assume that the other party will take, or will
         have taken, any particular action upon receipt or transmission
         of these:
         さらに、NVTプリンターに対する以下のコードが、必須ではないが、
         定義さます。どちらのTELNET接続端も、これらを受信した相手
         が特定の動作をすると考えるべきです:

         BELL (BEL)              7      Produces an audible or
                                        visible signal (which does
                                        NOT move the print head).
                                        聞こえるか、目に見えるシグナル
                                        を作り出します(プリンタヘッド
                                        は動かしません)。
         Back Space (BS)         8      Moves the print head one
                                        character position towards
                                        the left margin.
                                        プリンタヘッド位置を1文字左端
                                        マージンに向かって動かします。
         Horizontal Tab (HT)     9      Moves the printer to the
                                        next horizontal tab stop.
                                        It remains unspecified how
                                        either party determines or
                                        establishes where such tab
                                        stops are located.
                                        プリンタを次の水平なタブ位置に
                                        動かします。だれがこのようなタ
                                        ブ位置を決定するか、あるいは設
                                        定するかは特定されていないまま
                                        でいます。
         Vertical Tab (VT)       11     Moves the printer to the
                                        next vertical tab stop.  It
                                        remains unspecified how
                                        either party determines or
                                        establishes where such tab
                                        stops are located.
                                        プリンターを次の縦のタブ・ストッ
                                        プに動かします。だれがこのよう
                                        なタブ・ストップ位置を決定する
                                        か、あるいは設定するかは特定さ
                                        れていないままでいます。
         Form Feed (FF)          12     Moves the printer to the top
                                        of the next page, keeping
                                        the same horizontal position.
                                        同じ水平な位置を保持して、次の
                                        ページの最上部にプリンターを動
                                        かします。

      All remaining codes do not cause the NVT printer to take any
      action.
      すべての残りのコードはNVTプリンターに行動をとらせません。

      The sequence "CR LF", as defined, will cause the NVT to be
      positioned at the left margin of the next print line (as would,
      for example, the sequence "LF CR").  However, many systems and
      terminals do not treat CR and LF independently, and will have to
      go to some effort to simulate their effect.  (For example, some
      terminals do not have a CR independent of the LF, but on such
      terminals it may be possible to simulate a CR by backspacing.)
      Therefore, the sequence "CR LF" must be treated as a single "new
      line" character and used whenever their combined action is
      intended; the sequence "CR NUL" must be used where a carriage
      return alone is actually desired; and the CR character must be
      avoided in other contexts.  This rule gives assurance to systems
      which must decide whether to perform a "new line" function or a
      multiple-backspace that the TELNET stream contains a character
      following a CR that will allow a rational decision.
      「CR LF」の連続は、定義されるように、NVTを次の印刷行の左端マー
      ジンにおきます(例えば、「LF CR」連続と同様)。しかしながら、多く
      のシステムとターミナルが独立してCRとLFを扱わず、それらの効果をシ
      ミュレートするある努力が必要でしょう。(例えば、ある端末がLFなし
      のCRを持たず、このような端末上ではバックスペースによってCRをシミュ
      レートすることは可能かもしれません。)それ故に、「CR LF」連続はひ
      とつの「改行」文字と取り扱われて、それらの結合行動を意図する時は
      いつでも使なくてはなりません;「CR NUL」連続が単独のキャリッジ・
      リターンだけが実際に望ましい所に使いいます;CR文字はは他の文脈で
      避けなくてはなりません。この規則は、「改行」か複数のバックスペー
      スかを決定しなければいけないシステムに、TELNET流がCRの後の
      1文字で合理的な決定を許す保証を与えます。

         Note that "CR LF" or "CR NUL" is required in both directions
         (in the default ASCII mode), to preserve the symmetry of the
         NVT model.  Even though it may be known in some situations
         (e.g., with remote echo and suppress go ahead options in
         effect) that characters are not being sent to an actual
         printer, nonetheless, for the sake of consistency, the protocol
         requires that a NUL be inserted following a CR not followed by
         a LF in the data stream.  The converse of this is that a NUL
         received in the data stream after a CR (in the absence of
         options negotiations which explicitly specify otherwise) should
         be stripped out prior to applying the NVT to local character
         set mapping.
         NVTモデルの対称を維持するため、「CR LF」あるいは「CR NUL」が
         両方向で(デフォルトASCIIモードで)、要求されることに注意を払っ
         てください。文字が実際のプリンターに送られていないある状態があ
         りますが(例えば、遠隔エコーと、送信抑圧モード)、にもかかわら
         ず、一貫性のために、プロトコルが後にLFが続かないCRでNULをデータ
         流に入れる事を要求します。逆に言うと(さもなければ明示的に指定
         するオプション交渉なしで)CRの後に受信したNULを、NVTをローカ
         ル文字セットに変換する前に捨てるべきです。

      The NVT keyboard has keys, or key combinations, or key sequences,
      for generating all 128 USASCII codes.  Note that although many
      have no effect on the NVT printer, the NVT keyboard is capable of
      generating them.
      NVTキーボードはすべての128のUSASCII コードを生成する、キーか、
      キーの組合せか、キー連続を持ちます。多くがNVTプリンターに対する
      効果を持っていないけれども、NVTキーボードがそれらを生み出すこと
      ができることに注意を払ってください。

      In addition to these codes, the NVT keyboard shall be capable of
      generating the following additional codes which, except as noted,
      have defined, but not reguired, meanings.  The actual code
      assignments for these "characters" are in the TELNET Command
      section, because they are viewed as being, in some sense, generic
      and should be available even when the data stream is interpreted
      as being some other character set.
      これらのコードのほかに、NVTキーボードは以下の定義された追加コー
      ドを生成できますが、記載している以外は、意味はないべきです。これ
      らの「文字」のための実際のコード割当てはTELNETコマンド章に
      あります、なぜならそれらは、ある意味、一般的なコマンドで、データ
      流が何か他の文字セットであるとして解釈される時さえ、利用可能であ
      るからです。

      Synch

         This key allows the user to clear his data path to the other
         party.  The activation of this key causes a DM (see command
         section) to be sent in the data stream and a TCP Urgent
         notification is associated with it.  The pair DM-Urgent is to
         have required meaning as defined previously.
         このキーは他者へのデータパスをクリアする事を可能にします。この
         キーの起動はデータ流でDMを(コマンド章参照)送ります、そしてT
         CP緊急の通知がそれと結び付けられます。DM-緊急対が前に定義され
         る意味を必要とします。

      Break (BRK)

         This code is provided because it is a signal outside the
         USASCII set which is currently given local meaning within many
         systems.  It is intended to indicate that the Break Key or the
         Attention Key was hit.  Note, however, that this is intended to
         provide a 129th code for systems which require it, not as a
         synonym for the IP standard representation.
         このコードは、USASCII外の、多くのシステムでローカルな意味を与え
         られたシグナルであるから、供給されます。ブレークキーあるいは注
         意キーが打たれたことを示すことことを意図します。しかしながら、
         これがIP標準表現と同義語ではなく、これを必要とするシステムに
         第129番目のコードを提供するように意図されることを注意を払っ
         てください。

      Interrupt Process (IP)

         Suspend, interrupt, abort or terminate the process to which the
         NVT is connected.  Also, part of the out-of-band signal for
         other protocols which use TELNET.
         NVTが接続してるプロセスを中断か割込みか中止か停止します。同
         じく、TELNETを使う他のプロトコルの、アウトバンド信号の一
         部です。

      Abort Output (AO)

         Allow the current process to (appear to) run to completion, but
         do not send its output to the user.  Also, send a Synch to the
         user.
         走る現在走るのプロセスの完了を許しますが、ユーザに出力を送らな
         いでください。同じく、ユーザーにSynchを送ってください。

      Are You There (AYT)

         Send back to the NVT some visible (i.e., printable) evidence
         that the AYT was received.
         NVTに、AYTを受信した証拠の、目に見えるなにか(すなわち、
         印刷可能)を送る。

      Erase Character (EC)

         The recipient should delete the last preceding undeleted
         character or "print position" from the data stream.
         受信者はデータ流から最後の前のアンデリートされた文字あるいは
         「印刷位置」を削除するべきです。

      Erase Line (EL)

         The recipient should delete characters from the data stream
         back to, but not including, the last "CR LF" sequence sent over
         the TELNET connection.
         受取人はTELNET接続を通して送ったデータストリームから「CR
         LF」まで(CR LF)は含まないの文字を削除すべきです。

      The spirit of these "extra" keys, and also the printer format
      effectors, is that they should represent a natural extension of
      the mapping that already must be done from "NVT" into "local".
      Just as the NVT data byte 68 (104 octal) should be mapped into
      whatever the local code for "uppercase D" is, so the EC character
      should be mapped into whatever the local "Erase Character"
      function is.  Further, just as the mapping for 124 (174 octal) is
      somewhat arbitrary in an environment that has no "vertical bar"
      character, the EL character may have a somewhat arbitrary mapping
      (or none at all) if there is no local "Erase Line" facility.
      Similarly for format effectors:  if the terminal actually does
      have a "Vertical Tab", then the mapping for VT is obvious, and
      only when the terminal does not have a vertical tab should the
      effect of VT be unpredictable.
      これらの「追加」キーとプリンターフォーマットの効果の精神は、それら
      がすでにある「NVT」から「ローカル」へのマッピングの自然な拡張を表
      すべきということです。ちょうどNVTデータバイト68(8進数で10
      4)がローカルコードの「大文字D」にマップされるべきであるように、
      EC文字はローカルな「消去文字」機能にマップされるべきです。さらに、
      124(8進数174)のマッピングが「直立バー」文字を持っていない
      環境で幾分任意であるから、EL文字は、もしローカルな「行消去」機能
      がないなら、幾分任意のマッピング(あるいはマッッピングなし)かもし
      れません。同様にフォーマット効果:もし端末が実際に「縦のタブ」を持っ
      ているなら、VTのマッピングは明白で、そしてただ端末が縦タブを持っ
      ていない時だけVTの効果が予想できないべきです。

TELNET COMMAND STRUCTURE
TELNETコマンド構造体

   All TELNET commands consist of at least a two byte sequence:  the
   "Interpret as Command" (IAC) escape character followed by the code
   for the command.  The commands dealing with option negotiation are
   three byte sequences, the third byte being the code for the option
   referenced.  This format was chosen so that as more comprehensive use
   of the "data space" is made -- by negotiations from the basic NVT, of
   course -- collisions of data bytes with reserved command values will
   be minimized, all such collisions requiring the inconvenience, and
   inefficiency, of "escaping" the data bytes into the stream.  With the
   current set-up, only the IAC need be doubled to be sent as data, and
   the other 255 codes may be passed transparently.
   すべてのTELNETコマンドは少なくとも2バイトの連続から成り立ちま
   す:「コマンドとして翻訳」(IAC)文字と続くコマンドのコード。オプ
   ション交渉を扱っているコマンドは3バイトの連続で、3番目のバイトが参
   照されるオプションのコードです。このフォーマットは、「データ空間」の
   いっそう包括的な使用は−もちろん基本的なNVT交渉によって−されるか
   ら、ストリームの中にデータバイトを「エスケープ」する不都合や非能率を
   必要とするので、予約コマンド値のデータバイトの衝突が最小化されるよう
   に選択されました。現在の設定で、ただIACをデータそして送る場合だけ
   が2倍にされる必要があり、他の255のコードが透過的に送られるために
   ます。

   The following are the defined TELNET commands.  Note that these codes
   and code sequences have the indicated meaning only when immediately
   preceded by an IAC.
   次は定義されたTELNETコマンドです。これらのコードとコードの連続
   が、前にIACがある時だけ、示された意味を持つことに注意を払ってくだ
   さい。

      NAME               CODE              MEANING
      名前               コード            意味

      SE                  240    End of subnegotiation parameters.
                                 副交渉パラメータの終わり。
      NOP                 241    No operation.
                                 オペレーションなし。
      Data Mark           242    The data stream portion of a Synch.
                                 This should always be accompanied
                                 by a TCP Urgent notification.
                                 Synchのデータ流部。これは常にTCP
                                 緊急通知に伴うべきです。
      Break               243    NVT character BRK.
                                 NTV文字BRK。
      Interrupt Process   244    The function IP.
                                 IP機能。
      Abort output        245    The function AO.
                                 AO機能。
      Are You There       246    The function AYT.
                                 AYT機能。
      Erase character     247    The function EC.
                                 EC機能。
      Erase Line          248    The function EL.
                                 EL機能。
      Go ahead            249    The GA signal.
                                 GA信号。
      SB                  250    Indicates that what follows is
                                 subnegotiation of the indicated
                                 option.
                                 次に続のが示されたオプションの副交渉で
                                 あることを示します。
      WILL (option code)  251    Indicates the desire to begin
                                 performing, or confirmation that
                                 you are now performing, the
                                 indicated option.
                                 示されたオプションの能力を発揮し始める
                                 要望、あるいはあなたが今能力を発揮して
                                 いるという確認を示します。
      WON'T (option code) 252    Indicates the refusal to perform,
                                 or continue performing, the
                                 indicated option.
                                 示されたオプションの能力を発揮するか、
                                 あるいは能力を発揮し続けることについて
                                 の拒絶を示します。
      DO (option code)    253    Indicates the request that the
                                 other party perform, or
                                 confirmation that you are expecting
                                 the other party to perform, the
                                 indicated option.
                                 示されたオプションの能力を相手が発揮す
                                 る要請、あるいはあなたが相手が能力を発
                                 揮することを期待しているという確認。
      DON'T (option code) 254    Indicates the demand that the
                                 other party stop performing,
                                 or confirmation that you are no
                                 longer expecting the other party
                                 to perform, the indicated option.
                                 示されたオプションの能力を相手が発揮す
                                 るのをやめるという要求、あるいは相手が
                                 実行することを期待していない確認。
      IAC                 255    Data Byte 255.
                                 データバイト255。

CONNECTION ESTABLISHMENT
接続確立

   The TELNET TCP connection is established between the user's port U
   and the server's port L.  The server listens on its well known port L
   for such connections.  Since a TCP connection is full duplex and
   identified by the pair of ports, the server can engage in many
   simultaneous connections involving its port L and different user
   ports U.
   TELNET TCP接続はユーザーのポートUとサーバポートL間に確立さ
   れます。サーバはこのような接続のために、よく知られているポートLの上
   で聞きます。TCP接続が全二重で、1対のポートによって識別されるので、
   サーバはそのポートLと異なったユーザポートUの多くの同時の接続に従事
   できます。

   Port Assignment
   ポート割り当て

      When used for remote user access to service hosts (i.e., remote
      terminal access) this protocol is assigned server port 23
      (27 octal).  That is L=23.
      遠隔ユーザがサービスホストにアクセスする時(すなわち、遠隔端末アク
      セス)、このプロトコルはサーバーポート23(8進数の27)を割り当
      てられます。L = 23です。

Japanese translation by Ishida So