RFC139 日本語訳

Network Working Group                                      T. O'Sullivan
Request for Comments: 139                                       Raytheon
NIC: 6717                                                     7 May 1971

コメントを求めるワーキンググループT.オサリヴァン要求をネットワークでつないでください: 139 レイセオンNIC: 6717 1971年5月7日

                     Discussion of TELNET Protocol

telnetプロトコルの議論

   The attached discussion is an extension of RFC 137, NIC #6717, and is
   presented to provide useful background to designers and implementers
   to help them interpret the proposed Protocol and evaluate it in
   preparation for further discussion at the Atlantic City meetings.

付属議論は、RFC137、6717年のNIC#拡大であり、彼らがアトランティックシティーのミーティングにおけるさらなる議論に備えて提案されたプロトコルを解釈して、それを評価するのを助けるために役に立つバックグラウンドをデザイナーとimplementersに供給するために提示されます。

   While the views in the discussion represent those of various TELNET
   committee members, they should not be interpreted as being the agreed
   view of committee.  They are the author's understanding of some of
   the arguments and background to the PROTOCOL proposed in the TELNET
   PROTOCOL recommendations.

議論における視点が様々なTELNET委員のものを表している間、委員会の同意された視点であるので彼らを解釈するべきではありません。 それらは作者のテルネット・プロトコル推薦で提案されたプロトコルへの議論といくつかのバックグラウンドの理解です。

   *  See Footnotes to attached discussion for changes to RFC 137.

* RFC137への変化のための付属議論へのFootnotesを見てください。

Discussion of TELNET PROTOCOL

テルネット・プロトコルの議論

   The use of a standard, network-wide, intermediate representation of
   terminal code between sites eliminates the need for using and serving
   sites to keep information about the characteristics of each other's
   terminals and terminal handling conventions, but only if the user,
   the using site, and the serving site assume certain responsibilities.

ユーザ、使用サイト、および給仕サイトが、ある責任を負う場合にだけ、サイトの間の端末のコードの標準的、そして、ネットワーク全体的、そして、中間的な表現の使用は互いの端末と端末の取り扱い規約の特性の情報を保つサイトを使用して、役立つ必要性を排除します。

      1. The serving site must specify how the intermediate code will be
         mapped by it into the terminal codes that are expected at that
         site.

1. 給仕サイトは中間コードがそれによってどうそのサイトで予想される端末のコードに写像されるかを指定しなければなりません。

      2. The user must be familiar with that mapping.

2. ユーザはそのマッピングに詳しいに違いありません。

      3. The using site must provide some means for the user to enter
         all of the intermediate codes, and as a convenience, special
         control signals, as well as specify for the user how the
         signals from the serving site will be presented at the user
         terminal.

3. 使用サイトは中間コードのすべてに入るユーザ、および便利としていくつかの手段を提供しなければなりません、と特別なコントロールは給仕サイトからの信号がユーザ端末にどう提示されるかをユーザに指定するのと同じくらいよく示します。

   Other schemes were considered but rejected.  For example, a proposal
   that the using site be responsible to transmit to and from the code
   expected by the serving site was rejected since it required that the
   using site keep tables of all serving site codes and provide mapping
   for each case.  The information would require constant maintenance as
   new hosts were added to the network.

他の体系は、考えられましたが、拒絶されました。 例えば、使用サイトがすべての給仕サイトコードのテーブルを保って、各ケースにマッピングを供給するのが必要であったので、使用サイトがコードと、そして、給仕サイトによって予想されたコードから伝わるのにおいて原因となるという提案は拒絶されました。 新しいホストがネットワークに追加されたように情報は一定のメインテナンスを必要とするでしょう。

O'Sullivan                                                      [Page 1]

RFC 139              Discussion of TELNET Protocol            7 May 1971

telnetプロトコル1971年5月7日のオサリヴァン[1ページ]RFC139議論

   Since it is not known how the current or future sites will specify
   the mapping between the network-wide standard code (7 bit ASCII in an
   8 bit field) and the codes expected from their own terminals, it
   seems necessary to permit the user to cause every one of the 128
   ASCII codes, plus (for full user power) selected control signals
   (either of a TELNET control nature, or of a special terminal nature
   such as break or attention).

現在の、または、将来のサイトがどのようにネットワーク全体の標準のコード(8ビットの分野の7ビットのASCII)とそれら自身の端末から予想されたコードの間のマッピングを指定するかが知られていないので、ユーザが128のASCIIコードの皆を引き起こすことを許可するように必要に思えます、プラス(完全なユーザパワーのための)の選択された制御信号(TELNETコントロール本質、または中断か注意などの特別な端末の本質について)。

   There was strong feeling about the importance of the user/system
   interface at the using site, but equally strong feeling that this
   problem is one of local implementation and should reflect the using
   site installation philosophy rather than the subject to network-wide
   standards.  Some topics of consideration in this area are:

ネットワーク全体の規格への対象よりむしろ使用しているサイトインストール哲学は、この問題が1であると感じながらユーザ/システム・インタフェースの重要性に関して使用サイト、しかし、等しく強く感じるのに地方の実装に強く、反射するべきです。 この領域での考慮のいくつかの話題は以下の通りです。

      1. How to represent special graphics, not available at the using
         site, at the user's terminal.

1. 使用サイト、ユーザの端末に利用可能でない特別なグラフィックスを表す方法。

      2. Treatment of upper/lower case problem on TTY 33 and 35.

2. TTY33と35における上側の、または、低いケース問題の処理。

         a. Representing lower-case output.

a。 小文字の出力を表します。

         b. Providing users with shift and shift lock signals.

b。 シフトとシフトロックをユーザに提供するのは合図します。

      3. Incorporating editing capability in TELNET.

3. 編集能力をTELNETに取り入れます。

      4. Extending user options in Network mode not available to local
         users,
         e.g., hold output

4. 地元のユーザには、利用可能でないNetworkモードにおけるユーザ・オプションを広げて、例えば、出力を持ってください。

               kill print

印刷を殺してください。

      5. Permit users to specify how keyboard input is to be translated,
         e.g., let a character from the terminal cause a specified
         string to be sent by the user's TELNET.

5. ユーザが翻訳されるキーボード入力がことである方法を指定することを許可してください、そして、例えば、端末からのキャラクタはユーザのTELNETに指定されたストリングを送らせてください。

   In early discussions, there was pressure to get a simple statement of
   protocol out early to permit early use of selected systems.  The
   counter pressure to provide a richer set of protocol in the first
   release was also present.  Work started in the direction of the
   latter, but the complexities introduced were not necessary for early
   use of the network.  The proposed solution to the TELNET protocol
   problem seems to provide a mechanism for a minimum implementation (to
   be discussed later) while providing a basis for developing richer
   sets of protocol for present and future use in terminal applications,
   process-process communications, and use by other conventions to pass
   data or control information.

早めの議論には、選択されたシステムの早めの使用を可能にするために早くプロトコルの単純文を出す圧力がありました。また、より豊かなセットのプロトコルを最初のリリースに提供する逆圧も存在していました。 仕事は後者の向きに始まりましたが、導入された複雑さはネットワークの早めの使用に必要ではありませんでした。 TELNETプロトコル問題への提案された解決はデータか制御情報を通過する端末のアプリケーション、プロセス間通信、および他のコンベンションによる使用における現在の、そして、今後の使用のために、より豊かなセットのプロトコルを開発する基礎を提供している間、最小の実装(後で議論する)にメカニズムを提供するように思えます。

O'Sullivan                                                      [Page 2]

RFC 139              Discussion of TELNET Protocol            7 May 1971

telnetプロトコル1971年5月7日のオサリヴァン[2ページ]RFC139議論

   The understanding that ASCII be used as a network-wide code has been
   established for some time.  Its use in TELNET provided a problem with
   respect to the limitation of a maximum character set of 128.  Some
   systems provide for more than this number in their operation, and
   therefor, as serving sites cannot map on a one for one basis.

ASCIIがネットワーク全体のコードとして使用されるという理解はしばらく確立されています。 TELNETにおける使用は128の最大の文字集合の制限に関して問題を提供しました。 いくつかのシステムが彼らの操作に、そのためにこの数以上に備えます、サイトが1つの基礎のために1つで写像できない給仕として。

   Each such serving site could probably provide a reasonably useful
   character set, including all system control signals, by mapping 128
   of its codes and just not provide a network user access to the other
   codes.  However, any character left out might later be used in a
   major application at that site as a special control signal.  This
   could result in denying network users the facility offered by that
   application.  Serving sites are, therefor, encouraged to provide a
   full mapping between the ASCII code and the code used on the serving
   system.

サイトに各役立つのであると、そのようなたぶん128のコードを写像することによってすべてのシステム制御信号を含むかなり役に立つ文字集合を提供して、ただ他のコードへのネットワーク利用者アクセスは提供できませんでした。 しかしながら、省かれたどんなキャラクタも後でそのサイトの特別な制御信号としての主用途で使用されるかもしれません。 これはそのアプリケーションで提供された施設をネットワーク利用者に対して否定するのに結果として生じることができました。 給仕サイトが給仕システムの上で使用されるASCIIコードとコードの間に完全なマッピングを提供するようそのために奨励されます。

   The ASCII code for ESC (known to some as ALT MODE) has been selected
   as an escape [1].  For each serving site character not mapped on a
   one for one basis, the serving site can specify an escape character
   or string of escape characters (preferably a printable graphic) to
   represent it.  Thus, the user could enter the full set of serving
   site code from any network terminal operating through the Network
   Virtual Terminal (NVT) ASCII convention.  The serving site, in
   generating output directed at the user's terminal, would be expected
   to map out such a character and transmit the appropriate ESC
   character or string of ESC characters.

ESC(ALT MODEとしていくつかに知られている)のためのASCIIコードはエスケープ[1]として選定されました。 1つの基礎のために1つで写像されなかったそれぞれの給仕サイトキャラクタとして、給仕サイトは、それを表すために拡張文字(望ましくは印刷可能なグラフィック)の拡張文字かストリングを指定できます。 したがって、ユーザはNetwork Virtual Terminal(NVT)ASCIIコンベンションで作動するどんなネットワーク端末からも給仕サイトコードのフルセットに入ることができました。 ユーザの端末が向けられた出力を生成する際に、給仕サイトは、そのようなキャラクタを計画して、ESCキャラクタの適切なESCキャラクタかストリングを伝えると予想されるでしょう。

      Example: A serving site, whose normal code is EBCDIC, has
      specified that cent ([5]) has not been mapped on a one for one
      basis and that to transmit the character, users must enter ESC
      followed by C.  At a using site, the TELNET implementers have
      decided to try to print out all ESC characters using \ to indicate
      ESC.  On receipt of the representation for cent, the user would
      see \C on his print-out.

例: 給仕サイト(正常なコードはEBCDICである)は、セント([5])が1つの基礎のために1つで写像されていなくて、キャラクタを伝えるために、ユーザが使用サイト、TELNET implementersがESCを示すのに\を使用することですべてのESCキャラクタを印刷しようとすると決められたC.Atによって続かれたESCに入らなければならないと指定しました。 セントの表現を受け取り次第、ユーザは外での彼の印刷であるところの\Cを見るでしょう。

   The representation of the end of a physical line at a terminal is
   implemented differently on network HOSTS.  For example, some use a
   return (or new line) key, the terminal hardware both returns the
   carriage or printer to start of line and feeds the paper to the next
   line.  In other implementations, the user hits carriage return and
   the hardware returns carriage while the software returns to the
   terminal a line feed.  The network-wide representation will be
   carriage return followed by line feed.  It represents the physical
   formatting that is being attempted, and is to be interpreted and
   appropriately translated by both using site and serving site.

端末の物理行の端の表現はネットワークHOSTSで異なって実装されます。 例えば、或るものがリターン(または、復帰改行)キーを使用して、端末のハードウェアは、キャリッジかプリンタを系列の始まりに返して、次の系列に紙を提供します。 他の実装では、ユーザは復帰を打ちます、そして、ソフトウェアは改行を端末に返しますが、ハードウェアはキャリッジを返します。 ネットワーク全体の表現は改行がいうことになった復帰になるでしょう。 それは試みられて、解釈されて、両方によってサイトを使用することで適切に翻訳されて、サイトに役立つことになっている物理的な形式を表します。

O'Sullivan                                                      [Page 3]

RFC 139              Discussion of TELNET Protocol            7 May 1971

telnetプロトコル1971年5月7日のオサリヴァン[3ページ]RFC139議論

      Example:  A Multics user is working, through the network, on some
      serving site HOST.  In the course of the session, the user has
      numerous occasions to hit New Line on his Mod 37 TTY.  Each time
      the Multics system is awakened by a New Line interrupt, the line
      of buffered characters is passed to TELNET where it is scanned for
      special characters.  If none is found, carriage return followed by
      line feed is inserted where New Line was entered, and the line is
      turned over to the NCP for transmission.  When the TELNET finds
      the carriage return line feed sequence in the data stream coming
      from the serving site, the two characters are replaced with New
      Line code and sent to the terminal.

例: Multicsユーザは働いています、ネットワークを通して、何らかの給仕サイトHOSTで。セッションの間に、ユーザには、彼のMod37TTYにNew線を打つ多数の時があります。 MulticsシステムがNew線中断で目を覚ます各回、バッファリングされたキャラクタの系列はそれが特殊文字のためにスキャンされるTELNETに通過されます。 なにも見つけられないなら、改行があとに続いた復帰はNew線が入れられたところに挿入されます、そして、NCPはトランスミッションのために系列に引き渡されます。 TELNETが、給仕サイトから来るデータ・ストリームで復帰改行が系列であることがわかると、2つのキャラクタをNew線コードに取り替えて、端末に送ります。

   The decision to have the assumed condition for echo be that the using
   site will provide any echo necessary for its terminals was taken
   because of the difficulties faced by some installations that cannot
   turn off their echo or that have terminals that print locally as a
   result of key strokes.  Serving sites could take the position "let
   the user turn my echo off", but this seems an unnecessary burden on
   the user.  In addition, some serving sites may choose not to supply
   any echo service, in which case the no echo assumption will supply a
   network-wide condition, while other assumptions would give a mixed
   starting connection. [2]

キーストロークの結果、局所的に印刷するそれらのエコーをオフにすることができないか、または端末を持っているいくつかのインストールで直面されていた困難のために、エコーのための想定された状態が使用サイトが端末に必要などんなエコーも供給するということであることを持っているという決定を取りました。 サイトに役立つと、「ユーザに私のエコーをオフにさせてください」という立場は取るかもしれませんが、これはユーザの上で不必要な負担に見えます。 追加、供給しないサイトがどんなエコーサービス、その場合ノーも選ぶかもしれない何らかの給仕では、エコー仮定はネットワーク全体の状態を提供するでしょう、他の仮定が複雑な始めの接続に与えるでしょうが。 [2]

   The convention of using "I ECHO", "YOU ECHO" seems to fill both the
   requirements for dynamic echo control and for a minimum
   implementation of TELNET Protocol. [3]  An agreed-upon exchange to
   pass echo control (i.e., two sites exchange the I ECHO/YOU ECHO
   codes) results in passing the control from one site to the other.

「私は反響する」使用のコンベンション、「あなたは反響すること」がダイナミックなエコー制御とテルネット・プロトコルの最小の実装のための両方の要件をいっぱいにするように思えます。 [3] エコー制御(すなわち、2つのサイトがI ECHO/YOU ECHOコードを交換する)を通過する同意している交換はあるサイトからもう片方までのコントロールを通過するのに結果として生じます。

      Example:  A serving site is exchanging control information with
      the USER in an area where the serving system asks for pass word
      and wants to suppress the printing of the pass word at the using
      site's user terminal. (In this case, the using site has the
      ability to control the print capability at the user's terminal.)
      Using site has been echoing to the user's terminal.

例: 給仕サイトは給仕システムがパス単語を求めて、使用サイトのユーザ端末でパス単語の印刷を抑圧したがっている領域でUSERと制御情報を交換しています。 (この場合、使用サイトには、ユーザの端末で印刷能力を制御する能力があります。) サイトを使用するのはユーザの端末に反響しています。

         Serving Site to Using Site (--->)

サイトを使用するのにサイトに役立ちます。(-、--、>)

            I ECHO

私は反響します。

         Using Site to Serving Site (<---)

サイトに役立つのにサイトを使用します。(<--、)

            YOU ECHO

あなたは反響します。

         --->Pass word:

--->パス単語:

         <--- (User enters password at terminal)

<。--- (ユーザはパスワードを端末に入力します)

O'Sullivan                                                      [Page 4]

RFC 139              Discussion of TELNET Protocol            7 May 1971

telnetプロトコル1971年5月7日のオサリヴァン[4ページ]RFC139議論

         ---> (No echo sent)

--->。(送られなかったエコー全く)

         ---> YOU ECHO

---あなたが反響する>。

         <--- I ECHO

<。--- 私は反響します。

      After the exchange, the original normal condition is re-
      established.  If the using site did not have dynamic echo control
      installed in its TELNET implementation, the serving site would
      have signaled I ECHO several times, received no response, and
      assumed that the using site could not comply proceeding to call
      for the pass word without the normal protection of inhibiting
      print.

交換の後に、元の正常な状態は再確立されます。 使用サイトでダイナミックなエコー制御をTELNET実装にインストールしなかったなら、給仕サイトは、合図された私が何度かECHOを持って、応答を全く受けないで、使用サイトが禁止印刷の通常の保護なしでパス言葉を求めかけながら応じることができないと仮定しました。

   TELNET control signals are of two types: one that results in
   transmission of signals down the network to a receiving site; the
   other intended for the user/process site only.  The latter type will
   be discussed later.  So far, we have discussed the former type,
   specifically dealing with echo control.

2つのタイプにはTELNET制御信号があります: それがトランスミッションに結果になる1つは受信サイトへのネットワークの下側に合図します。 ユーザ/プロセスサイトに意図するもう片方専用。 後で後者のタイプについて議論するでしょう。 今までのところ、明確にエコー制御に対処して、私たちは元タイプについて議論しました。

   The use of ESC should not be considered a TELNET-wide standard, but a
   convention limited to the 7 bit ASCII mode of transmission.  Other
   conventions, to be incorporated later, may include binary
   transmission, EBCDIC, etc.  Presumably, each will have its own
   convention for an escape character to extend its code set.

TELNET全体の規格であるとESCの使用を考えるべきではありませんでしたが、コンベンションはトランスミッションの方法を7ビットのASCIIに制限しました。 他のコンベンションは、後で法人組織であるために2進のトランスミッション、EBCDICなどを含めるかもしれません。 おそらく、それぞれが拡張文字がコードセットを広げるそれ自身のコンベンションを開くでしょう。

   Since it is expected that conventions other than ASCII will be
   implemented under TELNET, a code to indicate a DATA TYPE representing
   each set of conventions will be employed.  The control code X'AO' has
   been selected to represent the ASCII convention in TELNET.  Since a
   number of applications may wish to transmit transparently (i.e., 8
   bit binary data), X'Al' is being reserved for that purpose.  The
   TELNET control code X'A2' is reserved for an expected set of EBCDIC
   conventions.  The DATA TYPE is expected as the first byte of data
   over a TELNET connection.  Minimum implementations will be aided by
   providing a default.  That is, if the first byte over a connection
   has the high order bit set as zero, then the transmission has begun
   in ASCII mode.

ASCIIを除いたコンベンションがTELNETの下で実装されると予想されるので、それぞれのセットのコンベンションを代表するDATA TYPEを示すコードは使われるでしょう。 制御コードX'AO'がTELNETのASCIIコンベンションを代表するのが選択されました。 応募件数が透過的に(すなわち、8ビットのバイナリ・データ)を伝えたがっているかもしれないので、X'Al'はそのために予約されています。 TELNET制御コードX'A2'は予想されたセットのEBCDICコンベンションのために予約されます。 DATA TYPEはデータの最初のバイトとしてTELNET接続に関して予想されます。 最小の実装は、デフォルトを提供することによって、支援されるでしょう。 すなわち、ゼロとして接続の上の最初のバイトで高位のビットを設定するなら、トランスミッションはASCIIモードで始まりました。

   Each set of conventions, i.e., each DATA TYPE will be expected to
   have a convention for that DATA TYPE to signal that it is returning
   to control mode.  This return may be for the purpose of making use of
   an existing control codes or to change data type.  X'88' is used [4].

それぞれのセットのコンベンション、そのDATA TYPEがそれが戻る予定であって、モードを制御すると合図するように、すなわち各DATA TYPEがコンベンションを開くと予想されるでしょう。 このリターンは制御コードか変化データ型に存在を利用する目的のためのものであるかもしれません。 'X88年'は中古の[4]です。

      Example:  At the using site, a terminal has a special device on it
      (e.g., plotter, laboratory instrument, control box, etc.) that is
      controlled by binary code in 8 bit bytes.  The terminal uses a
      special "enter" code that routes signals to the device and cuts

例: 使用サイトでは、端末はそれ(例えば、陰謀者、実験室器具、コントロールボックスなど)の8ビットのバイトで表現される2進コードによって制御される特別なデバイスを持っています。 端末は「入ってください」というデバイスときり傷に信号を発送する特別なコードを使用します。

O'Sullivan                                                      [Page 5]

RFC 139              Discussion of TELNET Protocol            7 May 1971

telnetプロトコル1971年5月7日のオサリヴァン[5ページ]RFC139議論

      off printing at the terminal until a special "leave" signal is
      received from the driving process.  The driving process in this
      case is at a remote serving site.  It is assumed in this example
      that a DLE convention is used for transparent transmission, a
      single DLE signal representing return to control.  Normal
      transmission has been in ASCII.

端末で特別な「休暇」まで印刷するところでは、駆動プロセスから信号を受信します。 駆動プロセスがこの場合遠く離れた給仕サイトにあります。 この例では、DLEコンベンションがわかりやすいトランスミッション(制御するためにリターンを表すただ一つのDLE信号)に使用されると思われます。 ASCIIには通常のトランスミッションがありました。

      Driving Process (at Serving Site) to Using Site) ---->

サイトを使用することへの駆動プロセス(サイトに役立つところの)) ---->。

         X'88'X'A1'

X'88'X'A1'

      Using Site to Serving Site <----

サイト<に役立つのにサイトを使用します。----

         X'88'X'88'

'X'88'X88年'

      ----------->

----------->。

         ENTER code...8 bit binary bytes...

ENTERコード…8は2進のバイトに噛み付きました…

      Using Site TELNET to Terminal |
                                    |
                                    V

サイトtelnetを端末に使用します。| | V

         Enter code...8 bit binary bytes...

コードを入れてください…8は2進のバイトに噛み付きました…

      Terminal

端末

         Turn printer off, feed transparently to special device, look
         for LEAVE signal

プリンタをオフにしてください、そして、透過的に特別なデバイスへ供給してください、そして、LEAVE信号を探してください。

      ------------>

------------>。

         8 bit binary bytes...LEAVE signal...single DLE
         X'A0'

8は2進のバイトに噛み付きました…LEAVEは合図します…独身のDLE X'A0'

      <-----------

<。-----------

         X'88'X'88

X'88'X88年

      ------------>

------------>。

      Message

メッセージ

       |
       |
       V
         8 bit binary data...LEAVE signal MESSAGE

| | V8はバイナリ・データに噛み付きました…LEAVE信号MESSAGE

O'Sullivan                                                      [Page 6]

RFC 139              Discussion of TELNET Protocol            7 May 1971

telnetプロトコル1971年5月7日のオサリヴァン[6ページ]RFC139議論

      _Terminal_

_端末の_

      During this sequence of exchanges - at the terminal, feed binary
      data to special device until LEAVE signal is sensed, strip off
      LEAVE signal, turn on printer and block data path to special
      device, print MESSAGE at terminal.

端末の交換のこの系列の間、LEAVE信号が理解されるまで、特別なデバイスにバイナリ・データを提供してください、そして、LEAVE信号を全部はぎ取ってください、そして、プリンタをつけてください、そして、特別なデバイスにデータ経路を妨げてください、端末の印刷MESSAGE。

   There is a special control signal on some terminals that has no
   corresponding bit pattern in ASCII, but is transmitted by a special
   electrical signal.  This control signal is ATTN on a 2741 and BREAK
   on a teletype.  The ASCII DATA TYPE in TELNET will use the code X'81'
   to represent BREAK.  (There is a corresponding control signal for use
   from serving sites to using sites for reverse break, and it is
   assigned the code X'82').

いくつかの端末の上のASCIIではどんな対応するビット・パターンも持っていませんが、特別な電気的信号によって送信される特別な制御信号があります。 この制御信号は、2741のATTNとテレタイプの上のBREAKです。 'TELNETのASCII DATA TYPEがコードXを使用する、81年、'BREAKを表すために。 '、(そこでは、給仕からの使用のための逆にサイトを使用することへのサイトが壊れて、コードXがそれに割り当てられるという対応する制御信号が82年、'、)

   Some systems treat the break as an extra code available for use in
   conjunction with the data stream.  For example, one system uses break
   as a special editing code meaning "delete the current line to this
   point".  In these cases, the code may simply be inserted in the data
   stream with no special additional action by the user.

いくつかのシステムがデータ・ストリームに関連して使用に利用可能な付加的なコードとして中断を扱います。 例えば、「現在行をこの位まで削除します」と意味しながら、1つのシステム用途が特別な編集コードとして壊れます。 これらの場合では、コードはユーザによって特別な追加措置なしで単にデータ・ストリームに挿入されるかもしれません。

   Other systems use BREAK or ATTN in a special interrupt fashion, to
   mean stop processing the application and give me the supervisor, or
   cancel the present job, etc.  (Other systems use normal characters
   for this purpose, such as "Control C".)  In these cases, because of
   differences in the ways both serving and using sites operate, it is
   necessary to take a route in addition to the normal TELNET data
   stream to signal that the special control signal is imbedded in the
   data stream.

他のシステムは、アプリケーションを処理するのを止めることを意味するのに特別な中断ファッションでBREAKかATTNを使用して、監督を私に与えるか、または現在の仕事を中止しますなど。 (他のシステムは「コントロールC」などのようにこのために普通のキャラクタを使用します。) これらの場合では、ともにサイトに役立って、使用するのが作動する方法の違いのために、特別な制御信号がデータ・ストリームで埋め込まれると合図するために通常のTELNETデータ・ストリームに加えてルートを取るのが必要です。

      _Examples-Problem_

_例問題_

      The PDP-10 normally will, when it fills its input buffer, continue
      to accept characters from a terminal examining each to see if it
      is a control character, then act on it if it is or throw it away
      if it is not.

入力バッファをいっぱいにするとき、それが続けないと、PDP-10は、それが制御文字であるかどうか確認するためにそれぞれを調べる端末からキャラクタを受け入れるか、次に、それが行動するならそれに行動するか、または通常、それを捨て続けるでしょう。

      Since the TELNET server at the serving site is at the mercy of the
      NCP with respect to controlling the bunching, and therefor,
      arrival at the TELNET of bursts of characters, TELNET
      implementations might be expected to choke off flow to the buffers
      until they are ready to accept characters without throwing them
      away.

以来、給仕サイトのTELNETサーバがそのために束になることを制御するキャラクタ、バッファへの流れで詰まらせる実装が予想されるかもしれないTELNETの炸裂のTELNETへのそれらが彼らを捨てないでキャラクタを受け入れる準備ができるまでの到着に関するNCPの思うままにあります。

   Under this condition, the serving process might be outputting to the
   using terminal, the input buffers fill up, and a control C get stuck
   in the data stream that has been choked off.

この条件のもとでは、プロセスが使用端末に出力しているかもしれない給仕、バッファが満たす入力、およびコントロールCは止められたデータ・ストリームで立ち往生します。

O'Sullivan                                                      [Page 7]

RFC 139              Discussion of TELNET Protocol            7 May 1971

telnetプロトコル1971年5月7日のオサリヴァン[7ページ]RFC139議論

   A similar problem could occur with the Multics or some IBM system as
   a server.  The user at a using site gets into an output loop at the
   serving site and wants to break the process without having to release
   his TELNET connection.  The buffers clog the connection, transmission
   is choked off, and the control C break, or other user control signal
   gets stuck in the pipeline.

同様の問題はサーバとしてMulticsか何らかのIBMシステムで起こることができました。彼のTELNET接続を釈放する必要はなくて、使用サイトのユーザは、給仕サイトで出力輪に入って、プロセスを壊したがっています。 バッファは接続を妨げて、トランスミッションはパイプラインで制御信号で張り付けるむせているオフで、コントロールC中断であるか、他のユーザです。

   _Example - Solution_

_の例--ソリューション_

   The user at the using site knows he is entering a special control
   signal (break, ATTN, control C, etc.) and follows it with an X'80'.
   (The local instructions at using sites for accomplishing this may
   differ from site to site.)

'使用サイトのユーザは、彼が特別な制御信号(中断、ATTN、コントロールCなど)を入力していて、X80年でそれの後をつけるのを知っています'。 (これを達成するのにサイトを使用するところのローカルの指示はサイトからサイトまで異なるかもしれません。)

      Using Site TELNET to Serving Site

サイトに役立つのにサイトtelnetを使用します。

         Insert X'80' in Data Stream

データ・ストリームへの'X80年を挿入してください'

      Using Site TELNET to Using Site NCP

サイトNCPを使用するのにサイトtelnetを使用します。

         Send an INS

INSを送ってください。

      Sending Site NCP to TELNET Server

サイトNCPをtelnetサーバに送ります。

         Look out, here she come

危ない、ここに、彼女は来ます。

      Serving Site TELNET

サイトtelnetに役立ちます。

         Does its special thing until it sees X'80' then resumes
         normal handling

'、X'当時の履歴書80年の標準が扱われているのを見るまで、特別なことをします。

   Thus, depending on the server's local implementation to provide
   adequate service, a special handling of the data stream can be
   invoked whenever an INS is received in order to get the special
   character.  When it sees X'80', it recognizes it as a SYNC character
   and knowing that the special character has been passed on, strips the
   X'80' from the data stream and returns to normal mode.

したがって、INSが特殊文字を得るために受け取られているときはいつも、データ・ストリームの特別な取り扱いは呼び出されて、適切なサービスを提供するためにサーバの地方の実装に依存できます。 '正規モードへのデータ・ストリームとリターンからのX80年に遭遇して、'SYNCキャラクタとしてそれを認識して、特殊文字があったのを知っているのを進んで、片はX80年である'とき。

   If the X'80' arrives before the INS, a counting scheme can keep the
   activity appropriate to the serving site conditions.

'X80年であるなら'。INS、体系が役立っている敷地条件に適切な活動であることを保つことができる勘定の前に到着します。

   This approach to handling selected special characters or signals
   relieves the using TELNET processes from having to recognize the
   special serving site characters, as well as from having to know how
   the serving site wants to handle them.  At the same time, the

選択された特殊文字か信号を扱うことへのこのアプローチはTELNETが特別な給仕サイトキャラクタ、およびその方法を知らなければならないのからの給仕サイト必需品を見分けなければならないのでそれらを扱うために処理する使用を救います。 同時に

O'Sullivan                                                      [Page 8]

RFC 139              Discussion of TELNET Protocol            7 May 1971

telnetプロトコル1971年5月7日のオサリヴァン[8ページ]RFC139議論

   procedure requires only a minimum level of user understanding of the
   serving site.  This seems appropriate, since the TELNET ASCII
   conventions are providing a Network Virtual Terminal, not a Network
   Virtual User.

手順は最低水準の給仕サイトのユーザ理解だけを必要とします。 TELNET ASCIIコンベンションがNetwork Virtual Userではなく、Network Virtual Terminalを提供しているので、これは適切に見えます。

   The ability of the user to cause the using site TELNET to send any
   combination of ASCII characters in a string, and only that
   combination, is viewed as important to the user utility of the TELNET
   ASCII conventions.  Because of this, some user sites may find it
   necessary to provide special local TELNET control signalling from the
   user to the using site.

使用サイトTELNETを引き起こすユーザの能力は、ストリング、およびその組み合わせだけでASCII文字のどんな組み合わせも送って、TELNET ASCIIコンベンションに関するユーザユーティリティに重要であるとして見なされます。 これのために、いくつかのユーザの現場によって、ユーザから使用サイトまで合図する特別な地方のTELNETコントロールを提供するのが必要であることがわかるかもしれません。

      _Examples_

_例の_

      A user on a line at a time system (Multics, System 360, GECOS,
      etc.)  is working through the Network on a serving site that
      operates a character at a time.  The application is a debugging
      aid that permits the user to type in a memory location = to which
      it will respond with n where n represents the current contents of
      that location.  The serving site process does not expect to see
      the location = followed by a carriage return line feed sequence.
      The user at the using site should be able to type in the location,
      follow it with a signal to suppress the end of a line convention,
      followed by a new line or return, and expect the location number =
      to be transmitted immediately without an end of line sequence.

時間システム(Multics、System360、GECOSなど)の系列のユーザは一度にキャラクタを手術する給仕サイトのNetworkを終えています。 アプリケーションはユーザが記憶域でそれがnがその位置の現在のコンテンツを表すところでnで応じる=をタイプすることを許可するデバッギング・エイドです。 給仕サイトプロセスは、復帰改行系列が位置=のあとに続くのを見ると予想しません。 使用サイトのユーザは、位置をタイプするか、系列コンベンションの終わりを抑圧するために信号でそれに続くか、復帰改行のそばで続くか、または戻ることができて、すぐ行末系列なしで伝えられるために位置の番号が等しいと予想するべきです。

      In another case, a using site has decided that it is convenient to
      accumulate four characters at a time and transmit them to the
      serving site, unless an end of line is observed, in which case the
      end of line sequence is sent preceded by whatever number of
      characters have been accumulated, (presumably three or less).  In
      the same debugging application, the address is such that the end
      does not correspond with the four character buffer demarcation.
      The user should have the ability to enter a code for "transmit
      immediately" in place of the Carriage Return in order to preserve
      neat formatting, and expect the address to be sent to the serving
      site.

別の場合では、行末((数の何でもキャラクタが蓄積されたかによって先行しました)行末系列が送られるケース)が観測されない場合、使用サイトは、一度に4つのキャラクタを蓄積して、給仕サイトに彼らを送るのが便利であると決めました(おそらく3以下)。 同じデバッグアプリケーションでは、アドレスがそのようなものであるので、終わりは4文字バッファ画定に対応していません。 ユーザは、きちんとした形式を保存して、「至急、伝わってください」のためにCarriage Returnに代わってコードを入れる能力を持って、アドレスが給仕サイトに送られると予想するべきです。

      TELNET controls have been discussed and those introduced to date
      are probably sufficient for an early implementation of TELNET
      ASCII convention.  There will be a need to establish a mechanism
      for the controlled assignment (on request by Network Sites), and
      announcement of DATA TYPE and CONTROL codes.

TELNETコントロールについて議論しました、そして、これまで導入されたものはたぶんTELNET ASCIIコンベンションの早めの実装に十分です。 制御課題(Network Sitesによる要求での)のためのメカニズム、およびDATA TYPEとCONTROLコードの発表を確立するそこでは、必要性でしょう。

      It should be noted that some controls are network-wide TELNET
      controls, while others are specific to the ASCII Data Type.  It
      should be further recognized that some local control messages do
      not require a corresponding network-wide code.

他のものがASCII Data Typeに特定である間、いくつかのコントロールがネットワーク全体のTELNETコントロールであることに注意されるべきです。 いくつかの現場制御メッセージが対応するネットワーク全体のコードを必要としないとさらに認められるべきです。

O'Sullivan                                                      [Page 9]

RFC 139              Discussion of TELNET Protocol            7 May 1971

telnetプロトコル1971年5月7日のオサリヴァン[9ページ]RFC139議論

      While it is recognized that even a minimum implementation of
      TELNET for a using site is expected to permit the user to send any
      selected ASCII string (and only that string) to the serving site,
      it is not necessary for a serving site to implement a full mapping
      from ASCII to local code, nor is it necessary for either the using
      or serving sites to implement all control codes.

使用サイトへのTELNETの最小の実装さえ、ユーザがどんな選択されたASCIIストリング(そして、そのストリングだけ)も給仕サイトに送ることを許可すると予想されると認められますが、給仕サイトがASCIIからローカルのコードまで完全なマッピングを実装するのは必要でなく、また使用か給仕サイトのどちらかがすべての制御コードを実装するのにそれは、必要ではありません。

      _Example - Using Site_

_の例--サイト_を使用すること。

      A minimum implementation of the TELNET protocol for the using site
      would permit ignoring (and stripping) any control signals from the
      serving site since they would all either require agreement or
      acknowledgement (e.g., DATA TYPE, ECHO CONTROL, etc.) or can be
      ignored with no particularly harmful results (e.g., reverse
      break).

使用サイトへのTELNETプロトコルの最小の実装は、それらを協定か承認(例えば、DATA TYPE、ECHO CONTROLなど)をすべて必要とするだろうか、または特に有害な結果(例えば、逆の中断)なしで無視できるので給仕サイトからのどんな制御信号も無視することを(そして、ストリップ)許可するでしょう。

      _Example - Serving Site_

_の例--サイト_に役立つこと。

      A minimum implementation of the TELNET protocol for the serving
      site could provide one for one mapping for the most important 128
      serving system controls and graphic signals, and ignore all
      control signals.

給仕サイトへのTELNETプロトコルの最小の実装は、最も重要な128給仕のために個人的にはシステム制御とグラフィック信号を写像しながら1つを提供して、すべての制御信号を無視するかもしれません。

   It would be helpful if a minimally implemented receiving site, when
   it recognizes an incoming control signal for which appropriate
   reaction is not available, could respond with X'87' (The following
   not implemented at this site) and follow it with the code just
   received.

'適切な反応が利用可能でない入って来る制御信号を認識するとき、最少量で実装している受信サイトがX87年で応じることができれば、助かっ'て(このサイトで実装されなかった以下)、ただコードを受け取っていてそれに続いてください。

   Whenever an ASCII TELNET connection is lost, it should be assumed
   that the process at the other end of the connection has been quit,
   aborted, failed, etc.  In this way, a minimum using site installation
   can fail to implement the break and break synchronization, and have
   the user rely on the using site local procedure for leaving a running
   local process and returning to the supervisor to break a connection
   to a remote serving site.

ASCII TELNET接続が迷子になっている、接続のもう一方の端のプロセスがやめられたと思われるべきであるときはいつもなど中止になって、失敗した。 このように、ユーザは、休みを実装して、同期を壊して、サイトインストールを使用する最小限で実行している地方のプロセスと監督に戻るのが遠く離れた給仕サイトに接続を切り出すのを残すための使用サイトローカルの手順を当てにすることができません。

      _Example_

_例の_

      User recognizes that he is caught in an output loop and wishes to
      stop his user process at the serving site.  The serving site
      requires a break, but the using site minimum implementation has
      not made it available.  Even if it had, the INS was not
      implemented and could not be used to unblock the input pipe.
      Locally, the using site convention for leaving a process and
      getting to supervisory level is to hit the attention key on the
      2741 terminal.  The user does this and is passed to the supervisor
      where he signals to release the TELNET connection.  The serving

ユーザは、彼が出力輪に捕らえられると認めて、給仕サイトで彼のユーザ・プロセスを止めたがっています。 給仕サイトは中断を必要としますが、使用サイト最小の実装で、それは利用可能になっていません。 そうしたとしても、INSは実装されないで、また入力が運ぶ非ブロックに使用されないかもしれません。 局所的に、プロセスを残して、管理のレベルを始めるための使用しているサイトコンベンションは2741年の端末でアテンションキーを打つことになっています。 ユーザは、これをして、監督にTELNET接続を釈放すると合図するところに移られます。 給仕

O'Sullivan                                                     [Page 10]

RFC 139              Discussion of TELNET Protocol            7 May 1971

telnetプロトコル1971年5月7日のオサリヴァン[10ページ]RFC139議論

      site, seeing that an ASCII TELNET connection has been lost,
      assumes that the user is ended either normally or abnormally.
      Serving site cancels the user's process.  The user tries again by
      re-establishing the connection, logging in again, re-initiating
      the process, etc.

ASCII TELNET接続が迷子になったのを見て、サイトは、ユーザが通常か異常に終わると仮定します。 サイトキャンセルにユーザのプロセスに役立ちます。 ユーザは、接続、再び伐採、プロセスを再開始するのなどを復職させることによって、再試行します。

   Other conventions under TELNET may make quite different assumptions
   about lost connections, and some may go as far as dynamic
   establishing and releasing of connections.

TELNETの下の他のコンベンションは迷子になった接続に関する全く異なった仮定をするかもしれません、そして、或るものは接続のはるかに同じくらいダイナミックな設立と解放に仮装して出演するかもしれません。

   The proposed TELNET ASCII implementation leaves much uncovered, but
   seems to permit early simple implementation with varying levels of
   capability, along with the capacity to expand in several ways to meet
   others needs.

提案されたTELNET ASCII実装は、多くをむき出しのままにしますが、異なったレベルの能力で早めの簡単な実装を可能にするように思えます、他のもの需要を満たすいくつかの方法で広がる容量と共に。

   There is an important open question.  Should a PROTOCOL such as
   TELNET provide the basis for extending a system to perform functions
   that go beyond the normal capacity of the local system.  For example,
   a local system may not provide functions such as Hold Output, Kill
   Print, etc., but it could extend it for network purposes through
   TELNET.  If so, to what extent should such extensions be thought of
   as Network-wide standards as opposed to purely local implementations.

重要な未決問題があります。 TELNETがローカルシステムの正常生産能力を越える機能を実行するシステムを拡張する基礎を提供するプロトコルはそうするべきです。 例えば、ローカルシステムはHold Output、Kill Printなどの機能を提供しないかもしれませんが、それはネットワーク目的のためにTELNETを通してそれを広げるかもしれません。 そうだとすれば、そのような拡大は純粋に地方の実現と対照的にNetwork全体の規格としてどんな範囲まで考えられるべきですか?

Endnotes

エンドノート

   [1] Please drop the (s) at the end of "character" in paragraph 3,
   page 3, RFC 137, NIC #6714.

[1] RFC137、NIC#6714、パラグラフ3の3ページの「キャラクタ」の終わりで(s)を落としてください。

   [2] Also make note that the starting assumption in the initial
   exchange between using site and serving site will be that the using
   site will (if necessary) provide echo and the serving site will not.

[2] また、サイトを使用して、サイトに役立つことの間の初期の交換における始めの仮定が(必要なら、)使用サイトがエコーを供給して、給仕サイトがそのように供給しないということであるというメモを作ってください。

   [3] Note: Please change RFC #137, NIC #6714, page 4 - Code X'85' to
   read Reserved.

[3] 以下に注意してください。 Reservedを読む'4ページ--RFC#137、NIC#6714を変えてください、そして、X85年をコード化してください'。

   [4] Please note on page 4 of RFC 137 that the receipt of an X'88'
   should be responded with by the receiver sending a double signal,
   i.e., X'88'X'88' if the new DATA TYPE can be handled.

'[4] 4RFCページでは、137 88年が新しいDATA TYPEであるなら'二重信号、すなわち、X'88'X88年を送る受信機で反応するべきである'Xの領収書を扱うことができます。

   [5] Cent sign

[5] セント記号

          [This RFC was put into machine readable form for entry]
           [into the online RFC archives by Lorrie Shiota, 1/02]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロリー塩田によるオンラインRFCアーカイブへの1/02]

O'Sullivan                                                     [Page 11]

オサリヴァン[11ページ]