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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

:first-letter擬似要素にマージンが設置されない

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る