RFC435 日本語訳

Network Working Group                                          B. Cosell
Request for Comment: 435                                         BBN-NET
NIC: 13675                                                     D. Walden
Category: TELNET, Protocols, Echoing                             BBN-NET
References: 318, 357                                      5 January 1973

コメントを求めるワーキンググループB.コーセルの要求をネットワークでつないでください: 435 BBNネットのNIC: 13675D.ウォルデンカテゴリ: telnet、BBNネットの参照を反映するプロトコル: 318 357 1973年1月5日

                             TELNET Issues

telnet問題

   This RFC discusses a number of TELNET related issues which have been
   bothering us [1].  The basic, central issue we started from was that
   of echoing.  We worked downward from our difficulties to discover the
   basic principles at the root of our unhappiness, and from there
   worked back upwards to design a scheme which we believe to be better.
   In this note we will discuss both the alternate scheme and its
   underlying principles.

このRFCは関係づけられたTELNETの数について議論します。私たちを苦しめているものに[1]を発行します。 私たちが始めた基本的で、主要な問題は反響のものでした。 私たちは、私たちの不幸の根で基本原理を発見するために私たちの困難から下向きに働いて、私たちが、より良いと信じている体系を設計するためにそこから上向きに超過勤務しました。 この注意では、私たちは代替の体系とその基本的な原則の両方について議論するつもりです。

   As something of a non sequitur, before discussing echoing we feel it
   expedient to dismiss one possible stumbling block, outright.  HIDE
   YOUR INPUT may or may not be a good idea, this question not
   concerning us at the moment.  Whatever the case, the issue of hiding
   input is certainly separable from that of echoing.  We, therefore,
   strongly recommend that a STOP HIDING YOUR INPUT command be
   sanctioned to replace the multiplexing of this function on the NO
   ECHO command.  Once this has been done, the pair of commands HIDE
   YOUR INPUT and STOP HIDING YOUR INPUT can be kept or discarded
   together, and we can discuss the issue of echoing independently of
   them.

ある種の不合理な推論として、反響するのを議論する前に、私たちは、1つの可能なつまずきの石を完全に棄却するのが好都合であると感じます。 現在、HIDE YOUR INPUTは名案、私たちでないのに関するこの問題であるかもしれません。 ケースが何であっても、確かに、隠れること入力の問題は反響のものから分離できます。 したがって、私たちは、STOP HIDING YOUR INPUTコマンドがNO ECHOコマンドでのこの機能のマルチプレクシングを取り替えるために認可されることを強く勧めます。 これがいったん完了していると、コマンドのHIDE YOUR INPUTとSTOP HIDING YOUR INPUTの組を一緒に維持するか、または捨てることができます、そして、私たちはそれらの如何にかかわらず反響する問題について議論できます。

Echoing

反響します。

   The basic observation that we made regarding echoing was that servers
   seem to be optimized to best handle terminals which either do their
   own echoing or do not, but not both.  Therefore, the present TELNET
   echoing conventions, which prohibit the server from initiating a
   change in echo mode, seemed overly confining.  The servers are
   burdened with users who are in the 'wrong' mode, in which they might
   not otherwise have to be, and users, both human and machine, are
   burdened with remembering the proper echoing mode, and explicitly
   setting it up, for all the different servers.  It is our
   understanding that this prohibition was imposed on the servers to
   prevent loops from developing because of races which can arise when
   the server and user both try to set up an echo mode simultaneously.
   We will describe a method wherein both parties can initiate a change
   of echo mode and show that the method does not loop.

私たちが反響に関してした基礎観測がサーバがそれら自身の反響をする端末を最もよく扱うか、またはするために最適化されるように思えるということであった、しかし、両方でない。 したがって、コンベンションを反響する現在のTELNETは閉じ込めることをひどく思えました。コンベンションはエコーモードにおける変化を起こすのからサーバを禁じます。 サーバはそうでなければ、彼らがそうする必要はないかもしれない'間違った'モードで、いてください、そして、ユーザ(人間とマシンの両方)が背負い込んでいるという適切な反響モードを覚えているのがあることであり、それをセットアップして、明らかにことであるユーザに負担されます、すべての異なったサーバのために。 私たちは、この禁止が輪がサーバとユーザが同時にともにエコーモードをセットアップしようとするとき起こることができるレースのために展開するのを防ぐためにサーバに課されたのを理解しています。 私たちは、双方がエコーモードの変化を起こすことができるメソッドを説明して、メソッドが輪にされないのを示すつもりです。

Cosell & Walden                                                 [Page 1]

RFC 435                      TELNET Issues                5 January 1973

コーセルとウォルデン[1ページ]RFC435telnetは1973年1月5日を発行します。

   This alternate specification relies on three primary assumptions.
   First as above, the server, as well as the user, should be able to
   suggest the echo mode.  Second, all terminals must be able to provide
   their own echoes, either internally or by means of the local Host.
   Third, all servers must be able to operate in a mode which assumes
   that a remote terminal is providing its own echoes.  Both of these
   last two result from the quest for a universal, minimal basis upon
   which to build.  It is fairly easy for a Host which normally supplies
   echoes to disable the appropriate code, but it will difficult for a
   Host which does not do echoing to integrate such routines into its
   system similarly, it is easier for a local Host to supply echoes to a
   terminal which cannot provides its own, but it borders on the
   impossible to undo echoing in a terminal which has automatic echoing
   built into it.

この代替仕様は3つのプライマリ仮定に依存します。 まず最初に同じくらい上では、サーバ、およびユーザがエコーモードを示すことができるべきです。 2番目に、すべての端末が内部的か地方のHostによってそれら自身のエコーを供給できなければなりません。 3番目に、すべてのサーバが遠隔端末がそれ自身のエコーを供給していると仮定するモードで作動できなければなりません。 これらの最後の2の両方が建てる普遍的で、最小量の基礎を求める探索から生じます。 Hostのために、通常、どれがそうすることができない端末への同様に、地方のHostがエコーを供給するのが、簡単であるシステムとそのようなルーチンを統合するために反響をしないHostに、難しい意志をしかし、適切なコード、それに無効にするためにエコーを供給するかがかなりたやすく、それ自身のものを提供しますが、それを自動反響に組み込む端末で反響しながら元に戻す不可能に近似するということです。

   Our proposed specification would use the present ECHO and NO ECHO
   commands as follows: ECHO, when sent by the server to the user, would
   mean 'I'll echo to you' ECHO, when sent by the user to the server,
   would mean 'You echo to me'.  NO ECHO, when sent by the server to the
   user, would mean 'I'll not echo to you'; NO ECHO, when sent by the
   user to the server, would mean 'Don't you echo to me'.  These are, of
   course, nearly the same meanings that the commands currently have,
   although most current implementations seem to invert the server-to-
   user meanings.

私たちの提案された仕様は以下の現在のECHOとNO ECHOコマンドを使用するでしょう: サーバでユーザに送ると、ECHOは、ユーザによってサーバに送られると'私はあなたに反響する'ECHOが、'あなたは私に反響します'と意味することを意味するでしょう。 サーバでユーザに送ると、NO ECHOは、'私はあなたに反響しないでしょう'と意味するでしょう。 ユーザによってサーバに送られると、NO ECHOは'あなたは私に反響しないこと'を意味するでしょう。 これらはもちろんコマンドが現在持っているのとほとんど同じ意味です、ほとんどの現在の実装がサーバからユーザへの意味を逆にするように思えますが。

   In our specification, whenever a connection is opened both server and
   user assume that the user is echoing locally.  If the user would, in
   fact, prefer the server to echo, the user could send off an ECHO
   command.  Similarly, if the server prefers to do the echoing (for
   instance, because the server system is optimized for very interactive
   echoing), the server could send off an ECHO command.  Neither is
   required to do anything, it is only a matter of preference.  Upon
   receipt of either command by either party, if that is an admissible
   mode of operation the recipient should begin operating in that mode,
   and if such operation reflects a change in mode, it should respond
   with the same command to confirm that (and when) the changeover took
   place.  If the received command request an inadmissible mode of
   operation, then the command's inverse should be sent as a refusal
   (this must be NO ECHO, since neither party can refuse a change into
   NO ECHO).  To state these rules more formally:

私たちの仕様では、接続が開かれるときはいつも、サーバとユーザの両方が、ユーザが局所的に反響していると仮定します。 ユーザが、サーバが反映するのを事実上好むなら、ユーザはECHOコマンドを送るかもしれません。 サーバが、好むなら同様に、反響してください、(例えば、サーバシステムが非常に対話的な反響のために最適化される、)、サーバはECHOコマンドを送るかもしれません。 どちらも何もするのに必要でなく、それは好みの問題にすぎません。 何れの当事者によるコマンドを受け取り次第、受取人は、それが操作の容認できるモードであるならそのモードで作動し始めるべきです、そして、そのような操作が流行していた状態で変化を反映するなら、それは(そして、いつ)転換が行われたかと確認する同じコマンドでこたえるべきです。 容認されたコマンドであるなら、操作の承認しがたいモードを要求してください、コマンドの逆が拒否として送られるべきであるその時(これはNO ECHOであるに違いありません、どちらのパーティーもNO ECHOへの変化を拒否できないので)。 これらを述べるのは、より正式に統治されます:

      1) Both server and user assume that a connection is initially in
         NO ECHO mode.

1) サーバとユーザの両方が、接続が初めはNO ECHOモードであると仮定します。

      2) Neither party can refuse a request to change into NO ECHO mode.

2) どちらのパーティーもNO ECHOモードに変化するという要求を拒否できません。

      3) Either party may send an unsolicited command only to request a
         change in mode.

3) 何れの当事者は単に流行していた状態で変化を要求する求められていないコマンドを送るかもしれません。

Cosell & Walden                                                 [Page 2]

RFC 435                      TELNET Issues                5 January 1973

コーセルとウォルデン[2ページ]RFC435telnetは1973年1月5日を発行します。

      4) A party only changes its echo mode when it receives an
         admissible request.

4) 容認できる要求を受け取るときだけ、パーティーはエコーモードを変えます。

      5) When a command is received, the party replies with its echo
         mode, unless it did not have to change mode to honor the
         request.

5) コマンドが受け取られているとき、パーティーはエコーモードで返答します、要求を光栄に思うためにモードを変えなければならなかったなら。

   Several properties of this scheme are worthy of note:

この体系の数個の特性が注意にふさわしいです:

      1) NO ECHO is retained as the nominal connection mode.  A
         connection will work in ECHO mode only when both parties agree
         to operate that way.

1) NO ECHOは名目上の接続モードとして保有されます。 双方が、そのように作動するのに同意するときだけ、接続はECHOモードで働くでしょう。

      2) The procedure cannot loop.  Regardless of which party (or both)
         initiates a change, or in what time order, there are at most
         three commands sent between the parties [2].

2) 手順は輪にされることができません。 どのパーティー(ともに)が変化を起こすか、または何時で注文するかにかかわらず、パーティー[2]の間に送られた3つのコマンドが高々あります。

      3) Servers are free to specify their preferred mode of operation.
         Thus, human, or machine, users do not have to learn the proper
         mode for each server.

3) サーバは無料でそれらの操作の最もよく使われる方法を指定できます。 したがって、人間、またはマシン、ユーザが各サーバのために適切なモードを学ぶ必要はありません。

Three Principles

3つの原則

   Let us mention the general principles we alluded to at the beginning
   of this note.  The principles are: default implementation, negotiated
   options and symmetry.  The principle of default implementation merely
   states that for all options, defaults are declare which must be
   implemented.  It is this principle which leads us to seek out the
   'minimum' for each option (to keep the required burden on everybody
   as small as possible), and prevents loops in protocol.  The principle
   of negotiated options merely states that options must be agreed upon
   by all (both) parties concerned.  It is this principle which dictated
   the positive/negative acknowledgement scheme.  The principle of
   symmetry merely states that neither party should have to 'know'
   whether it is the server or the user.  Our scheme, as described thus
   far, is not totally symmetrical we will consider this matter in a
   later section.

私たちがこの注意の始めに暗示した綱領を参照しましょう。 原則は以下の通りです。 デフォルト実装、交渉されたオプション、および対称。 単にデフォルトがすべてのオプションのための、そうである州がどれを宣言するかというデフォルト実装の原則を実装しなければなりません。 それは私たちが各オプション(できるだけ小さいみんなの上に必要な負担を保つ)のために'最小限'を捜し出すように導いて、プロトコルで輪を防ぐこの原則です。 交渉されたオプションの原理は、パーティーが関したすべて(両方)がオプションに同意しなければならないと単に述べます。 それは肯定しているか否定している承認体系を決めたこの原則です。 対称の原則は、どちらのパーティーも、それがサーバかそれともユーザであるかを'知る必要はないはずである'と単に述べます。 これまでのところ説明される私たちの体系は完全に対称の私たちが後のセクションでこの件を考えるつもりであるということではありません。

   The ECHOING scheme we have described, together with the principles
   stated above, form the heart of our comments on the TELNET protocol.
   The remainder of this note consists of further ways in which the
   protocol can be expanded on the whole, these suggestions are all
   really only applications and development of the principles we have
   already put forward.  However, the fecundity of these expansions, and
   the 'good feel' they have, make us yet more convinced of the '
   rightness' of our original proposals.

私たちが原則と共に説明したECHOING体系は、上に、TELNETプロトコルの私たちのコメントの心を形成するように述べました。 これらの提案は、私たちが既に提唱した原則のこの注意の残りがプロトコルを概して広げることができるさらなる方法から成って、すべての本当に唯一のアプリケーションと開発です。 しかしながら、これらの拡張の多産、およびそれらにはある'良い感じ'はまだ私たちの起案の'公正'で、より確信していた状態で私たちを作っています。

Cosell & Walden                                                 [Page 3]

RFC 435                      TELNET Issues                5 January 1973

コーセルとウォルデン[3ページ]RFC435telnetは1973年1月5日を発行します。

   Thus far, we have made a simple, concrete suggestion that we believe
   should be immediately sanctioned.  Looking beyond that proposal,
   however, has suggestion a large number of further, more ambitious
   changes.  The remainder of this RFC describes ideas which we don't
   feel have the immediacy of the proposal above, but should,
   nonetheless, be kept in mind if the network community decides to
   embark on revamping the protocol.

これまでのところ、私たちはすぐに認可されるべきであると信じている簡単で、具体的な提案をしました。 しかしながら、その提案の先を見るのにおいて、より遠くて、より野心満々の変化の提案多くがあります。 このRFCの残りは、私たちが上の提案の早急を持っていると感じない考えについて説明しますが、ネットワーク共同体が、プロトコルを改造するとき乗り出すと決めるなら、それにもかかわらず、覚えておかれるべきです。

Synchronization

同期

   One complaint we have heard about the present convention for
   establishing an echoing mode is about the lack of a provision to
   synchronize a change of echoing mode with the user-to-server data
   stream our scheme, too, is guilty on this count.  John Davidson of
   the University of Hawaii has documented, in RFC 357, a more elaborate
   echoing scheme which doesn't have this problem.  We, however, feel
   that it is possible to eliminate most of the trouble involved with
   normal changing of echo mode at a more modest cost than that required
   by the highly interactive scheme described by Davidson.  We can do
   this by borrowing a small piece of that scheme.  The rule we would
   incorporate is that whenever a party initiates a request for a change
   in echo mode, it then buffers, without transmitting or processing,
   all data in the user-to-server data stream until it receives an
   acknowledgement, positive or negative, at which time it deals with
   the buffered data in the newly negotiated mode.  Since with both our
   proposed and the current schemes such a request is guaranteed to be
   acknowledgement, the buffering time is bounded.

私たちが反響モードを確立するために現在のコンベンションに関して聞いた1つの苦情はまた、私たちの体系もこの点に関してはユーザからサーバへのデータ・ストリームがある反響モードの変化を連動させる支給の不足に関して、有罪であるということです。 ハワイ大学のJohn Davidsonはこの問題を持っていないより精巧な反響体系をRFC357に記録しました。 しかしながら、私たちは、ディヴィッドソンによって説明された非常に対話的な体系によって必要とされたそれより穏やかな費用におけるエコーモードの正常な変化に伴われる問題の大部分を排除するのが可能であると感じます。 私たちは、その体系の小さい断片を借りることによって、これができます。 私たちが取り入れる規則は次に、パーティーがエコーモードで珍しく要求を開始するときはいつも、伝えるのも処理なしでユーザからサーバへのデータ・ストリームですべてのデータをどの時に新たに交渉されたモードによるバッファリングされたデータに対処するかとき肯定しているか否定している承認を受けるまでバッファリングするということです。 そして、以来、両方、私たち、提案、電流がそのようなaを計画するので、要求はバッファリング時間は承認に、なるように境界があるのが保証されます。

   An important aspect of this technique of eliminating the
   synchronization problem is that it need not ever become part of the
   official protocol.  Since its operation is entirely internal to the
   server or user, each may independently weigh the value of elegance
   against the cost of the required code and buffer space.

同期問題を解決するこのテクニックの重要な一面は公式のプロトコルの一部になる必要はないということです。 サーバかユーザにとって、操作が完全に内部であるので、それぞれが独自に必要なコードとバッファ領域の費用に優雅の値について比較考量するかもしれません。

Other options

別の選択肢

   Abhay Bushan has suggested to us that whether the user and server
   operate line-at-a-time or character-at-a-time mode (see RFC 318)
   should also be a negotiated option.  Further, he suggested that
   whether the terminal follows the TELNET end-of-line convention or not
   should also be negotiated.  Thus, when a connection is opened, in
   addition to being set to NO ECHO mode, the terminal would also be set
   to LINE-AT-A-TIME and EOL modes.  We could augment the command space
   with the new commands LINE, NO LINE (=CHARACTER), EOL and NO EOL
   (=separate CR and LF).

Abhay Bushanは、また、ユーザとサーバが一度に系列か一度にキャラクタモードを操作するかどうかが(RFC318を見てください)、交渉されたオプションであると私たちに示唆しました。 さらに、彼は、また、端末がTELNET行末規約に続くかどうかが交渉されるべきであると示唆しました。 したがって、また、NO ECHOモードに設定されることに加えて接続が開かれるとき、端末は線アーター族Aタイム誌とEOLモードに設定されるでしょう。 新しいコマンドの線、線がなく(キャラクターと等しい)、EOL、およびNO EOL(別々のCRとLFと等しい)によると、私たちはコマンドスペースを増大させることができました。

Cosell & Walden                                                 [Page 4]

RFC 435                      TELNET Issues                5 January 1973

コーセルとウォルデン[4ページ]RFC435telnetは1973年1月5日を発行します。

   Once started in this direction, we found several further
   applications.  HIDE YOUR INPUT could be made an option, as could
   Davidson's echoing scheme, and even the character set to be used!
   Consider that an APL subsystem might well want to suggest to its user
   that EBCDIC be used for the connection.

いったんこの方向に始められると、私たちはさらなるいくつかのアプリケーションを設立します。 HIDE YOUR INPUTを作ることができた、ディヴィッドソンの反響体系であることができたことのようなオプション、および使用されるべき文字集合さえ! APLサブシステムが、EBCDICが接続に使用されるのをたぶんユーザに示したがっているだろうと考えてください。

   In mentionaing that the character set could be negotiated, it was
   implicit that 7-bit USASCII was the default.  The possibility of
   having the default be straight binary suggests itself.  If we
   augmented the protocol with a QUOTE character, the byte after which
   were to be always interpreted as data, then codes 128-255 could be
   retained as the 'TELNET command space' independently of the data mode
   in use by merely prefixing all data bytes in this region with a
   QUOTE.  If BINARY were a permissible data mode, then it is easy to
   visualize many higher level protocols, e.g., perhaps, File Transfer
   and Graphics, being built on top of, and into, the TELNET protocol.
   What we would have accomplished is to promote TELNET from being a
   constrained, terminal-oriented protocol to its being a flexible,
   general protocol for any type of byte oriented communication.  With
   such a backbone, many of the higher level protocols could be designed
   and implemented more quickly and less painfully -- conditions which
   would undoubtedly hasten their universal acceptance and availability
   [3].

それをmentionaingすることにおける文字集合を交渉できて、7ビットのUSASCIIがデフォルトであったのは暗黙でした。 デフォルトがまっすぐなバイナリーであることを持っている可能性は連想されます。 私たちがQUOTEキャラクタと共にプロトコルを増大させたなら、QUOTEと共にこの領域にすべてのデータ・バイトを単に前に置くことによって使用中のデータモードの如何にかかわらず'TELNETコマンドスペース'としてどれがデータとしていつも解釈されるためにあって、次に、128-255をコード化するか保有されることができた後にバイトです。 BINARYが許されているデータモードであるなら、例えば恐らく多くの、より高い平らなプロトコル、File Transfer、およびGraphicsを想像するのは簡単でしょうに、プロトコルとTELNETプロトコルの中に建てられて。 私たちが達成したことはどんなタイプのバイトの指向のコミュニケーションのためにも強制的で、端末指向のプロトコルであるのからそれがフレキシブルで、一般的なプロトコルであるのにTELNETを促進することになっています。 そのようなバックボーンで、よりはやくそれほど痛々しいほどないより高い平らなプロトコルの多くを設計して、実装することができませんでした--確かにそれらの普遍的な承認と有用性[3]を急がせる状態。

   Looking toward a better world of the future, we have come up with a
   more compact and flexible command scheme.  We'll describe it after
   the next section.

未来の来世に向かって見えて、私たちは、よりコンパクトでフレキシブルなコマンド体系を思いつきました。 私たちは次のセクションの後にそれについて説明するつもりです。

Symmetry

対称

   Some of the TENEX group (in particular, Thomas, Burchfiel and
   Tomlinson) have pointed out to us that although we have made the
   rules for the protocol symmetrical, we have not made the meanings of
   the commands symmetrical.  For example, the interpretations of the
   ECHO command -- 'I'll echo to you' and 'You echo to me' -- implicitly
   assume that both the server and user know who is which.  This is a
   problem not only for server-server connections where it is not clear
   which is the user, but also for user-user connections, e.g., in
   linking Teletypes together, where it is not clear which is the
   server.

TENEXグループ(特にトーマス、Burchfiel、およびトムリンスン)のいくつかが、プロトコルのための規則を対称にしましたが、私たちがコマンドの意味を対称にしていないと私たちに指摘しました。 例えば、ECHOコマンドの解釈('Iはあなたに反響し'て'あなたは私に反響する')が、サーバとユーザの両方が、だれがいるかを知っているとそれとなく仮定する、どれですか? これは、サーバサーバ接続でないののためだけのどれがユーザであるかが明確でない問題ですが、ユーザユーザ接続、例えば、一緒にテレタイプをまたリンクすることにおいてそのような問題です。(そこでは、どれがサーバであるかが明確ではありません)。

   Responding to this, we came to understand that there are only five
   reasonable modes of operation for the echoing on a connection pair
   [4]:

これに応じて、私たちは接続組[4]での反響のための5つの妥当な運転モードしかないのを理解するようになりました:

Cosell & Walden                                                 [Page 5]

RFC 435                      TELNET Issues                5 January 1973

コーセルとウォルデン[5ページ]RFC435telnetは1973年1月5日を発行します。

                         <------------------<
   A          Process 1                        Process 2
                         >------------------>
                         neither end echoes

<。------------------<はプロセス1プロセス2>です。------------------どちらの終わりの>は反響します。

                         <------------------<
   B          Process 1  <--+                  Process 2
                            ^
                         >--^--------------->
                        one end echoes for itself

<。------------------<Bプロセス1<--^+ プロセス2>--^---------------それ自体のための>片端エコー

                         <------------------<
   C          Process 1  <--------------+     Process 2
                                        ^
                         >--------------^--->
                        one end echoes for the other

<。------------------<Cプロセス1<。--------------^+ プロセス2>。--------------^---もう片方のための>片端エコー

                         <--------------V---<
   D          Process 1  <--+           V       Process 2
                            ^           +--->
                         >--^--------------->
                        both ends echo for themselves

<。--------------V---<Dプロセス1<--+ Vプロセス2^ +--->>--^---------------両端が自分たちのために反響する>。

                         <-----V------------<
   E          Process 1  <--+  V               Process 2
                            ^  +------------>
                         >--^--------------->
                        one end echoes for both ends

<。-----V------------<Eプロセス1<--+ Vプロセス2^ +------------>>--^---------------両端への>片端エコー

   The TENEX group suggested to us that four commands are sufficient to
   deal with completely symmetric echoing.  We have actually already
   mentioned the four commands -- the two possible meanings for each of
   ECHO and NO ECHO.  Explicitly, the commands would be I'LL ECHO TO
   YOU, YOU ECHO TO ME, DON'T ECHO TO ME and I'LL NOT ECHO TO YOU.
   Echoing is now the negotiation of two options, and the initial,
   default modes are DON'T ECHO TO ME and I'LL NOT ECHO TO YOU.

TENEXグループは、4つのコマンドが完全に左右対称の反響に対処するために十分であると私たちに示唆しました。 私たちは実際に既に4つのコマンドについて言及しました--2つのそれぞれのECHOとNO ECHOに、可能な意味。 私はそうするつもりです。明らかに、コマンドがそうであるだろう、ECHO TO YOU、YOU ECHO TO ME、DON'T ECHO TO ME、および私はNOT ECHO TO YOUがそうするつもりです。 現在反響は2つのオプションの交渉です、そして、初期のデフォルトモードはDON'T ECHO TO MEです、そして、私はNOT ECHO TO YOUをDON'T ECHO TO MEであるつもりであること。

   In the case where the server or user knows which he is, the
   modification to the scheme is minimal since the commands never had
   ambiguous meanings in these cases.  When an 'end' truly doesn't know,
   then things are a little more complicated -- for example, consider
   both ends in I'LL ECHO TO YOU mode, but even then the problems are
   not insurmountable.

サーバかユーザが彼がどれであるかを知っている場合では、コマンドにはこれらの場合におけるあいまいな意味が決してなかったので、計画への変更は最小限です。 '終わり'が本当に知らないと、いろいろなことはもう少し複雑です--例えば、Iの両端がそうすると考えてください、ECHO TO YOUモード、その時でさえ、問題は打ち勝ちがたくはありません。

Cosell & Walden                                                 [Page 6]

RFC 435                      TELNET Issues                5 January 1973

コーセルとウォルデン[6ページ]RFC435telnetは1973年1月5日を発行します。

   Once the principle of symmetry is adopted, it is no longer possible
   to use a function in two different ways.  On pages 5 and 6 of RFC
   318, Postel gives a description of INS and SYNC which indicates that
   they are used to simulate a 'break' user-to-server, but flush the
   output buffers server-to-user.  Since we do believe in symmetry, we
   suggest that the INS/DATA-MARK be treated the same in both directions
   and that a new CLEAR YOUR BUFFER option be added.

対称の原則がいったん採用されると、2つの異なった方法で機能を使用するのはもう可能ではありません。 5と6RFCページでは、318ポステルは彼らが'中断'のユーザからサーバをシミュレートするのに使用されるのを示すINSとSYNCの記述を与えますが、出力のバッファのサーバからユーザを洗い流してください。 対称を信じて、私たちは、DATAインス/マークが同じように両方の方向に扱われて、新しいCLEAR YOUR BUFFERオプションが追加されることを提案します。

Command Format

コマンド形式

   Extending full symmetry through the other options we have suggested,
   we can now describes the compacted command format referred to
   earlier.

別の選択肢で完全な対称について敷衍していて、私たちは示して、現在が、より早く形式が参照した圧縮されたコマンドについて説明する缶です。

   Rather than having four commands for each option (I WILL, I WON'T,
   YOU DO, YOU DON'T), there would be four 'prefixes' -- WILL, WON'T,
   DO, DON'T -- which would be used before the single command devoted to
   each option, WON'T and DON'T being the default modes.  To give an
   example, assume the codes for WILL and WON'T are 140 and 141, and the
   codes for ECHO REMOTE and HIDE INPUT are 132 and 133.  Then several
   of the possible command combinations would be:

有よりむしろ、4は各オプションのために命令します。(Iウィル、私がそうしないつもりである、あなたがして、そうしない、)、4'接頭語'があるでしょう--、ウィル、してください、--ただ一つのコマンドが各オプションに注がれる前に使用されるデフォルトモードであることはそうしないでしょう。 そして、一例をあげれば、ウィルのためにコードを仮定してください、HIDE INPUTは140、141、およびコードはECHO REMOTEのためのものであり、132と133歳になるでしょう。 そして、いくつかの可能なコマンド組み合わせは以下の通りでしょう。

                   140 133 -- DO HIDE INPUT
                   140 132 -- DO ECHO REMOTE
                   141 132 -- WON'T ECHO REMOTE
                   141 133 -- WON'T HIDE INPUT

140 133--入力140 132を隠してください--リモート141 132を反響してください--リモート141 133を反響しないでしょう--入力を隠さないでしょう。

   These are some of the commands that we believe should exist:

これらは私たちが存在するべきであると信じているコマンドのいくつかです:

   I WILL (140)
   I WILL NOT (141)
   YOU DO (142)
   YOU DO NOT (143)
   QUOTE (144)
   SYNC (163)
   SYNC REPLY (164)

あなたがNOT(143)引用文の(144)同時性(163)同時性回答をする(142)をするIウィル(140)IウィルNOT(141)(164)

   ECHO REMOTE (132)
   SEND A CHARACTER-AT-A-TIME (146)
   SEND INDEPENDENT CR and LF (147)
   SEND IN EBCDIC (162)
   HIDE INPUT (133)
   USE DAVIDSON'S ECHOING STRATEGY (145)

リモート(132)が一度に(146)が独立しているCRを送って、LF(147)がEBCDIC(162)獣皮で入力(133)使用を送るキャラクタディヴィッドソンの反響戦略を送るエコー(145)

   An important virtue of this command structure, and of our entire
   viewpoint, is that Hosts need no longer even be aware of what all the
   options are.  If we call the mode of operation in which every
   alternative is in its default state the 'NVT', then a site, of

この命令系統、および私たちの全体の観点の重要な美徳はHostsがもうすべてのオプションが何であるかを意識している必要さえないということです。 私たちがあらゆる選択肢がデフォルト状態の'NVT'、どれの当時のaサイトであるかで運転モードを呼ぶなら

Cosell & Walden                                                 [Page 7]

RFC 435                      TELNET Issues                5 January 1973

コーセルとウォルデン[7ページ]RFC435telnetは1973年1月5日を発行します。

   course, must handle an NVT, but beyond that if it merely responds no
   to any command it does not understand, then it can totally ignore
   options it chooses not to implement.  Thus, options would truly be
   optional (for a change), not only to the user who may choose not to
   invoke them, but also to the systems builders who may now choose not
   to offer them!

向こうでは、それはそれであるならそれが理解していない少しのコマンドにもいいえを単に反応させます、そして、コース、必須はNVTを扱いますが、次に、それは実行しないのを選ぶオプションを完全に無視できます。 したがって、本当に、オプションは任意でしょう(珍しい)、現在彼らを提供しないのを選ぶかもしれないシステム建築業者にも!

   We hereby volunteer to rigorously specify a version of TELNET which
   embodies the principles we have described and to do so at any level
   of complexity deemed sufficient by the network community.

私たちは私たちが説明した原則を具体化するTELNETのバージョンをきびしく指定して、十分であるとネットワーク共同体によって考えられたどんなレベルの複雑さでもそうするのをこれにより買って出ます。

Cosell & Walden                                                 [Page 8]

RFC 435                      TELNET Issues                5 January 1973

コーセルとウォルデン[8ページ]RFC435telnetは1973年1月5日を発行します。

Appendix: A Sample Implementation

付録: サンプル実現

   The basis scheme we described represents most of what we have been
   thinking about the further extensions are just that, extensions.  We
   fear, however, that some who are spiritually in league with us might
   be frightened off by the magnitude of all the changes we suggest.  To
   combat this, we here provide an example of how simply and straight-
   forwardly the basis scheme could be implemented for the TIP [5].

私たちが説明した基礎計画は、考えながら、私たちが者であることの大部分と表します。さらなる拡大はまさしくそれ(拡大)です。 しかしながら、私たちは、霊的にそうである或るものが私たちが勧めるすべての変化の大きさによって私たちがいるリーグで逃されるかもしれないと恐れます。 これと戦うために私たち、ここで、TIP[5]のためにどう簡単にまっすぐ強引に、基礎計画を実行できたかに関する例は提供されます。

   For each user terminal the TIP would keep three state bits: whether
   the terminal echoes for itself (NO ECHO always) or not (ECHO mode
   possible), whether the (human) user prefers to operate in ECHO or NO
   ECHO mode, and whether the connection to this terminal is in ECHO or
   NO ECHO mode.  We call these three bits P(hysical), D(esired) and
   A(ctual).

各ユーザ端末に関しては、TIPは、3状態がビットであることを保つでしょう: 端末がそれ自体のために反響する、(NO ECHO、いつも)、(可能なECHOモード)でない(人間)のユーザは、ECHOで作動するのを好まないか、そして、NO ECHOモードと、この端末との接続がECHOにないか、そして、NO ECHOモードでない。 私たちは、これらの3ビットをP(hysical)、D(esiredした)、およびA(ctual)と呼びます。

   When a terminal dials up the TIP, the P-bit is set appropriately, the
   D-bit is set equal to it, and the A-bit is set to NO ECHO.  The P-
   and A-bits may be manually reset by direct commands if the user so
   desires for instance, a user in Hawaii on a 'full-duplex' terminal
   might know that whatever the preference of a mainland server, because
   of satellite delay his terminal had better operate in NO ECHO mode --
   he would direct the TIP to change his D-bit from ECHO to NO ECHO.

TIPへの端末のダイヤル、P-ビットが適切に設定されて、D-ビットがそれと等しいセットであり、A-ビットがNO ECHOに設定されるとき。 '全二重'端末の上のハワイのユーザは本土サーバの好みが何であってもそれを知っています、NO ECHOモードで彼の端末がさせた作動するほうがよい衛星遅れのために--例えば、ユーザがそう望んでいるなら、PとA-ビットはダイレクトコマンドで手動でリセットされるかもしれなくて、彼は、彼のD-ビットをECHOからNO ECHOに変えるようTIPに指示するでしょう。

   When a connection is opened from the TIP terminal to a server, the
   TIP would send the server an ECHO command if the MIN (with NO ECHO
   less than ECHO) of the P- and D-bits is different from the A-bit.  If
   a NO ECHO or ECHO arrives from the server, the TIP will set the A-bit
   to the MIN of the received request, the P-bit and D-bit.  If this
   changes the state of the A-bit, it will send off the appropriate
   acknowledgement if it does not, then the TIP will send off the
   appropriate refusal if not changing meant that it had to deny the
   request (i.e., the MIN of the P- and D- bits was less than the
   received A- request).  If while a connection is open, the TIP
   terminal user changes either the P- or D-bit, the TIP will repeat the
   above tests and send off an ECHO or NO ECHO, if necessary.  When the
   connection is closed, the TIP would reset the A-bit to NO ECHO.

接続がTIP端末からサーバまで開かれるとき、PとD-ビットのMIN(NO ECHOがECHOより少ない)がA-ビットと異なるなら、TIPはECHOコマンドをサーバに送るでしょう。 NO ECHOかECHOがサーバから到着すると、TIPは受信された要求のMIN、P-ビット、およびD-ビットにA-ビットを設定するでしょう。 これがA-ビットの状態を変えて、送らないと、適切な承認を送って、変化でないのが、要求を否定しなければならないことを意味したなら(すなわち、PとDビットのMINは受信されたA要求以下でした)、次に、TIPは適切な拒否を送るでしょう。 接続がオープンですが、TIP端末ユーザがPかD-ビットを変えると、TIPは上のテストを繰り返して、必要なら、ECHOかNO ECHOを発送するでしょう。 接続が閉じられるとき、TIPはA-ビットをNO ECHOにリセットするでしょう。

   While the TIP's implementation would not involve ECHO or NO ECHO
   commands being sent to the server except when the connection is
   opened or the user explicitly changes his echoing mode, we would
   suppose that bigger Hosts might send these commands quite frequently.
   For instance, if a JOSS subsystem were running, the server might put
   the user in NO ECHO mode, but while DDT was running, the server might
   put the user in ECHO mode.

TIPの実現が接続が開かれる時を除いて、サーバに送られるECHOかNO ECHOコマンドを伴わないだろうか、またはユーザが、モードを反映するのを明らかに変えている間、私たちは、より大きいHostsがかなり頻繁にこれらのコマンドを送るかもしれないと思うでしょう。 例えば、ジョスサブシステムが走っているなら、サーバはNO ECHOモードにユーザを入れるでしょうにが、DDTが走っていた間サーバはECHOモードにユーザを入れるかもしれません。

Cosell & Walden                                                 [Page 9]

RFC 435                      TELNET Issues                5 January 1973

コーセルとウォルデン[9ページ]RFC435telnetは1973年1月5日を発行します。

   [1] We have assumed that TELNET is defined as suggested by Jon Postel
   in RFC 318.

[1] RFC318でジョン・ポステルによって提案されるように私たちは、TELNETが定義されると思いました。

   [2] Notice that a faulty implementation could achieve the effect of a
   loop by repeatedly sending a command which has previously been
   refused.  We consider this a property of the implementation, not of
   the scheme in general, a command which has be rejected should not be
   repeated until something changes -- for instance, not until after a
   different program has been started up.

[2] 不完全な実現が繰り返して以前に拒否されたコマンドを送ることによって輪の効果を実現するかもしれないのに注意してください。 私たちは、一般に、計画ではなく、実現のこのaの特性であり、何かが変化するまで、拒絶されたコマンドを繰り返すべきではありません--例えば、異なったプログラムが始動されていなかった後まで、上昇するように考えます。

   [3] Will Crowther, with an eye towards building higher protocols upon
   TELNET, has suggested that a SYNC command (not to be confused with
   the existing SYNCH), and a SYNC REPLY be added to TELNET.  For
   example, a server might want to wait until the output buffer of a
   user's terminal were empty before doing something like closing the
   connection or passing the connection to another server.  Although we
   see no current use for the command pair, they seem to be a handy
   enough building block that we recommend that they be included.

[3] より高いプロトコルをTELNETの上に建てることに向かった目で、ウィル・クラウザーは、SYNCコマンド(既存のSYNCHに混乱しない)、およびSYNC REPLYがTELNETに加えられることを提案しました。 例えば、ユーザの端末の出力バッファが接続を終えるか、または別のサーバに接続を通過するようにする前に空になるまで、サーバは待ちたがっているかもしれません。私たちはコマンドのどんな現在の使用も見ませんが、対にしてください、と含まれていて、彼らは私たちが推薦する彼らがいる十分便利なブロックになるように思えます。

   [4] It is perhaps appropriate to mention that most of the connections
   in the network are TELNET connections, which are full duplex.
   Wouldn't it be reasonable to make all Host/Host protocol connections
   full duplex, rather than simplex? If, for some reason, one truly
   needs a simplex connection, the reverse direction can always just be
   ignored.

[4] ネットワークにおける接続の大部分がTELNET接続であると言及するのは恐らく適切です(全二重です)。 シンプレクスよりむしろすべてのHost/ホストプロトコル接続全二重を作るのは妥当でないでしょうか? 人が本当にある理由でシンプレクス接続を必要とするなら、いつもただ反対の方向を無視できます。

   [5] Readers unfamiliar with the TIP may read the TIP Users Guide --
   NIC 10916.

[5] TIPになじみのない読者はTIP Usersガイドを読むかもしれません--NIC10916。

        [This RFC was put into machine readable form for entry]
    [into the online RFC archives by Helene Morin, Via Genie, 12/99]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ヘレーネのモーリン、Via GenieによるオンラインRFCアーカイブへの12/99]

Cosell & Walden                                                [Page 10]

コーセルとウォルデン[10ページ]