RFC1372 日本語訳
1372 Telnet Remote Flow Control Option. C. Hedrick, D. Borman. October 1992. (Format: TXT=11098 bytes) (Obsoletes RFC1080) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Hedrick Request for Comments: 1372 Rutgers University Obsoletes: RFC 1080 D. Borman Cray Research, Inc. October 1992
コメントを求めるワーキンググループC.ヘドリックの要求をネットワークでつないでください: 1372年のラトガース大学は以下を時代遅れにします。 RFC1080D.ボーマンクレイ・リサーチ1992年10月
Telnet Remote Flow Control Option
telnetのリモートフロー制御オプション
Status of This Memo
このメモの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Introduction
序論
This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions.
このドキュメントはいずれのRESTARTとRESTART-XON suboptionsの追加でTelnet Remote Flow Control Option、RFC1080年の拡張版を指定します。
1. Command Names and Codes
1. コマンド名とコード
TOGGLE-FLOW-CONTROL 33 OFF 0 ON 1 RESTART-ANY 2 RESTART-XON 3
1に関する0のトグルフロー制御33は-少しも2再開-XON3を再開します。
2. Command Meanings
2. コマンド意味
IAC WILL TOGGLE-FLOW-CONTROL
IACウィルトグルフロー制御
Sender is willing to enable and disable flow control upon command.
送付者は、コマンドのときにフロー制御を可能にし、無効にしても構わないと思っています。
IAC WONT TOGGLE-FLOW-CONTROL
IAC習慣トグルフロー制御
Sender refuses to enable and disable flow control. Nothing is implied about whether sender does or does not use flow control. It is simply unwilling to enable and disable it using this protocol.
送付者は、フロー制御を可能にして、無効にするのを拒否します。 送付者がするか、またはフロー制御を使用しないかに関して何も含意されません。 それを可能にして、無効にするのは、このプロトコルを使用することで単に不本意です。
IAC DO TOGGLE-FLOW-CONTROL
IACはトグルフロー制御をします。
Sender is willing to send commands to enable and disable flow control.
送付者は、フロー制御を可能にして、無効にするコマンドを送っても構わないと思っています。
Hedrick & Borman [Page 1] RFC 1372 Telnet Remote Flow Control Option October 1992
フロー制御オプション1992年10月にリモートなヘドリックとボーマン[1ページ]RFC1372telnet
IAC DONT TOGGLE-FLOW-CONTROL
IACドントトグルフロー制御
Sender refuses to send command to enable and disable flow control.
送付者は、フロー制御を可能にして、無効にするコマンドを送るのを拒否します。
IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE
IAC SEのIAC SBトグルフロー制御
Sender requests receiver to disable flow control.
送付者は、フロー制御を無効にするために受信機を要求します。
IAC SB TOGGLE-FLOW-CONTROL ON IAC SE
IAC SEの上のIAC SBトグルフロー制御
Sender requests receiver to enable flow control.
送付者は、フロー制御を可能にするよう受信機に要求します。
IAC SB TOGGLE-FLOW-CONTROL RESTART-ANY IAC SE
IAC SBトグルフロー制御いずれの再開IAC SE
Sender requests that when flow control is enabled, the receiver allow any character (except another XOFF) to restart output.
送付者は、フロー制御が可能にされるとき、どんなキャラクタ(別のXOFFを除いた)も受信機で出力を再開できるよう要求します。
IAC SB TOGGLE-FLOW-CONTROL RESTART-XON IAC SE
IAC SBトグルフロー制御再開-XON IAC SE
Sender requests that when flow control is enabled, the receiver allows only the XON character to restart output.
送付者は、フロー制御が可能にされるとき、XONキャラクタだけが受信機で出力を再開できるよう要求します。
3. Default Specification
3. デフォルト仕様
The default specification for this option is
このオプションのためのデフォルト仕様はそうです。
WONT TOGGLE-FLOW-CONTROL DONT TOGGLE-FLOW-CONTROL
習慣トグルフロー制御ドントトグルフロー制御
meaning flow control information will not be exchanged in either direction.
意味フロー制御情報はどちらの方向とも交換されないでしょう。
4. Motivation
4. 動機
This memo describes a method of remotely toggling flow control between a user telnet process and the attached terminal. Only flow control of data being transmitted from the telnet process to the terminal is considered. Many systems will also allow flow control of data from the terminal to the telnet process, however there is seldom need to change this behavior repeatedly during the session.
このメモはユーザtelnetプロセスと付属端末の間のフロー制御を離れて切り換えるメソッドを説明します。 telnetプロセスから端末まで送られるデータのフロー制御だけが考えられます。 しかしながら、また、端末からtelnetプロセスまでのデータのフロー制御を許容して、ある多くのシステムはセッションの間、めったに繰り返してこの振舞いを変える必要はありません。
There are two common ways of doing flow control: hardware and software. Hardware flow control uses signals on wires dedicated for this purpose. Software flow control uses one or two specific characters sent along the same path as normal input data. Most commonly, XOFF (control-S) and XON (control-Q) are used to stop and start output, respectively. The option described herein is useful primarily where software flow control is being used. (Since hardware flow control does not preempt any characters, there is normally no
フロー制御をする2つの一般的な方法があります: ハードウェアとソフトウェア。 ハードウェアフロー制御はこのために捧げられたワイヤの上の信号を使用します。 ソフトウェア・フロー制御は正常な入力データと同じ経路に沿って送られた1か2つの特定のキャラクタを使用します。 最も一般的に、XOFF(コントロールS)とXON(コントロールQ)はそれぞれ出力された停止と始めに使用されます。 ここに説明されたオプションは主としてソフトウェア・フロー制御が使用されているところで役に立ちます。 (ハードウェアフロー制御が少しのキャラクタも先取りしないので、通常いいえがあります。
Hedrick & Borman [Page 2] RFC 1372 Telnet Remote Flow Control Option October 1992
フロー制御オプション1992年10月にリモートなヘドリックとボーマン[2ページ]RFC1372telnet
need to disable it.) It should also be noted that flow control can either be generated automatically by the terminal when its buffers are close to overflowing, or manually by the user, when he/she cannot read the information as fast as it is being displayed, and unread information will start scrolling off the screen.
それを無効にするのが必要です。) また、その人が情報を読むことができないときオーバフローの近くにバッファがあるとき、端末で自動的にそのフロー制御を生成することができるか、またはユーザによって、手動で、それと同じくらい速いのが、表示することにされるのであることに注意されるべきです、そして、読まれていない情報はスクリーンでスクロールし始めるでしょう。
The primary difficulty with software flow control is that it preempts one or two characters. Host software often requires the user to be able to input every possible ASCII character. (Certain editors are notorious for having XOFF and XON as commonly-used commands.) For this reason, operating systems often allow programs to disable flow control. While it is disabled, the characters that normally signal flow control may be read as normal input. In a telnet environment, flow control is normally done by the user telnet process, not by the host computer. In addition, many operating systems, when flow control is enabled, the user may specify whether the XOFF character is the only character that is allowed to re-enable the output of data, or whether any typed character should re-enable the flow of data. Thus this RFC defines a way to propagate flow control status from the host computer to the user telnet process.
ソフトウェア・フロー制御におけるプライマリ困難は1か2つのキャラクタを先取りするということです。 ホストソフトウェアは、しばしばユーザがすべての可能なASCII文字を入力できるのを必要とします。 (一般的に使用されたコマンドとしてXOFFとXONを持っているのに、確信しているエディタは悪名高いです。) この理由で、オペレーティングシステムで、プログラムはしばしばフロー制御を無効にすることができます。 それは障害がある間、通常、フロー制御を示すキャラクタが通常の入力と読まれるかもしれません。 telnet環境で、通常、ユーザtelnetプロセスはホストコンピュータでするのではなく、フロー制御をします。 フロー制御が可能にされるとき、追加、多くのオペレーティングシステムで、ユーザは、XOFFキャラクタがデータの出力を再可能にすることができる唯一のキャラクタであるかどうかかそれとも何かタイプされたキャラクタがデータの流れを再可能にするべきであるかどうか指定するかもしれません。 したがって、このRFCはホストコンピュータからユーザtelnetプロセスまでフロー制御状態を伝播する方法を定義します。
5. Description of the Option
5. オプションの記述
Use of the option requires two phases. In the first phase, the telnet processes agree that one of them will TOGGLE-FLOW-CONTROL. WILL and DO are used only in this first phase. In general there will be only one exchange of WILL and DO for a session. Subnegotiations must not be issued until DO and WILL have been exchanged. It is permissible for either side to turn off the option by sending a WONT or DONT. Should this happen, no more subnegotiations may be sent, unless the option is re-enabled by another exchange of DO and WILL.
オプションの使用は二相を必要とします。 第1段階では、telnetプロセスは、それらの1つはTOGGLE-FLOW-CONTROLがそうするのに同意します。 してください。そして、この第1段階だけでは、使用されるでしょう。 一般に、ウィルの1回の交換だけであり、セッションのためにするでしょう。 してください。そうすれば、ウィルを交換するまでSubnegotiationsを発行してはいけません。 どちらの側もWONTかドントを送ることによってオプションをオフにするのは、許されています。 してください。これが起こるなら、より多くの副交渉を送るかもしれません、オプションが別の交換で再可能にされない場合そして、ウィル。
Once the hosts have exchanged a WILL and a DO, the sender of the DO TOGGLE-FLOW-CONTROL is free to send subnegotiations to enable and disable flow control in the other process, and to send subnegotiations for recommendations on when to restart output. Normally, the sender of the DO will be a host, and the other end will be a user telnet process, which is connected to a terminal. Thus the protocol is normally asymmetric, however it may be used in both directions without confusion should need for this arise.
ホストがいったんウィルとaがするaを交換すると、DO TOGGLE-FLOW-CONTROLの送付者は、もう片方のプロセスでフロー制御を可能にして、無効にして、いつ出力を再開するかときの推薦のために副交渉を送るために自由に副交渉を送ることができます。 通常送付者、終わりがユーザtelnetがプロセスであったならそうするaに接されるホスト、およびもう片方が端末であったなら、意志をしてください。 したがって、通常、プロトコルが非対称である、しかしながら、この必要性が起こるなら、それは混乱なしで両方の方向に使用されるかもしれません。
As soon as the DO and WILL have been exchanged, the sender of the WILL must enable flow control. This allows flow control to begin in a known state. The decision of whether to restart output only when the XON character is received, or when any character received, starts in a system dependent state. (This is to make it consistent with older implementations of the TOGGLE-FLOW-CONTROL option that do not understand the RESTART-ANY and RESTART-XON suboptions.) The sender
すぐに、してください、そして、交換していて、ウィルの送付者がフロー制御を可能にしなければならないということであってしまうでしょう。 これで、フロー制御は知られている状態で始まります。 XONキャラクタが受け取られているときだけ、出力を再開したかどうか、または何かキャラクタがいつ受信したかに関する決定はシステム属国で始まります。 (これはそれをいずれのRESTARTとRESTART-XON suboptionsを理解していないTOGGLE-FLOW-CONTROLオプションの、より古い実装と一致するようにするためのものです。) 送付者
Hedrick & Borman [Page 3] RFC 1372 Telnet Remote Flow Control Option October 1992
フロー制御オプション1992年10月にリモートなヘドリックとボーマン[3ページ]RFC1372telnet
of the DO should send either a RESTART-ANY or RESTART-XON suboption to put the restart characteristics to a know state. Some clients might not be able to support both of the RESTART-ANY and RESTART-XON modes due to system limitations, and would then choose to ignore these commands. There is no way for the server to be notified of this condition, but a client should make every attempt to honor the state requested by the RESTART-ANY and RESTART-XON modes. Should the option be disabled by exchange of DONT and WONT, flow control may revert to an implementation-defined default state. It is not safe to assume that flow control will remain in the state requested by the most recent subnegotiation.
してください。いずれのRESTARTを送るべきであるか、または再開の特性をaにつけるRESTART-XON suboptionは状態を知っています。 何人かのクライアントはシステム制限のためいずれのRESTARTとRESTART-XONモードの両方をサポートすることができないかもしれません、そして、次に、これらのコマンドを無視するのを選ぶでしょう。 サーバがこの状態について通知される方法が全くありませんが、クライアントは、いずれのRESTARTとRESTART-XONによって要求された状態を光栄に思うためにモードに最善の努力をするべきです。 オプションがドントとWONTの交換で無効にされるなら、フロー制御は実装で定義されたデフォルト状態に戻るかもしれません。 フロー制御が最新の副交渉によって要求された州に残ると仮定するのは安全ではありません。
In most implementations of software flow control, when enabled, the XOFF and XON characters are never propagated to the server; they are typically eaten by the terminal driver between the telnet client and the attached terminal. In most implementations that support the RESTART-ANY functionality, the typed character that re-enables the output is not eaten by the terminal driver, unless it is the XON character.
ソフトウェア・フロー制御の可能にされるとほとんどの実装では、XOFFとXONキャラクタはサーバに決して伝播されません。 それらはtelnetクライアントと付属端末の間の端末のドライバーによって通常食べられます。 いずれのRESTARTの機能性をサポートするほとんどの実装では、出力を再可能にするタイプされたキャラクタは端末のドライバーによって食べられません、それがXONキャラクタでないなら。
Currently, only four command codes are defined for the subnegotiations: flow control off (code 0), flow control on (code 1), restart output on any character (code 2) and restart output only on XON (code 3). None of these codes requires any additional data, however it is possible that additional commands may be added. Thus subnegotiations having command codes other than those defined in this document should be silently ignored.
現在、4つのコマンドコードだけが副交渉のために定義されます: (コード0)のフロー制御、(コード1)に関するフロー制御は、どんなキャラクタ(コード2)の上でも出力を再開して、XON(コード3)だけで出力を再開します。 これらのコードのいずれも追加データを必要としないで、しかしながら、追加コマンドが加えられるのは、可能です。 したがって、それら以外のコマンドコードを定義させる副交渉は本書では静かに無視されるべきです。
This option does not deal with the issue of allowing the DO side of the connection to inform the WILL side which characters should be used for XON and XOFF. That functionality is already supplied by the LINEMODE [1] option.
このオプションが許容の問題に対処しない、接続の側面をして、どのキャラクタがXONとXOFFに使用されるべきであるかをウィル側に知らせてください。 LINEMODE[1]オプションで既にその機能性を提供します。
Hedrick & Borman [Page 4] RFC 1372 Telnet Remote Flow Control Option October 1992
フロー制御オプション1992年10月にリモートなヘドリックとボーマン[4ページ]RFC1372telnet
6. Example
6. 例
Here is an example of the use of this option:
ここに、このオプションの使用に関する例があります:
Client Server IAC DO TOGGLE-FLOW-CONTROL IAC WILL TOGGLE-FLOW-CONTROL [ The server is now free to send commands to change flow control. Note that the client must now have enabled flow control, but that whether it is restart on XON only or on any character is client specific. ] IAC SB TOGGLE-FLOW-CONTROL RESTART-ANY IAC SE
クライアントサーバIACはトグルフロー制御IACウィルトグルフロー制御をします。[ サーバは現在、無料でフロー制御を変えるコマンドを送ることができます。 クライアントが現在、フロー制御を可能にしたに違いありませんが、それがXONだけの上、または、何かキャラクタにおける再開であるかどうかがクライアント特有であることに注意してください。 ] IAC SBトグルフロー制御いずれの再開IAC SE
[ The client should now switch to allowing output to restart when the user types any character, if the client is able to support that functionality. ] IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE IAC SB TOGGLE-FLOW-CONTROL ON IAC SE
[ユーザがどんな文字もタイプするとき出力が再開するのを許容するのにクライアントは現在切り替わるべきです、クライアントがその機能性をサポートすることができるなら。] IAC SEの上のIAC SE IAC SBトグルフロー制御のIAC SBトグルフロー制御
References
参照
[1] Internet Engineering Task Force, Telnet Working Group, D. Borman, Editor, "Telnet Linemode Option", RFC 1184, Cray Research, Inc., October 1990.
[1]インターネット・エンジニアリング・タスク・フォース、telnet作業部会、D.ボーマン、エディタ、「telnet Linemodeオプション」、RFC1184、クレイ・リサーチ、1990年10月。
Acknowledgments
承認
The original specification for this option was written by Charles Hedrick, and published as RFC 1080. The RESTART-ANY and RESTART-XON suboptions were defined and added to this version of the document by David Borman.
このオプションのための正式仕様書は、チャールズ・ヘドリックによって書かれていて、RFC1080として発表されました。 いずれのRESTARTとRESTART-XON suboptionsはデヴィッド・ボーマンによるドキュメントのこのバージョンに定義されて、追加されました。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Hedrick & Borman [Page 5] RFC 1372 Telnet Remote Flow Control Option October 1992
フロー制御オプション1992年10月にリモートなヘドリックとボーマン[5ページ]RFC1372telnet
Authors' Addresses
作者のアドレス
David Borman Cray Research, Inc. 655F Lone Oak Drive Eagan, MN 55121
デヴィッド・ボーマン・クレイ・リサーチ655FひとりのオークDriveイーガン、Mn55121
Phone: (612) 452-6650 Email: dab@CRAY.COM
以下に電話をしてください。 (612) 452-6650 メールしてください: dab@CRAY.COM
Charles Hedrick Director, LCSR Computing Facility Rutgers University 227 CORE Building P.O. Box 879 Piscataway, NJ 08855-0879
チャールズヘドリックディレクター、ビルP.O. Box879ピスキャタウェイ、LCSRコンピュータ設備ラトガース大学227コアニュージャージー08855-0879
Phone: (908) 932-3088 Email: hedrick@cs.rutgers.edu
以下に電話をしてください。 (908) 932-3088 メールしてください: hedrick@cs.rutgers.edu
Mailing List: telnet-ietf@CRAY.COM
メーリングリスト: telnet-ietf@CRAY.COM
Hedrick & Borman [Page 6]
ヘドリックとボーマン[6ページ]
一覧
スポンサーリンク