RFC595 日本語訳

Network Working Group                                      Wayne Hathaway
Request for Comments # 595                                        AMES-67
NIC # 20617                                                   12 Dec 1973
References: NIC # 20812

コメント#595エームズ-67NIC#20617の1973年12月12日の参照箇所に関するワーキンググループウェインハザウェイRequestをネットワークでつないでください: NIC#20812

            Some Thoughts in Defense of the TELNET Go-Ahead

telnet開始許可のディフェンスにおけるいくつかの考え

This note is a reply to Edward Taft's "Second Thoughts on TELNET Go-
Ahead" (NIC #20812).  Specifically, I will attempt to show the
following about the three main directions of his objections:

この注意はエドワード・タフトの「telnetに関する考え直しは前方に行く」(NIC#20812)に関する回答です。 明確に、私は、彼の反論の3つの主な方向に関して以下を示すのを試みるつもりです:

     1. It is the idea of line-at-a-time systems which are esthetically
     unappealing, not the GA mechanism.  This may be a valid point, but
     given the large number of such systems on the net, it would seem a
     rather academic one.

1. それはジョージアメカニズムではなく、美的に非上告されている一度に線システムの考えです。 これは有効なポイントであるかもしれませんが、ネットのそのような多くのシステムを考えて、それはかなりアカデミックなものに見えるでしょう。

     2. The specified GA mechanism will in fact work very well between
     (reasonably implemented) line-at-a-time systems, and should provide
     significant help elsewhere.

2. 指定されたジョージアメカニズムは、事実上、(合理的に実行されています)の一度に線システムの間で非常によく働いて、重要な助けをほかの場所に提供するはずです。

     3. While the GA mechanism may not be correct in all cases, it can
     provide significant advantages fro the line-at-a-time systems and
     users.

3. ジョージアメカニズムがすべての場合で正しくないかもしれない間、それは一度に線システムとユーザを重要な利点froに供給できます。

   My comments will be arranged under the original headings from the
   subject RFC (NIC #20812).

私のコメントは対象のRFC(NIC#20812)からのオリジナルの見出しの下でアレンジされるでしょう。

"TECHNOLOGY"

「技術」

   The definitions of "half-duplex" and "reverse break" are
   satisfactory.  Two points should be made regarding "reverse break",
   however.  First: having reverse break on the terminal is of course not
   sufficient; the operating system must support it.  As "support" is
   equivalent to "require" in this context, it is not too surprising
   that some systems do not in fact do this.  That is, there are systems
   which will not type through an unlocked keyboard until the user
   manually turns the line around, and the operational problems with
   such systems are much less than might be assumed.  Second, at least on
   IBM 2741's and equivalent, the line turnaround takes a significant
   amount of time, during which user-typed characters may be missed or
   garbled.  In fact, a fairly standard mode of operation with systems
   that use reverse break (including TIP's) is to automatically enter
   a "line delete" character and start over every time the reverse break
   is used while typing, which can hardly be called esthetic.  One
   solution to this problem would be for the system to not use reverse
   break once the user has begun typing (as suggested near the end of
   NIC #20812), but most systems (including TIP's) do not do this.

「半二重」と「逆の中断」の定義は満足できます。 2ポイントは. しかしながら、「逆の中断」、1番目に関して指摘されるべきです: 逆が端末で壊れるのは、もちろん十分ではありません。 オペレーティングシステムはそれを支持しなければなりません。 「サポート」がこのような関係においては「必要である」ように同等であるので、事実上、いくつかのシステムがこれをしないのは、それほど驚くべきものではありません。 すなわち、ユーザが手動で線を変えて、そのようなシステムに関する運転上の問題が想定されるかもしれないよりはるかに少なくなるまでアンロックされたキーボードを通してタイプされないシステムがあります。 少なくともIBMのもの2741の2番目で同等です、線ターンアラウンドは重要な時かかります。(ユーザによってタイプされたキャラクタは、それの間、逃されているか、または誤り伝えられるかもしれません)。 事実上、逆の中断(TIPのものを含んでいる)を費やすシステムによる操作のかなり標準のモードが自動的にaに入ることである、「線は、」 キャラクタを削除して、逆の中断がタイプしている間に使用されている毎回の間、始動します。(それをほとんど美的であると呼ぶことができません)。 この問題の1つの解決がユーザがいったんタイプし始めたと(NIC#20812の終わり頃に示されるように)システムが逆の中断を費やさないだろうことですが、ほとんどのシステム(TIPのものを含んでいる)はこれをしません。

Hathaway                                                        [Page 1]

RFC 595            In Defense of the TELNET Go-Ahead       December 1973

進行命令のtelnet1973年12月のディフェンスにおけるハザウェイ[1ページ]RFC595

   Some discussion is also warranted at this point about line-at-a-time
   systems (hereafter abbreviated as LAAT systems).  One prime reason for
   LAAT operation is to avoid the overhead of interrupting the CPU (and
   possibly the user process) for every character typed.  Instead,
   characters are buffered (in a controller, a front-end computer, etc)
   until some "end-of-line" signal is received; they are then passed to
   the system in a group.  This means that the system is totally unaware
   that any typing has occurred until the "end-of-line" signal is sent;
   a partially completed line will literally never be recognized.

また、何らかの議論がここに一度に線システム(LAATシステムが今後簡略化されている)に関して保証されます。 LAAT操作の1つの主要な理由はすべてのキャラクタのためのCPU(そして、ことによるとユーザ・プロセス)がタイプした中断のオーバーヘッドを避けることです。 代わりに、何らかの「行末」信号が受信されるまで、キャラクタはバッファリングされます(コントローラ、フロントエンドコンピュータなどで)。 そして、それらはグループでシステムに通過されます。 これは、システムがどんなタイプも「行末」信号を送るまで起こったのを全く気づかないことを意味します。 部分的に完成した線は文字通り決して認識されないでしょう。

"ESTHETIC OBJECTIONS TO GA"

「ジョージアへの美的な反論」

   From the above, I feel that one can see that it is the operating mode
   of a system rather than the type of features of its terminals which
   determines whether GA is useful or not.  For example, IBM front-ends
   handle Teletypes in LAAT mode, while the TIP attempts to run 2741's
   as full-duplex devices (with something less than "a very good job at
   turning the line around," from my experience).

上記では、私は、人が、それが端末の特徴のタイプよりむしろジョージアが役に立つかどうか決定するシステムのオペレーティング・モードであると考えることができると感じます。 例えば、IBMフロントエンドはLAATモードによるテレタイプを扱います、TIPが、全二重装置(「線を変えるところの非常に良い仕事」より何か少ないもので私の経験に照らしてみると)として2741年代を走らせるのを試みますが。

   At any rate, the half-duplex/full-duplex debate can go on forever --
   the problem here is to try to smooth the way for users on local LAAT
   systems connected to foreign systems of varying characteristics.

いずれにせよ、半二重/全二重討論はいつまでも続くことができます--ここの問題はユーザのために特性を変える外国システムに接続されたローカルのLAATシステムの上で道を滑らかにしようとすることです。

"WHY GA WON'T WORK"

「ジョージアが働いていない理由」

   As mentioned, in LAAT systems no terminal input is recognized until
   the specified "end-of-line" character is entered, preceding characters
   having been buffered in a front-end etc.  This can of course be
   carried over into server TELNET: incoming network messages can be
   buffered at a very low level in the NCP awaiting a TELNET end-of-line
   signal.  User processes wanting input would remain blocked until the
   end-of-line is received, rather than being handed each character as
   it is read.  In fact, this is the implementation in all of the LAAT
   systems with which I am familiar.  The reason for doing this is
   obvious: many hosts continue to send single characters even in LAAT
   systems, resulting in a significant increase in overhead.  Equally
   obvious is the fact that in this mode the GA mechanism will function
   quite well, in fact as well as turning the line around to unlock the
   keyboard of a local terminal.

言及されるLAATシステムでは、指定された「行末」キャラクタが入られるまで、どんな端末の入力も認識されません、フロントエンドなどでバッファリングされたキャラクタに先行して もちろんサーバTELNETにこれを持ち越すことができます: TELNET行末信号を待ちながら、NCPで非常に低いレベルで入って来るネットワークメッセージをバッファリングできます。 入力を必要とするユーザ・プロセスが行末がそれが読まれるので各キャラクタに手渡されるよりむしろ受け取られているまで妨げられたままで残っているでしょう。 事実上、これは私が詳しいLAATシステムのすべてでの実現です。 これをする理由は明白です: オーバーヘッドのかなりの増加をもたらして、多くのホストが、LAATシステムでさえ単独のキャラクタを送り続けています。 等しく明白であるのは、事実上、全くよくであることローカル・ターミナルのキーボードをアンロックするために線を変えることと同様にこのモードで、ジョージアメカニズムが機能するという事実です。

Hathaway                                                        [Page 2]

RFC 595            In Defense of the TELNET Go-Ahead       December 1973

進行命令のtelnet1973年12月のディフェンスにおけるハザウェイ[2ページ]RFC595

   This further brings us what is to me one of the main reasons for the
   GA mechanisms: the need for a scheme similar to the above for user
   TELNET's.  The problem is as follows: a user TELNET on a LAAT system
   has no required "end-of-message" signal for incoming server-generated
   messages, and so is required to read each character as it comes, with
   attendant overhead.  In addition, the user process is forced to write
   each character as it arrives, since it never knows when the server
   will stop sending.  On systems which support reverse break this
   results in little more than erratic terminal behavior, but on systems
   which do not support it, it is left up to the user to manually turn
   the line around (which he can do reasonably well with "attention").
   Of course the overhead of handling character-at-a-time input on a
   line-at-a-time system is also significant.

これはさらに私へのジョージアメカニズムの主な理由の1つであることを私たちにもたらします: ユーザTELNETのもののための上記で同様の計画の必要性。 問題は以下の通りです: LAATシステムの上のユーザTELNETが入って来るサーバで発生しているメッセージのためのどんな必要な「メッセージの終わり」信号も持たないので、来るとき各キャラクタを読むのに必要です、付き添いのオーバーヘッドで。 さらに、到着するとき、ユーザ・プロセスはやむを得ず各キャラクタに書きます、サーバが、いつ発信するのを止めるかを決して知らないので。 システムの上では、どのサポート逆がこれを壊すかがただ不安定な端末の振舞いをもたらしますが、それを支持しないシステムの上では、それは手動で線を変えるのがユーザに任せられます(彼が「注意」で合理的に上手にできる)。 また、もちろん、一度に一度に線システムで入力された取り扱いキャラクタのオーバーヘッドも重要です。

   This is what I see as the most valuable reason for the GA mechanism,
   as was noted in NIC#20812: it is not so much a request for input as
   an assurance (although not an irrevocable one) that the server is
   through sending output.  In fact, that is what the name implies to me:
   go ahead, it's your turn to type, I'm through for a while.  Perhaps
   some of the objections would be eased if this aspect were given more
   emphasis? As an aside, the problem of spontaneous system messages
   that might be generated after a GA is sent is not a major one in
   practice, as the user will surely see the message as soon as he
   manually turns the line around (enters his next input line).  Note of
   course that the spontaneous message should also have a GA following,
   to serve as  "end-of-message" to the receiving NCP.  Further, if
   the user system supports reverse break, it can deliver the message as
   soon as it likes.

これはNIC#20812で注意されたように私がみなす中でジョージアメカニズムの理由最も貴重であることです: それは入力に関するサーバが送付出力であるという保証(呼び戻せないものではありませんが)と同じくらい多くの要求ではありません。 事実上、それは名前が私に含意することです: タイプするのが、あなたの番である、前に進んでください、そして、私はしばらくであることを通しています。 恐らく、より多くの強調をこの局面に与えるなら、反論のいくつかを緩和するでしょうか? 余談として、ジョージアを送った後に発生させるかもしれない自然発生的なシステムメッセージの問題は実際には主要なものではありません、彼が手動で線を変えると(彼の次の入力行に入ります)すぐに、ユーザが確実にメッセージを見るとき。 もちろんまた、自然発生的なメッセージが「メッセージの終わり」として受信NCPに機能するようにジョージアを次のであるするべきであることに注意してください。 さらに、ユーザシステム支援逆が壊れるなら、それは好きなだけすぐ、メッセージを送ることができます。

"IMPLEMENTATION PROBLEMS"

「実現問題」

   Perhaps the above discussion will remove some of the objections from
   this section? The GA should be sent when a system has a "reasonable
   assurance" that it is not going to generate additional output (eg,
   after a system prompt).  If this assumption turns out to be false
   there is no problem: the additional output is simply sent, also
   followed by a GA.  The main point here is that known multi-line output
   (eg, editor printout, message-of-the-day, SYSTAT) would have only the
   single GA on the end.

恐らく、上の議論はこのセクションから反論のいくつかを取り除くでしょうか? システムに追加出力(システムプロンプトの後のeg)を発生させないだろうという「手頃な保証」があると、ジョージアを送るべきです。 この仮定が誤っていると判明するなら、問題が全くありません: 追加出力も、単に送って、また、ジョージアによって続かれています。 ここの要点は知られているマルチ線出力(eg、エディタプリントアウト、1日のメッセージ、SYSTAT)が終わりに単一のジョージアしか持っていないだろうということです。

   Finally about linking.  I agree that on a system like TENEX links
   should probably not use GA's, but have you been involved in a
   link to a user on a LAAT system? The LAAT user is of course generating
   complete lines, which are sent over such a link.  This can
   be very disconcerting to a character-at-a-time user, who all of a
   sudden has dozens of characters printing at full terminal speed

最終的にリンクに関して。 TENEXリンクがたぶんジョージアのものを使用するはずがないように私はシステムでそれに同意しますが、あなたはLAATシステムの上でユーザへのリンクにかかわりましたか? LAATユーザはもちろん完全な線を発生させています。(線はそのようなリンクの上に送られます)。 これは一度にキャラクタユーザ(何十ものキャラクタに突然、完全な端末の速度で印刷させる)に混乱させることにおいてまさしくそのである場合があります。

Hathaway                                                        [Page 3]

RFC 595            In Defense of the TELNET Go-Ahead       December 1973

進行命令のtelnet1973年12月のディフェンスにおけるハザウェイ[3ページ]RFC595

   (often against the right margin).  And I can hardly imagine linking
   from a 2741 on a TIP to a TENEX user: one would never get anything
   typed, with all the line turnarounds.

(しばしばライト・マージンに対する。) そして、私は、TIPの上の2741年からTENEXユーザまでリンクするとほとんど想像できません: 1つで、すべての線ターンアラウンドで何も決してタイプしません。

   In fact, in all the linking that I have done from our (LAAT) system
   to TENEX we have very quickly agreed on a manual GA mechanism (eg,
   "over").  For straight conversational links I do not feel that it is
   unreasonable to have a simple way to ask your local process to send a
   GA (although GA is mostly defined in the server-to-user context,
   which breaks down somewhat here).  One further supportive comment: a
   spoken conversation is of course line-at-a-time, with "obvious cues"
   (pauses, questions, etc.) serving as GA's.  The situation is of course
   quite livable, even when spontaneous talk overrides the GA ("Oh,
   before you answer that, ...").  This occasionally results in the need to
   repeat a line, in an exact analogy to the problem of lines garbled by
   a reverse break or printed against the right margin.

事実上、私が私たちの(LAAT)システムからTENEXまでしたすべてのリンクでは、私たちは非常にすばやく、手動のジョージアメカニズム(eg、“over")に同意しました。 まっすぐな会話のリンクに関しては、私は、ジョージアを送るように地元の過程に頼む簡単な方法を持っているのが無理であると感じません(ジョージアはサーバからユーザへの文脈がほとんど定義されますが)。ここで文脈にいくらか失敗します。 さらなる1つの支持しているコメント: 話された会話はもちろん一度に「明白な手がかり」(くぎり、質問など)がジョージアのものとして機能する線です。 自然発生的な話がジョージア(「おお、以前あなたはそれに答える」)をくつがえすときさえ、状況はもちろん十分住みよいです。 これは時折線を繰り返す必要性をもたらします、逆の中断で誤り伝えられるか、またはライト・マージンに対して印刷された台詞の問題への正確な類推で。

   The problem of links containing system output intermixed with user
   input is more difficult.  In any implementation it seems the LAAT user
   will have to be aware of what is happening and manually control his
   terminal to some extent, but that is reasonable when dealing with an
   "alien" system.  More definition work is called for in this area, to
   solve the efficiency problem for LAAT hosts.

リンクがユーザ入力と共に混ぜられたシステム出力を含むという問題は、より難しいです。 どんな実現でも、LAATユーザが何が起こっているかを意識していて、手動で彼の端末をある程度制御しなければならないように思えますが、「異質」のシステムに対処するとき、それは妥当です。 この領域では、より多くの定義仕事がLAATホストのための効率問題を解決するように求められます。

"A PROPOSAL"

「提案」

   The proposal appears on the surface to be that "suppress GA" should
   be the NVT default, which would be perfectly acceptable to me (and I
   would suppose to other LAAT users): two additional messages upon
   opening a connection is a small enough price.

提案は「ジョージアを抑圧してください」が完全に許容できるだろうというNVTデフォルト(私は他のLAATユーザと思う)であるということである表面に現れます: 接続を開くことに関する2つの追加メッセージが十分わずかな価格です。

   But in fact that is not the proposal at all -- the proposal is really
   to remove the requirement that all server systems implement the GA.
   This I object to very strenuously since, as I feel I have shown, the
   benefit to the LAAT system and user of GA far outweigh its cost to
   other types of server systems.  And of course the expense of going
   into "suppress GA" mode when appropriate is truly negligible.

しかし、事実上、それは全く提案ではありません--提案は本当に、すべてのサーバシステムがジョージアを実行するという要件を取り除くことです。 私が、目立ったと感じるのでジョージアのLAATシステムとユーザへの利益以来このIは遠くに精力的にまさしくその反対します。他のタイプのサーバシステムへの費用を重くいてください。そして、適切であるときに、本当に、もちろん「ジョージアを抑圧してください」というモードを調べる費用は取るにたらないです。

   The proposal for having those user TELNET's which do not support
   reverse break retain permanent control over terminals is also weak,
   even without GA.  In our current implementation the assumption is that
   for each line entered by the user, the server system will respeed
   with something.  Control of the terminal is thus retained after input
   until some output is received and printed, when the terminal is again
   made available for input.  The "attention" key is defined as a toggle
   switch to control the terminal keyboard: if pressed while the
   keyboard is unlocked (open for input) it will lock it until the next
   available output message and if pressed while keyboard is locked

また、それらを持っていて、逆の中断を支持しないユーザTELNETのものが端末の永久的なコントロールを保有するので、提案も弱いです、ジョージアがなくても。 私たちの現在の実現では、仮定は何かで再促進されて、ユーザによって入られた各線に、サーバシステムがそうするということです。 何らかの出力が受けられて、印刷されるまで入力された後に端末のコントロールはこのようにして保有されます、再び端末を入力に利用可能にするとき。 「注意」キーは端末のキーボードを制御するためにトグルスイッチと定義されます: キーボードの錠が開いていますが(入力において、開いている)、押されると、次の有効出力メッセージ、キーボードがロックされますが、押されると、それはそれをロックするでしょう。

Hathaway                                                        [Page 4]

RFC 595            In Defense of the TELNET Go-Ahead       December 1973

進行命令のtelnet1973年12月のディフェンスにおけるハザウェイ[4ページ]RFC595

   it will be unlocked for input.  The user may also enter a true unlocked
   mode, in which the terminal is always returned to him for additional
   input (after printing all queued output).  This is used, for
   example, for input to a text editor which does not issue prompts for
   each line, the mode may be changed at any time by the user, and the
   "attention" key may of course be used to retrieve expected but
   infrequent output.  This combination mode has proven much more effective
   than the proposed "user must press attention for all input" mode.
   Of course the addition of GA will allow the user process to wait for
   a "complete" reply before printing anything, which will eliminate
   much of the use of "attention", as well as improve system efficiency.

それの錠は入力のために開いているでしょう。 また、ユーザは本当のアンロックされたモードを入れるかもしれません(すべてを印刷すると出力が列に並ばせた後に)。(端末は追加入力のためにそれで彼にいつも返されます)。 例えば、これは入力に各線のためのプロンプトを発行しないテキストエディタに使用されます、そして、モードはいつでもユーザによって変えられるかもしれません、そして、「注意」キーは、予想されましたが、珍しい出力を検索するのにもちろん使用されるかもしれません。 この組み合わせモードは提案された「ユーザはすべての入力のために注意を押さなければならなく」モードよりはるかに効果的であると判明しました。 もちろん、ユーザ・プロセスは、ジョージアの添加で、「注意」の使用の多くを排除する何でも印刷する前に、「完全な」回答を待って、システム効率を高めるでしょう。

A GRIPE OF MY OWN

私自身の不平

   I would like to add one complaint of my own at this point.  The
   implementation schedule for the new TELNET called for a date of July 1
   when systems should accept new TELNET without causing errors.
   This date was presumably agreed to by responsible representatives of
   effectively all active network sites.  My system has been using the
   new TELNET since early September (significantly after the allowable
   date) but I have been forced to disable all server-generated GA's
   because (among other problems) TENEX "SNDMSG" does not work when GA's
   are received over the FTP TELNET control connection.  Disabling the
   GA's was of course required in order for me to receive any deliveries
   from the Network Information Center.  This brings up three points.
   First, I sincerely hope that service functions like the NIC intend to
   accept the new TELNET protocol by the January 1 implementation date.
   Second, in response to RFC#593 by Alex McKenzie and Jon Postel, I do
   not feel that attempting to use a second TCP socket for "new TELNET"
   will work, because of the use of TELNET by FTP.  In fact, it does not
   seem too difficult to make a "compatible" TELNET which will accept
   either mode (which sites have had since July 1 to do) and I feel that
   this is the most reasonable implementation method, even if it makes
   the January 1 date impractical.  And third, perhaps sites should be
   more cautious about commitments to implementation schedules in the
   future.

ここに私自身の1つの苦情を加えたいと思います。 新しいTELNETのための遂行スケジュールはシステムが誤りを引き起こさないで新しいTELNETを受け入れるはずである7月1日を求めました。 おそらく、この日付は事実上すべてのアクティブなネットワークサイトの責任がある代表によって同意されました。 FTP telnetコントロール接続の上にジョージアのものを受け取るとき、私のシステムは(という(他の問題の中の)TENEX"SNDMSG"が発生しなかったので、許容できる期日) 私だけが強制された後に、かなり、すべてを無能にするのがジョージアのものをサーバで発生させた早めの9月の仕事以来の新しいTELNETを使用しています。 私がNetworkインフォメーション・センターからどんな配送も受け取るのにジョージアを無能にするのがもちろん必要でした。 これは3ポイントを持って来ます。 まず最初に、心からNICが1月1日実現日付までに新しいTELNETプロトコルを受け入れるつもりであるようにサービスが機能することを願っています。 2番目に、アレックス・マッケンジーとジョン・ポステルによるRFC#593に対応して私は、「新しいTELNET」に2番目のTCPソケットを使用するのを試みるのが働くと感じません、FTPによるTELNETの使用のために。 事実上、受け入れる「コンパチブル」TELNETをモード(7月1日以来サイトがするために持っている)にするようにあまりに難しく思えないで、私は、これが最も合理的な実現方法であると感じます、1月1日日付を非実用的にしても。 そして、恐らく、3番目に、サイトは将来、遂行スケジュールの委任に関して、より用心深いはずです。

         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Mirsad Todorovac 5/98 ]

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

Hathaway                                                        [Page 5]

ハザウェイ[5ページ]