RFC651 日本語訳
0651 Revised Telnet status option. D. Crocker. October 1974. (Format: TXT=4360 bytes) (Obsoleted by RFC0859) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Revised Telnet Status Option NIC 31154 (25 Oct. 74) Request for Comments: 651 D. Crocker (UCLA-NMC) 25 Oct. 74 RFC# 651 Online file: <[ISI]<DCROCKER>STATUS-OPTION-REVISION.RNO
改訂されたtelnet状態オプションNIC31154(1974年10月25日)はコメントのために以下を要求します。 651 D.クロッカー(UCLA-NMC)1974年10月25日のRFC#651Onlineはファイルします: <[ISI]<DCROCKER>状態オプション-REVISION.RNO
Revised Telnet Status Option 1. Command name and code STATUS 5 2. Command meanings As described in the NAOL and NAOP option specifications, this option applies to a simplex connection. IAC DO STATUS Sender of DO wishes to be able to send requests for status-of-options information, or confirms that he is willing to send such requests. IAC WILL STATUS Sender of WILL wishes or agrees to send status information, spontaneously or in response to future requests. IAC DON'T STATUS Sender refuses to carry on any further discussion of the current status of options. IAC WON'T STATUS Sender refuses to carry on any further discussion of the current status of options. IAC SB STATUS SEND IAC SE Sender requests receiver to transmit his (the receiver's) perception of the current status of Telnet options. The code for SEND is 1. (See below.) IAC SB STATUS IS ... IAC SE Sender is stating his perception of the current status of Telnet options. The code for IS is 0. (See below.) 3. Default DON'T STATUS/WON'T STATUS. That is, the current status of options will not be discussed. 4. Motivation for the option This option allows a user/process to verify the current status of Telnet options (e.g., echoing) as viewed by the person/process on the other end of the Telnet connection. Simply renegotiating options could lead to the nonterminating request loop problem discussed in (NIC #16237). The changes to the option, described in this paper, allow STATUS to fit into the normal structure of Telnet options, by deferring the actual transfer of status information to the SB command. Additionally, the numbers of bytes that must be sent to describe the state of the options has been considerably reduced. 5. Description of the option WILL/DO are now used only to obtain and grant permission for future discussion. The actual exchange of status information occurs within option subcommands (IAC SB STATUS...). Once the two hosts have exchanged a WILL and a DO, the sender of the WILL STATUS is free to transmit status information, spontaneously or in response to a request from the sender of the DO. At worst, this may lead to transmitting the information twice. Only the sender of the DO may send requests (IAC SB STATUS SEND IAC SE) and only the sender of the WILL may transmit actual status information (within an IAC SB STATUS IS ... IAC SE command). IS has the subcommands WILL, DO and SB. They are used EXACTLY as used during the actual negotiation of Telnet options, except that SB is terminated with SE, rather than IAC SE. Transmission of SE, as a regular data byte, is accomplished by doubling the byte (SE SE). Options that are not explicitly described are assumed to be in their default states. A single IAC SB STATUS IS ... IAC SE describes the condition of ALL options. The following is an example of use of the option: Host1: IAC DO STATUS Host2: IAC WILL STATUS (Host2 is now free to send status information at any time. Solicitations from Host1 are NOT necessary. This should not produce any dangerous race conditions. At worst, two IS's will be sent. Host1 (perhaps): IAC SB STATUS SEND IAC SE Host2 (the following stream is broken into multiple lines only for readability. No carriage returns are implied.): IAC SB STATUS IS WILL ECHO DO SUPPRESS-GO-AHEAD WILL STATUS DO STATUS WILL RCTE SB RCTE <11><1><24> SE DO NAOL SB NAOL DS <66> SE IAC SE Explanation of Host2's perceptions: It is responsible for echoing back the data characters it receives over the Telnet connection; it will not send Go-Ahead signals; it will both issue and request Status information; it will send instruction for controlling the other side's terminal printer; it will discuss the line width for data it is sending.
改訂されたtelnet状態オプション1。 コマンド名とコードSTATUS5 2。 NAOLとNAOPオプション仕様、このオプションで説明された意味Asがシンプレクス接続に適用すると命令してください。 IAC DO STATUS Sender、オプションの状態情報に関する要求を送ることができるという願望をするか、または彼が、そのような要求を送ることを望んでいると確認します。 ウィルのIAC WILL STATUS Senderは、願っているか、または自然か今後の要求に対応して状態情報を送るのに同意します。 IAC DON'T STATUS Senderは、オプションの現在の状態のどんなさらなる議論のときにも運ぶのを拒否します。 IAC WON'T STATUS Senderは、オプションの現在の状態のどんなさらなる議論のときにも運ぶのを拒否します。 IAC SB STATUS SEND IAC SE Senderは、彼のTelnetオプションの現在の状態の(受信機のもの)認知を伝えるよう受信機に要求します。 SENDのためのコードは1です。 (以下を見てください。) IAC SB状態はそうです… IAC SE Senderは彼のTelnetオプションの現在の状態の認知を述べています。 コード、0です。 (以下を見てください。) 3. デフォルトはそうしません。状態/は状態がそうしないでしょう。 すなわち、オプションの現在の状態について議論しないでしょう。 4. オプションThisオプションに関する動機で、ユーザ/過程はTelnet接続のもう一方の端の人/工程で見られるようにTelnetオプション(例えば、反響)の現在の状態について確かめることができます。 単に、再交渉オプションは(NIC#16237)で議論した非終了の要求輪の問題を引き起こすかもしれません。 STATUSはこの紙で説明されたオプションへの変化でTelnetオプションの正常な構造に収まることができます、状態情報の実際の転送をSBコマンドに延期することによって。 さらに、オプションの事情について説明するために送らなければならないバイトの数はかなり減少しました。 5. ウィル/がするオプションの記述は現在、使用されますが、今後の議論のために許可を得て、与えます。 状態情報の実際の交換はオプションサブコマンド(IAC SB STATUS…)の中に起こります。 一度、WILL STATUSの送付者が、2人のホストがウィルとaがするaを交換したと自由に自然か送付者からの要求に対応した状態情報を伝えることができる、してください。 最悪の場合は、これは、二度情報を伝えるのに通じるかもしれません。 してください。送付者だけ、ウィルの送付者だけが、要求(IAC SB STATUS SEND IAC SE)を送るかもしれなくて、実際の状態情報(IAC SB STATUS IS…IAC SEコマンドの中の)を伝えてもよいです。 サブコマンドウィル、してください。そして、SB。 それらはTelnetオプションの実際の交渉の間、使用されるように中古のEXACTLYです、SBがIAC SEよりむしろSEと共に終えられるのを除いて。 通常のデータ・バイトとして、SEのトランスミッションは、バイト(SE SE)を倍にすることによって、実行されます。 明らかに説明されないオプションがそれらのデフォルト州にあると思われます。 独身のIAC SB STATUS IS… IAC SEはすべてのオプションの状態について説明します。 ↓これはオプションで役に立つ例です: Host1: IACは状態Host2をします: Host2はいつでも、現在、自由に状態情報を送ることができます。IAC WILL STATUS、(Host1からの懇願は. これが. Atが負かすどんな危険な競合条件も作成するべきでなくて、2がそうであることが必要なNOTのものに. (恐らく)のHost1: IAC SB STATUS SEND IAC SE Host2を送るということです。(複数の線が読み易さのためだけに以下の流れに細かく分けられます。 復帰が全く含意されない、)、: IAC SB STATUS IS WILL ECHO DO SUPPRESS-GO-AHEAD WILL STATUS DO STATUS WILL RCTE SB RCTE <11><1><24> SE DO NAOL SB NAOL DS <66> SE IAC SE Explanation of Host2's perceptions: それはそれがTelnet接続の上で受けるデータキャラクタをecho backであるのに責任があります。 それは先のGoに信号を送らないでしょう。 それは、ともにStatus情報を発行して、要求するでしょう。 それは反対側の端末のプリンタを制御するための指示を送るでしょう。 それは送るデータのために線幅について議論するでしょう。
一覧
スポンサーリンク