RFC559 日本語訳
0559 Comments on The New Telnet Protocol and its Implementation. A.K.Bushan. August 1973. (Format: TXT=10643 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group Abhay K. Bushan Request For Comments #559 MIT Project MAC NIC # 18482 August 15, 1973
ネットワークワーキンググループAbhay K.Bushanは1973年8月15日にコメント#のために559MITプロジェクトMAC NIC#18482を要求します。
Comments on the new TELNET Protocol and its Implementation
新しいTELNETプロトコルとそのImplementationのコメント
We at MIT-DN have implemented the new TELNET protocol (both server and user). This RFC describes our experience with the implementation (particularly the use of GO AHEAD) and in bringing the new User and Server TELNET's in operation (the new TELNET is not compatible with the old). We have a few suggestions here which should help other implementors and lead to a smoother transition to the new protocol.
MIT-DNの私たちは、新しいTELNETプロトコルが(サーバとユーザの両方)であると実装しました。 このRFCは実装(特にGO AHEADの使用)と稼働中であり新しいUserとServer TELNETを持って来る私たちの経験について説明します(新しいTELNETは老人と互換性がありません)。 私たちは、ここでの他の作成者を助けるべきであるいくつかの提案を持って、新しいプロトコルへの、より滑らかな変遷に導きます。
I. OUR TELNET SERVER IMPLEMENTATION
I. 私たちのtelnetサーバ実装
Our new server TELNET accepts both the "old" and the "new" TELNET "control sequences". Currently we have the ECHO and the "Suppress Go Ahead" options implemented and do the "right thing" to varying degrees with the Interrupt Process (IP), Erase Character (EC), Abort Output (AO), Are You There (AYT), Break, and Synch character sequences.
私たちの新しいサーバTELNETは「古さ」と「新しい」TELNET「制御配列」の両方を受け入れます。 現在の私たちは、ECHOとオプションが実装した「先で碁を抑圧してください」を持って、Interrupt Process(IP)、Eraseキャラクター(EC)、Abort Output(AO)、いろいろな度合いでAreがある「正しいもの」にあなたをします。There(AYT)、Break、およびSynchキャラクタシーケンス。
A. The ECHO Option
A. エコーオプション
The TELNET server comes up in the default local echo mode and accepts both the old and the new TELNET control sequences. The server starts the negotiation for remote echo (server echoing) by sending the sequence "IAC WILL ECHO" but changes the echo mode only when an affirmative "IAC DO ECHO" is received. After the cutoff date for old protocol we will stop "honoring" the old TELNET control sequences.
TELNETサーバは、デフォルトローカルエコーモードで来て、老人と新しいTELNET制御配列の両方を受け入れます。 肯定「IACは反響すること」が受け取られているときだけ、サーバが、「IACは反響すること」を系列に送りますが、エコーモードを変化に送ることによって、リモートエコー(サーバ反響)のための交渉を始めます。 古いプロトコルのための締め日の後に、私たちは、古いTELNET制御配列を「光栄に思うこと」を止めるつもりです。
B. The Go Ahead and Suppress GA option
B. Go AheadとSuppressジョージアオプション
The server comes up in the send GA mode and transmits the required "IAC GA" sequence whenever the server detects that it needs to send a GA. It should be noted that our scheme for sending GA's works most but not all of the time.
サーバが来る、ジョージアモードを送って、サーバがそれを検出するときはいつも、必要な「IACジョージア」系列を伝える、それは、ジョージア州を送る必要があります。 私たちの送付ジョージアのものの体系が最も働いていますが、絶えず働いているというわけではないことに注意されるべきです。
There is really no reliable way for our server TELNET to find out when a process is actually waiting for network input. On our system, the server TELNET does not "control" user's process, it only acts as a terminal handler at the TTY level.
本当に、私たちのサーバTELNETが、プロセスがいつ実際にネットワーク入力を待っているかを見つけるどんな信頼できる方法もありません。 私たちのシステムの上では、サーバTELNETはユーザのプロセスを「制御しない」で、唯一のそれはTTYレベルにおける端末の操作者として行為です。
Bushan [Page 1] RFC 559 Comments on TELNET August 1973
Bushan[1ページ]RFC559はtelnet1973年8月にコメントします。
A quick investigation revealed that the above problem (of sending GA's reliably) is not confined to the ITS operating system alone. In fact TENEX (ref. conversation with Ray Tomlinson) and DEC-10 (ref. conversation with Ed Taft at Harvard) systems will encounter similar problems.
迅速な調査は、上の問題(ジョージアを確かに送る)が単独でITSオペレーティングシステムに閉じ込められないのを明らかにしました。 事実上、TENEX(審判レイ・トムリンスンとの会話)と12月-10台(審判ハーバードのエド・タフトとの会話)のシステムが同様の問題に行きあたるでしょう。
Our solution to the GA sending problem was to have the server wait 2.5 seconds after sending output to see if there is more output to be sent. If the server has been "idle" for more than 2.5 seconds in the "output-sent" state it sends a GA and goes in an I/O wait state (looking for input or output). This scheme works most (but not guaranteed all) of the time and doesn't cause any noticeable delay. It is possible for the server to send an extra GA. Our experimentation revealed that 1-5 seconds was a good range for this "idling time constant".
ジョージア送付問題への私たちの解決は出力を送った2.5秒後にサーバを送られるより多くの出力があるかどうかを見るのを待たせることでした。 サーバが2.5秒以上間、「出力で送られた」状態で「活動していません」なら、それは、ジョージアを送って、入出力待ち状態を調べます(入力か出力を探して)。 この体系は、大部分の時間(しかし、すべてを保証しない)に働いて、少しのめぼしい遅れも引き起こしません。 サーバが付加的なジョージアを送るのは、可能です。 私たちの実験は、1-5 秒がこの「アイドリング時定数」のための良い範囲であることを明らかにしました。
We do implement the "suppress GA" option and will not send GA to hosts who agree to negotiate out of it. Our server tries to negotiate these suppress GA option.
私たちは、「ジョージアを抑圧してください」というオプションを実装して、わかっていない状態で交渉するのに同意するホストにジョージアを送るつもりではありません。 これらを交渉する私たちのサーバトライはジョージアオプションを抑圧します。
C. Other Options and TELNET Control Sequences
C.別の選択肢とtelnet制御配列
Our server will refuse all other options by sending the appropriate DONTs and WONTs. In addition to the ECHO and Suppress GA options we recognize the following TELNET "control sequences".
私たちのサーバは、適切なDONTsとWONTsを送ることによって、すべての別の選択肢を拒否するでしょう。 ECHOとSuppressジョージアオプションに加えて、私たちは以下のTELNET「制御配列」を認識します。
1. Interrupt Process (IP) - The server substitutes the system wide interrupt character <control-Z> (ACII SUB) which immediately interrupts the process, moving control to the immediately superior process. If the user is several levels down his process tree he may have to send several IP's to reach top level. It should be noted that the IP does not interrupt the running process in the sense a <control-G> interrupts muddle but only passes control to the superior.
1. 中断Process(IP)--サーバはすぐにプロセスを中断するシステムの広い中断キャラクタ<制御装置Z>(ACII SUB)を代入します、コントロールをすぐに優れたプロセスに動かして。 ユーザがそうなら、彼が数個IPのものを範囲に送るために持っているかもしれないプロセス木の下側へのいくつかのレベルがレベルを上回っています。 IPがG>中断を制御している<混乱状態にもかかわらず、パスだけが上司に制御する意味で実行しているプロセスを中断しないことに注意されるべきです。
2. Erase Character (EC) - The server substitutes the system wide standard erase character <rubout> (ACII DEL). The deletion however is done not by the server but by the receiving process. It is conceivable that some process (such as a user TELNET) take no action on receiving EC. Most processes will echo the deleted character(s). Several EC's will delete the several previous characters. (If the console is declared to be an IMLAC, the deleted character is removed from the screen).
2. キャラクター(EC)を消してください--サーバはシステムの広い標準の消去文字<rubout>(ACII DEL)を代入します。 しかしながら、受信プロセスはサーバでするのではなく、削除します。 あるプロセス(ユーザTELNETなどの)がECを受けることへの行動を全く取らないのが想像できます。 ほとんどのプロセスが削除されたキャラクタの言葉を繰り返すでしょう。 数個ECのものは前のいくつかのキャラクタを削除するでしょう。 (コンソールがIMLACであると申告されるなら、削除されたキャラクタはスクリーンから外されます。)
3. Abort Output (AO) - The server substitutes the character <control-S> (ACII DC3). The control-S convention is followed by many but not all of our programs. The action taken on receiving AO varies with the program.
3. Output(AO)を中止してください--サーバはキャラクタ<コントロールS>(ACII DC3)を代入します。 すべてではなく、私たちのプログラムの多くがコントロールSコンベンションのあとに続きます。AOを受けながら帯びられた動作はプログラム通りに異なります。
Bushan [Page 2] RFC 559 Comments on TELNET August 1973
Bushan[2ページ]RFC559はtelnet1973年8月にコメントします。
A normal occurrence is that output and the current command are aborted (without necessarily going to completion). In many programs there is no way to stop output except by sending an IP and "killing" the inferior process.
通常の発生は出力と現在のコマンドが中止されるという(必ず完成に行くというわけではなくて)ことです。 多くのプログラムには、発信することによってIPと劣ったプロセスが「殺し」である以外に、出力を止める方法が全くありません。
4. Are You There (AYT) - The server will print the message "****connections still open*****" preceded and followed by CRLF's upon receiving an AYT. At some later time we may report on the state of the user's job as well.
4. 「あなたはThere(AYT)です--意志がAYTを受けながら」 ****接続がまだCRLFのものによって上位で続かれた*****を開いているというメッセージを印刷するサーバ 何らかの後の時間に、私たちはまた、ユーザの仕事の状態に関して報告するかもしれません。
5. Erase Line (EL) - since we are a character-at-a-time system, the EL has little meaning on our system and we throw it (and the preceding IAC) away.
5. 私たちが一度にキャラクタシステムであり、ELは私たちのシステムの上でほとんど意味がなくて、私たちがそれ(そして、前のIAC)を遠くに投げるので、線(EL)を消してください。
6. Break (BRK) - We substitute three NUL's upon receiving BRK. This convention is consistent with what happens when the "Break" key is hit on local teletypes. The programs generally do nothing useful when break is received (except echo "|@|@|@") but sending BRK may cause strange program reactions, so beware.
6. (BRK)を壊してください--BRKを受けるとき、私たちは3NULのものを代入します。 このコンベンションは「中断」キーが地方のテレタイプに打たれるとき起こることと一致しています。 The programs generally do nothing useful when break is received (except echo "|@|@|@") but sending BRK may cause strange program reactions, so beware.
7. Synch - Whenever the server receives the synch INS, it flushes all except the interesting (control sequences) characters till the receipt of a DM. We also cause an implicit IP on receipt of SYNCH.
7. 同時性--サーバが同時性INSを受けるときはいつも、それはDMの領収書までのおもしろい(制御配列)キャラクタを除いた皆を洗い流します。 また、私たちはSYNCHを受け取り次第内在しているIPを引き起こします。
8. We follow the CRLF and CRNUL convention for transmitting EOL and CR respectively.
8. 私たちはそれぞれEOLとCRを伝えるためのCRLFとCRNULコンベンションに続きます。
II. OUR USER-TELNET IMPLEMENTATION
II。 私たちのユーザtelnet実装
The new user-TELNET (implemented in CALICO NETWORK by using a new "TELCOM" subroutine), accepts negotiation for the ECHO and suppress GA options. The program tries to negotiate out of receiving GA's and tries the ECHO negotiation if the settings file for the host indicate remote echo. Special characters and symbols are defined for EC, EL, AO, AYT, BRK, SYNCH, IP, and the ESCAPE character to command level. These symbols have a default character value which the user can change by typing the symbol followed by the new character value at NETWRK command level. To send EC, EL, etc, the user only has to type the special character for the function. In addition the user can send these characters by using the send.special command at NETWRK command level. In "line mode", EC and EL do a "local" character and line erase rather than send the EC and EL to the remote host. The following are the default values for the "special" characters in TELNET :
新しいユーザ-TELNET(CALICO NETWORKでは、新しい"TELCOM"サブルーチンを使用することによって、実装される)、エコーのための交渉を受け入れて、Gaオプションを抑圧します。 ホストへの設定ファイルがリモートエコーを示すなら、プログラムは、ジョージアのものを受けないように交渉しようとして、ECHO交渉を試みます。 特殊文字とシンボルはEC、EL、AO、AYT、BRK、SYNCH、IP、およびESCAPEキャラクタのためにコマンドレベルと定義されます。 これらのシンボルには、ユーザがNETWRKコマンドレベルにおける新しい文字値があとに続いたシンボルをタイプすることによって変えることができるデフォルト文字値があります。 EC、ELなどを送るために、ユーザだけが機能のために特殊文字をタイプしなければなりません。 さらに、ユーザは、NETWRKコマンドレベルにsend.specialコマンドを使用することによって、これらのキャラクタを送ることができます。 「ライン・モード」では、ECとELはリモートホストに「地方」のキャラクタをして、ECとELを送るよりむしろ抹消を裏打ちします。 ↓これはTELNETの「特別な」キャラクタのためのデフォルト値です:
ESCAPE - backslash EC - <DEL> EL - <CAN> or |X AO - |S
またはESCAPE--、EC--<DEL>EL--バックスラッシュ<CAN>。|X AO、-|S
Bushan [Page 3] RFC 559 Comments on TELNET August 1973
Bushan[3ページ]RFC559はtelnet1973年8月にコメントします。
IP - |R AYT - |T Synch - |Y Break - no preassigned value.
IP、-|R AYT、-|Tの同時性、-|Y中断--いいえは値を「前-割り当て」ました。
The user can change his echo mode by escaping to NETWRK command level and using the commands "echo.local" or "echo.remote". Note that the modes are changed only when the negotiation for mode change is successful. In either event the user is notified of the results of the negotiation.
ユーザは、NETWRKコマンドレベルに逃げて、コマンド"echo.local"か"echo.remote"を使用することによって、彼のエコーモードを変えることができます。 モード変更のための交渉がうまくいっているときだけ、モードが変えられることに注意してください。 どっちみちユーザは交渉の結果について通知されます。
III. INSTALLING THE NEW TELNETS
III。 新しいtelnetをインストールします。
On Monday July 2, we brought up the user and server TELNETs briefly to find that most of the hosts did not "recognize" IAC's and did not honor the new protocol. Much to our dismay usage of both our server and user TELNET's was chaotic. Consequently, we did not install the new user and server TELNETs, and the old TELNETs remain operational.
7月2日月曜日に、私たちは、ホストの大部分がIACのものを「認識しない」で、また新しいプロトコルを光栄に思わなかったのがわかるためにユーザとサーバで簡潔にTELNETsを持って来ました。 私たちの私たちのサーバとユーザTELNETの両方の驚愕用法への多くが混沌としていました。 その結果、私たちは新しいユーザとサーバTELNETsをインストールしませんでした、そして、古いTELNETsは操作上のままで残っています。
The new and the old TELNETs are definitely not compatible. The server tries to (and should try to) negotiate out of sending GA's and also to send echo. This negotiation causes problems with the "old-style" user TELNETs. Also if the negotiation for Suppress GA is unsuccessfully (which is the case with "old" user-TELNETs) the server will keep sending IAC GA's when appropriate. One solution we found to making our "new" server compatible with "old" user TELNETs was to come up in a mode that does not start any option negotiation and does not send GA's unless requested to do so (ie default is to suppress GA"s). As mentioned earlier the server also accepts the old "TELNET control" sequences. This solution makes the server compatible with both the old and the new user TELNETs (except it violates protocol by not sending GA's). We propose to install this server on our socket 1.
新しいTELNETsと古いTELNETsは確実に互換性がありません。 サーバは、送付ジョージアのものから交渉して(そして、そうしようとするべきです)、また、エコーを送ろうとします。 この交渉は「古いスタイル」ユーザTELNETsと共に問題を起こします。 また、Suppressジョージアとの交渉が不成功(「古い」ユーザ-TELNETsがあるケースである)にそうなら、サーバは適切であるときに、IAC GAのものを送り続けるでしょう。 私たちが私たちの「新しい」サーバを「古い」ユーザTELNETsと互換性があるようにするのに見つけた1つのソリューションが少しのオプション交渉も始めないで、またそうするよう要求されない場合ジョージアのものを送らないモードで来ることになっていました。(ieデフォルトはジョージア「s)」を抑圧することです。 また、先に述べたようにサーバは古い「TELNETコントロール」系列を受け入れます。 このソリューションで、サーバは老人と新しいユーザTELNETsの両方(それを除いて、ジョージアを送らないことによって、プロトコルに違反する)と互換性があるようになります。 私たちは、私たちのソケット1にこのサーバをインストールするよう提案します。
To promote experimentation with the new TELNET protocol, we have installed the new server TELNET on socket 60 (octal 105). This new server follows the new protocol (ie it sends GA's) and starts spontaneous negotiation for remote echo and suppress GA. The implementors on other Hosts are encouraged to use this service to debug their user TELNETs (and our server). We feel that transition to the new protocol will be smoother if new TELNET servers are brought up on experimental sockets. We are also willing to help debug other servers from our User TELNET.
新しいTELNETプロトコルで実験を促進するために、私たちはソケット60(8進105)の上に新しいサーバTELNETをインストールしました。 この新しいサーバは、新しいプロトコル(それがジョージアのものを送るie)に従って、リモートエコーのための自然発生的な交渉を始めます、そして、ジョージアを抑圧してください。 他のHostsの上の作成者が彼らのユーザTELNETs(そして、私たちのサーバ)をデバッグするのにこのサービスを利用するよう奨励されます。 私たちは、新しいTELNETサーバが実験用ソケットの上に持って来られるなら新しいプロトコルへの変遷が、より滑らかになるのを感じます。 また、私たちは、私たちのUser TELNETから他のサーバをデバッグするのを助けます。
Finally we would like to lobby for making suppress GA the default (as our present server on socket 1). It appears that only a few Hosts require the GA's (AMES-67 and UCLA-CON). It seems to me that the reason why sending GA is default in the current specification of protocol is that representatives from the concerned Hosts wanted the GA to be
作成がジョージアを抑圧するので、最終的に運動したいと思います。デフォルト(ソケット1の上の私たちの現在のサーバとしての)。 ほんのいくつかのHostsがジョージアのもの(エームズ-67とUCLA-CON)を必要とするように見えます。 それはジョージアが関係があるHostsからの代表がなりたかった送付ジョージアがプロトコルの現在の仕様に基づきデフォルトである理由がいる私であるのにとって見えます。
Bushan [Page 4] RFC 559 Comments on TELNET August 1973
Bushan[4ページ]RFC559はtelnet1973年8月にコメントします。
implemented. It doesn't matter to them if sending GA or suppress GA is default, as long as they can get a remote server to send a GA. The protocol can be so specified as to require every one to implement a "send GA option". Making "suppress GA" the default will have the advantage that it will obviate unnecessary negotiation in a great majority of cases. Another advantage is that not sending GA's makes the new server compatible with both old and new user TELNETs.
実装される。 ジョージアを送るならそれらに重要でない、抑圧、ジョージアはデフォルトです、彼らがリモートサーバにジョージアを送らせることができる限り。 プロトコルはしたがって、「ジョージアオプションを送ってください」という皆がaを実装するのが必要であるほど指定されて、ことであるかもしれません。 デフォルトが持っている「ジョージアを抑圧してください」をそれがそうする利点にして、ケースの大多数における不要な交渉を取り除いてください。 別の利点はジョージアを送らないのに新しいサーバが古いものと同様に新しいユーザTELNETsと互換性があるようになるということです。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Serge Hallyn 9/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][セルジュHallyn9/97によるオンラインRFCアーカイブへの]
Bushan [Page 5]
Bushan[5ページ]
一覧
スポンサーリンク