RFC1143 日本語訳
1143 The Q Method of Implementing TELNET Option Negotiation. D.J.Bernstein. February 1990. (Format: TXT=23331 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Bernstein
Request for Comments: 1143 NYU
February 1990
コメントを求めるワーキンググループD.バーンスタイン要求をネットワークでつないでください: 1143 NYU1990年2月
The Q Method of Implementing TELNET Option Negotiation
telnetオプション交渉を実行するQ方法
Status of This Memo
このメモの状態
This is RFC discusses an implementation approach to option negotiation in the Telnet protocol (RFC 854). It does not propose any changes to the TELNET protocol. Rather, it discusses the implementation of the protocol of one feature, only. This is not a protocol specification. This is an experimental method of implementing a protocol. This memo is not a recommendation of the Telnet Working Group of the Internet Engineering Task Force (IETF). This RFC is Copyright 1990, Daniel J. Bernstein. However, distribution of this memo in original form is unlimited.
これによるRFCがTelnetプロトコル(RFC854)におけるオプション交渉への実現アプローチについて議論するということです。 それはTELNETプロトコルへの少しの変化も提案しません。 むしろ、それは1つの特徴だけのプロトコルの実現について議論します。 これはプロトコル仕様ではありません。 これはプロトコルを実行する実験的方法です。 このメモはTelnetインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の推薦ではありません。 ダニエル・J.バーンスタイン、このRFCはCopyright1990です。 しかしながら、原型における、このメモの分配は無制限です。
1. Introduction
1. 序論
This RFC amplifies, supplements, and extends the RFC 854 [7] option negotiation rules and guidelines, which are insufficient to prevent all option negotiation loops. This RFC also presents an example of correct implementation.
このRFCはRFC854[7]オプション交渉規則とガイドラインを敷衍して、補って、広げています。(ガイドラインは、すべてのオプションネゴシエーション・ループを防ぐためには不十分です)。 また、このRFCは正しい実現に関する例を提示します。
DISCUSSION:
議論:
The two items in this RFC of the most interest to implementors are 1. the examples of option negotiation loops given below; and 2. the example of a TELNET state machine preventing loops.
作成者への最も多くの関心のこのRFCの2つの項目が1です。オプション交渉に関する例は以下で与えた状態で輪にされます。 2 そして、輪を防ぐTELNET州のマシンに関する例。
1. Implementors of TELNET should read the examples of option
negotiation loops and beware that preventing such loops is a
nontrivial task.
1. TELNETの作成者は、オプションネゴシエーション・ループに関する例を読んで、そのような輪を防ぐのが、重要なタスクであるのに注意するべきです。
2. Section 7 of this RFC shows by example a working method
of avoiding loops. It prescribes the state information that
you must keep about each side of each option; it shows what
to do in each state when you receive WILL/WONT/DO/DONT from
the network, and when the user or process requests that an
option be enabled or disabled. An implementor who uses the
procedures given in that example need not worry about
compliance with this RFC or with a large chunk of RFC 854.
2. このRFCのセクション7は例で輪を避ける働く方法を示しています。 それはあなたがそれぞれのオプションのそれぞれの側の周りに保たなければならないという州の情報を定めます。 それは、あなたがウィル/WONT/を受けるとき、ネットワークで放送とユーザか過程が、いつオプションが可能にされるか、または無効にされるよう要求するかから各状態でするべきことが/にドントをするのを示します。 その例で与えられた手順を用いる作成者はこのRFCかRFC854の大きい塊への承諾に心配する必要はありません。
In short, all implementors should be familiar with TELNET loops, and some implementors may wish to use the pre-written example here in
要するに、すべての作成者が作成者がここのあらかじめ書かれた例を使用したがっているかもしれないTELNET輪、およびいくつかに詳しいはずです。
Bernstein [Page 1] RFC 1143 Q Method February 1990
バーンスタイン[1ページ]RFC1143Q方法1990年2月
writing a new TELNET implementation.
新しいTELNET実現を書きます。
NOTE: Reading This Document
以下に注意してください。 このドキュメントを読みます。
A TELNET implementation is not compliant with this RFC if it fails
to satisfy all rules marked MUST. It is compliant if it satisfies
all rules marked MUST. If it is compliant, it is unconditionally
compliant if it also satisfies all rules marked SHOULD and
conditionally compliant otherwise. Rules marked MAY are optional.
マークされた規則が満たさなければならないすべてを満たさないなら、TELNET実現はこのRFCと共に対応しません。マークされた規則が満たさなければならないすべてを満たすなら、言いなりになっています。それが言いなりになるなら、また、そうでなければ、SHOULDで条件付きに言いなりになるとマークされたすべての規則を満たすなら、無条件に言いなりになります。 著しい5月が任意であると裁決します。
Options are in almost all cases negotiated separately for each
side of the connection. The option on one side is separate from
the option on the other side. In this document, "the" option
referred to by a DONT/WONT or DO/WILL is really two options,
combined only for semantic convenience. Each sentence could be
split into two, one with the words before the slash and one with
the words after the slash.
オプションは別々にほとんどすべての場合接続の各側面と交渉されます。 半面におけるオプションは反対側におけるオプションから別々です。 このドキュメント、オプションがドント/WONTで言及するか、または/をする“the"では、ウィルは本当に意味便宜のためだけに結合された2つのオプションです。 各文を2、スラッシュの前の単語とスラッシュの後の単語がある1がある1つに分けることができました。
An implementor should be able to determine whether or not an
implementation complies with this RFC without reading any text
marked DISCUSSION. An implementor should be able to implement
option negotiation machinery compliant with both this RFC and RFC
854 using just the information in Section 7.
作成者は、実現が何かDISCUSSIONであるとマークされたテキストを読まないでこのRFCに従うかどうか決定できるべきです。 作成者は両方のこのRFCと共に言いなりになっているオプション交渉機械を実行できるべきです、そして、RFC854使用はまさしくセクション7の情報を実行できます。
2. RFC 854 Option Negotiation Requirements
2. RFC854オプション交渉要件
As specified by RFC 854: A TELNET implementation MUST obey a refusal to enable an option; i.e., if it receives a DONT/WONT in response to a WILL/DO, it MUST NOT enable the option.
RFC854によって指定されるように: TELNET実現はオプションを可能にすることへの拒否に従わなければなりません。 すなわち、/がするウィルに対応してドント/WONTを受けるなら、それはオプションを可能にしてはいけません。
DISCUSSION:
議論:
Where RFC 854 implies that the other side may reject a request to
enable an option, it means that you must accept such a rejection.
RFC854が、反対側がオプションを可能にするという要求を拒絶するかもしれないのを含意するところでは、それは、あなたがそのような拒絶を受け入れなければならないことを意味します。
It MUST therefore remember that it is negotiating a WILL/DO, and this negotiation state MUST be separate from the enabled state and from the disabled state. During the negotiation state, any effects of having the option enabled MUST NOT be used.
したがって、それは、/がするウィルを交渉しているのを覚えていなければなりません、そして、この交渉状態は可能にされた州と、そして、障害がある状態から別々であるに違いありません。 交渉状態の間、オプションを可能にさせるという少しの効果も使用してはいけません。
If it receives WONT/DONT and the option is enabled, it MUST respond DONT/WONT repectively and disable the option. It MUST NOT initiate a DO/WILL negotiation for an already enabled option or a DONT/WONT negotiation for a disabled option. It MUST NOT respond to receipt of such a negotiation. It MUST respond to receipt of a negotiation that does propose to change the status quo.
WONT/ドントを受けて、オプションが可能にされるなら、それは、ドント/WONT repectivelyを反応させて、オプションを無効にしなければなりません。 それはそうしてはいけません。aが/をする開始は既に可能にされたオプションのための交渉か障害があるオプションのためのドント/WONT交渉がそうするでしょう。 それはそのような交渉の領収書に応じてはいけません。 それは現状を変えるよう提案する交渉の領収書に応じなければなりません。
Bernstein [Page 2] RFC 1143 Q Method February 1990
バーンスタイン[2ページ]RFC1143Q方法1990年2月
DISCUSSION:
議論:
Many existing implementations respond to rejection by confirming
the rejection; i.e., if they send WILL and receive DONT, they send
WONT. This has been construed as acceptable behavior under a
certain (strained) interpretation of RFC 854. However, to allow
this possibility severely complicates later rules; there seems to
be no use for the wasted bandwidth and processing. Note that an
implementation compliant with this RFC will simply ignore the
extra WONT if the other side sends it.
多くの既存の実現が拒絶を確認することによって、拒絶に応じます。 すなわち、ウィルを送って、ドントを受けるなら、彼らはWONTを送ります。 これは是認される行動にRFC854のある(張りつめている)解釈で理解されました。 しかしながら、この可能性を許容するのは厳しく後の規則を複雑にします。 無駄な帯域幅と処理のための無駄はあるように思えます。 反対側がそれを送るとこのRFCに伴う対応することの実現が単に余分なWONTを無視することに注意してください。
The implementation MUST NOT automatically respond to the rejection of a request by submitting a new request. As a rule of thumb, new requests should be sent either at the beginning of a connection or in response to an external stimulus, i.e., input from the human user or from the process behind the server.
実現は、新しい要求を提出することによって、自動的に要求の拒絶に応じてはいけません。 原則として、親指では、接続の始めか外的刺激(すなわち、人間のユーザかサーバの後ろの過程からの入力)に対応して新しい要求を送るべきです。
A TELNET implementation MUST refuse (DONT/WONT) a request to enable an option for which it does not comply with the appropriate protocol specification.
TELNET実現はそれが適切なプロトコル仕様に従わないオプションを可能にするという要求を(ドント/WONT)に拒否しなければなりません。
DISCUSSION:
議論:
This is not stated as strongly in RFC 854. However, any other
action would be counterproductive. This rule appears in
Requirements for Internet Hosts [6, Section 3.2.2]; it appears
here for completeness.
これは強くRFC854のように述べられていません。 しかしながら、いかなる他の動作も反生産的でしょう。 この規則はRequirementsにインターネットHosts[6、セクション3.2.2]に関して現れます。 それは完全性に関してここに現れます。
3. Rule: Remember DONT/WONT requests
3. 以下を統治してください。 ドント/WONT要求を覚えていてください。
A TELNET implementation MUST remember starting a DONT/WONT negotiation.
TELNET実現は、ドント/WONT交渉を出発させたのを覚えていなければなりません。
DISCUSSION:
議論:
It is not clear from RFC 854 whether or not TELNET must remember
beginning a DONT/WONT negotiation. There seem to be no reasons to
remember starting a DONT/WONT negotiation: 1. The argument for
remembering a DO/WILL negotiation (viz., the state of negotiating
for enabling means different things for the data stream than the
state of having the option enabled) does not apply. 2. There is
no choice for the other side in responding to a DONT/WONT; the
option is going to end up disabled. 3. If we simply disable the
option immediately and forget negotiating, we will ignore the
WONT/DONT response since the option is disabled.
RFC854から、TELNETが、ドント/WONT交渉を始めたのを覚えていなければならないかどうかは、明確ではありません。 ドント/WONT交渉を出発させたと思い出す理由は全くあるように思えません: 1. aが/ウィル交渉をするのを(つまり、データのために手段の異なったものを可能にするために交渉する状態はオプションを可能にさせる状態より流れます)覚えているための議論は適用されません。 2. ドント/WONTに応じるのにおいて反対側のための選択が全くありません。 オプションは障害があった状態で終わるでしょう。 3. すぐに、単にオプションを無効にして、交渉したのを忘れるなら、オプションは障害があるので、私たちはWONT/ドントの応答を無視するつもりです。
Unfortunately, that conclusion is wrong. Consider the following
TELNET conversation between two parties, "us" and "him". (The
残念ながら、その結論は間違っています。 以下のTELNETが2回のパーティーと、「私たち」と「彼」との会話であると考えてください。 (
Bernstein [Page 3] RFC 1143 Q Method February 1990
バーンスタイン[3ページ]RFC1143Q方法1990年2月
reader of this RFC may want to sort the steps into chronological
order for a different view.)
このRFCの読者は異なった視点のためにステップを年代順に分類したがっているかもしれません。)
LOOP EXAMPLE 1
輪の例1
Both sides know that the option is on.
両側は、オプションが進行中であるのを知っています。
On his side:
1 He decides to disable. He sends DONT and disables the option.
2 He decides to reenable. He sends DO and remembers he is
negotiating.
5 He receives WONT and gives up on negotiation.
6 He decides to try once again to reenable. He sends DO and
remembers he is negotiating.
7 He receives WONT and gives up on negotiation.
For whatever reason, he decides to agree with future requests.
10 He receives WILL and agrees. He responds DO and enables the
option.
11 He receives WONT and sighs. He responds DONT and disables the
option.
(repeat 10 and then 11, forever)
彼の側で: 彼が無効にすると決める1。 彼は、ドントを送って、オプションを無効にします。 2 彼は、再可能にすると決めます。 彼は発信します。して、彼が交渉しているのを覚えています。 5 彼は、WONTを受け取って、交渉に見切りをつけます。 6 彼は、もう一度再可能にしようとすると決めます。 彼は発信します。して、彼が交渉しているのを覚えています。 7 彼は、WONTを受け取って、交渉に見切りをつけます。 いかなる理由でも、彼は、今後の要求に同意すると決めます。 10 彼は、ウィルを受けて、同意します。 彼は応じます。オプションをして、可能にします。 11 彼は、WONTを受け取って、ため息をつきます。 彼は、ドントを反応させて、オプションを無効にします。 (いつまでもの反復10と当時11)
On our side:
3 We receive DONT and sigh. We respond WONT and disable the
option.
4 We receive DO but disagree. We respond WONT.
8 We receive DO and decide to agree. We respond WILL and enable
the option.
9 We decide to disable. We send WONT and disable the option.
For whatever reason, we decide to agree with future requests.
12 We receive DO and agree. We send WILL and enable the option.
13 We receive DONT and sigh. We send WONT and disable the option.
(repeat 12 and then 13, forever)
私たちの側で: 3 私たちは、ドントを受けて、ため息をつきます。 私たちは、WONTを反応させて、オプションを無効にします。 私たちが受け取る4は、しますが、意見を異にします。 私たちはWONTを反応させます。 私たちが受け取る8は、して、同意すると決めます。 私たちは、ウィルを反応させて、オプションを可能にします。 私たちが無効にすると決める9。 私たちは、WONTを送って、オプションを無効にします。 いかなる理由でも、私たちは、今後の要求に同意すると決めます。 私たちが受け取る12は、して、同意します。 私たちは、ウィルを送って、オプションを可能にします。 13 私たちは、ドントを受けて、ため息をつきます。 私たちは、WONTを送って、オプションを無効にします。 (いつまでもの反復12と当時13)
Both sides have followed RFC 854; but we end in an option
negotiation loop, as DONT DO DO and then DO DONT forever travel
through the network one way, and WONT WONT followed by WILL WONT
forever travel through the network the other way. The behavior in
steps 1 and 9 is responsible for this loop. Hence this section's
rule. In Section 6 below is discussion of whether separate states
are needed for "negotiate for disable" and "negotiate for enable"
or whether a single "negotiate" state suffices.
両側はRFC854に続きました。 しかし、私たちはネットワークを通して一方通行の旅行が交渉がいつまでもドント・ドゥドゥとして輪にして、次にドントにするオプションに終わります、そして、いつまでもWILL WONTによって続かれたWONT WONTはネットワークを通ってもう片方の道に旅行します。 ステップ1と9における振舞いはこの輪に原因となります。 したがって、このセクションの規則。 」 a単一であるか否かに関係なく、「交渉してください」という状態を可能にしてください。別々の州が必要であるかどうかに関する議論が以下のセクション6に、ある、「交渉、無能にする、」、「交渉、十分です。
4. Rule: Prohibit new requests before completing old negotiation
4. 以下を統治してください。 古い交渉を終了する前に、新しい要求を禁止してください。
A TELNET implementation MUST NOT initiate a new WILL/WONT/DO/DONT request about an option that is under negotiation, i.e., for which it has already made such a request and not yet received a response.
TELNET実現は/がそれが既にそのような要求をして、まだ応答を受けていないすなわち交渉中であるオプションは/ドント要求をする新しいウィル/WONTを開始してはいけません。
Bernstein [Page 4] RFC 1143 Q Method February 1990
バーンスタイン[4ページ]RFC1143Q方法1990年2月
DISCUSSION:
議論:
It is unclear from RFC 854 whether or not a TELNET implementation
may allow new requests about an option that is currently under
negotiation; it certainly seems limiting to prohibit "option
typeahead". Unfortunately, consider the following:
RFC854から、TELNET実現が現在、交渉中であるオプションは新しい要求を許すかどうかが、不明瞭です。 確かに、「オプションtypeahead」を禁止するのは制限に思えます。 残念ながら、以下を考えてください:
LOOP EXAMPLE 2
輪の例2
Suppose an option is disabled, and we decide in quick
succession to enable it, disable it, and reenable it. We send
WILL WONT WILL and at the end remember that we are negotiating.
The other side agrees with DO DONT DO. We receive the first DO,
enable the option, and forget we have negotiated. Now DONT DO
are coming through the network and both sides have forgotten
they are negotiating; consequently we loop.
私たちは、オプションが障害があると仮定してください。そうすれば、それを可能にして、それを無能にして、それを再可能にすると間断なく決めます。 私たちは、WILL WONT WILLを送って、終わりに交渉しているのを覚えています。 側が同意するもう片方がします。ドントはします。 私たちは1番目を受け取ります。してください、そして、オプションを可能にしてください、そして、私たちが交渉したのを忘れてください。 ドントがするので、現れるのは、ネットワークです、そして、両側は交渉しているのを忘れました。 その結果、私たちは輪にします。
(All possible TELNET loops eventually degenerate into the same
form, where WILL WONT [or WONT WILL, or WILL WONT WILL WONT, etc.]
go through the network while both sides think negotiation is over;
the response is DO DONT and we loop forever. TELNET implementors
are encouraged to implement any option that can detect such a loop
and cut it off; e.g., a method of explicitly differentiating
requests from acknowledgments would be sufficient. No such option
exists as of February 1990.)
(TELNET輪が結局同じフォームに陥るのがすべて可能です、WILL WONT[または、WONT WILL、またはWILL WONT WILL WONTなど]が両側である間、ネットワークに直面しているところで交渉が終わっていると考えてください。 応答はドントをすることです、そして、私たちはいつまでも、輪にします。TELNET作成者がそのような輪を検出して、眠ることができるどんなオプションも実行するよう奨励されます。 例えば、承認と要求を明らかに区別する方法は十分でしょう。 どんなそのようなオプションも1990年2月現在、存在しません。)
This particular case is of considerable practical importance: most
combinations of existing user-server TELNET implementations do
enter an infinite loop when asked quickly a few times to enable
and then disable an option. This has taken on an even greater
importance with the advent of LINEMODE [4], because LINEMODE is
the first option that tends to generate such rapidly changing
requests in the normal course of communication. It is clear that
a new rule is needed.
この特定のケースはかなり実用的に重要です: 数回オプションを可能にして、次に、無効にするようにすばやく頼まれると、既存のユーザサーバTELNET実現のほとんどの組み合わせが無限ループに入ります。 これはLINEMODE[4]の到来に伴うさらに大きい重要性を呈しました、LINEMODEがコミュニケーションの常軌でそのような急速に変化している要求を発生させる傾向がある第1の選択であるので。 新しい規則が必要であるのは、明確です。
One might try to prevent the several-alternating-requests problem
by maintaining a more elaborate state than YES/NO/WANTwhatever,
e.g., a state that records all outstanding requests. Dave Borman
has proposed an apparently working scheme [2] that won't blow up
if both sides initiate several requests at once, and that seems to
prevent option negotiation loops; complete analysis of his
solution is somewhat difficult since it means that TELNET can no
longer be a finite-state automaton. He has implemented his
solution in the latest BSD telnet version [5]; as of May 1989, he
does not intend to publish it for others to use [3].
ものははい/いいえ、/WANTwhateverより入念な状態を維持することによって、いくつかの交互の要求問題を防ごうとするかもしれません、例えば、すべての傑出している要求を記録する州。 デーヴ・ボーマンは両側がすぐにいくつかの要求を開始するなら爆発しないで、オプションネゴシエーション・ループを防ぐように思える明らかに働く計画[2]を提案しました。 TELNETがもう有限状態オートマトンであるはずがないことを意味するので、彼の解決策の全分析はいくらか難しいです。 彼は最新のBSD telnetバージョン[5]のソリューションを実現しました。 1989年5月付けで、他のものが[3]を使用するように、彼はそれを発行しないつもりです。
Here the author decided to preserve TELNET's finite-state
property, for robustness and because the result can be easily
ここで、作者は、丈夫さ、結果が容易に決めることができたのでTELNETの有限州の所有地を保持すると決めました。
Bernstein [Page 5] RFC 1143 Q Method February 1990
バーンスタイン[5ページ]RFC1143Q方法1990年2月
proven to work. Hence the above rule.
働くと立証されます。 したがって、上の規則。
A more restrictive solution would be to buffer all data and do
absolutely nothing until the response comes back. There is no
apparent reason for this, though some existing TELNET
implementations do so anyway at the beginning of a connection,
when most options are negotiated.
より制限している解決策は、応答が戻るまで、すべてのデータをバッファリングして、絶対に何もしないだろうことです。 この見かけの理由は全くありません、いくつかの既存のTELNET実現が接続の始めにそうとにかくしますが。(その時、ほとんどのオプションが交渉されます)。
5. How to reallow the request queue
5. reallowに、要求はどう列を作るか。
DISCUSSION:
議論:
The above rule prevents queueing of more than one request through
the network. However, it is possible to queue new requests within
the TELNET implementation, so that "option typeahead" is
effectively restored.
上の規則はネットワークを通した1つ以上の要求の待ち行列を防ぎます。 しかしながら、TELNET実現の中に新しい要求を列に並ばせるのが可能であるので、事実上、「オプションtypeahead」は回復します。
An obvious possibility is to maintain a list of requests that have
been made but not yet sent, so that when one negotiation finishes,
the next can be started immediately. So while negotiating for a
WILL, TELNET could buffer the user's requests for WONT, then WILL
again, then WONT, then WILL, then WONT, as far as desired.
明白な可能性は作られていますが、まだ送られない要求のリストを維持することです、1つの交渉がすぐに終わるとき、次を始めることができるように。 それで、TELNETが再びウィルを交渉している間、WONT、当時のウィルを求めるユーザの要求をバッファリングできて、その時がWONTであり、その時がウィルであり、その時はWONTです、望まれていて。
This requires a dynamic and potentially unmanageable buffer.
However, the restrictions upon possible requests guarantee that
the list of requests must simply alternate between WONT and WILL.
It is wasteful to enable an option and then disable it, just to
enable it again; we might as well just enable it in the first
place. The few possible exceptions to this rule do not outweigh
the immense simplification afforded by remembering only the last
few entries on the queue.
これはダイナミックで潜在的に「非-処理しやす」なバッファを必要とします。 しかしながら、可能な要求の制限は、要求のリストが単にWONTとウィルの間を行き来しなければならないのを保証します。 オプションを可能にして、次に、それを無能にして、まさしく再びそれを可能にするのは無駄です。 私たちは第一に、ただそれを可能にするほうがよいです。 この規則へのわずかな可能な例外は最後のわずかなエントリーだけを待ち行列に覚えていることによって提供された莫大な簡素化を十二分に補いません。
To be more precise, during a WILL negotiation, the only sensible
queues are WONT and WONT WILL, and similarly during a WONT
negotiation. In the interest of simplicity, the Q method does not
allow the WONT WILL possibility.
ウィル交渉の間、より正確に、なるように、WONT交渉の間、唯一の分別がある待ち行列が、同様にWONTとWONT WILLです。 簡単さのために、Q方法はWONT WILLの可能性を許容しません。
We are now left with a queue consisting of either nothing or the
opposite of the current negotiation. When we receive a reply to
the negotiation, if the queue indicates that the option should be
changed, we send the opposite request immediately and empty the
queue. Note that this does not conflict with the RFC 854 rule
about automatic regeneration of requests, as these new requests
are simply the delayed effects of user or process commands.
私たちは今、待ち行列が現在の交渉の無か正反対のどちらかから成っていておかれます。 待ち行列が、オプションが変えられるべきであるのを示すなら回答を交渉に受け取るとき、私たちは、すぐに、反対の要求を送って、待ち行列を空にします。 これが要求の自動再生に関するRFC854規則と衝突しないことに注意してください、これらの新しい要求が単にユーザか過程コマンドの遅発効果であるので。
An implementation SHOULD support the queue, where support is defined by the rules following.
続いて、サポートが規則で定義されるところで実現SHOULDは待ち行列を支持します。
Bernstein [Page 6] RFC 1143 Q Method February 1990
バーンスタイン[6ページ]RFC1143Q方法1990年2月
If it does support the queue, and if an option is currently under negotiation, it MUST NOT handle a new request from the user or process to switch the state of that option by sending a new request through the network. Instead, it MUST remember internally that the new request was made.
待ち行列を支持して、オプションは現在交渉中であるなら、それが、ネットワークを通して新しい要求を送ることによってそのオプションの事情を切り換えるためにユーザか過程からの新しい要求を扱ってはいけません。 代わりに、それは、新しい要求をしたのを内面的に覚えていなければなりません。
If the user or process makes a second new request, for switching back again, while the original negotiation is still incomplete, the implementation SHOULD handle the request simply by forgetting the previous one. The third request SHOULD be treated like the first, etc. In any case, these further requests MUST NOT generate immediate requests through the network.
ユーザか過程が2番目の新しい要求をします、再び元に戻るために実現SHOULDは単に前のものを忘れることによって要求を扱って、オリジナルの交渉はまだ不完全にします。 3番目は、SHOULDが1番目などのように扱われるよう要求します。 どのような場合でも、これらのさらなる要求はネットワークを通した即座の要求を発生させてはいけません。
When the option negotiation completes, if the implementation is remembering a request internally, and that request is for the opposite state to the result of the completed negotiation, then the implementation MUST act as if that request had been made after the completion of the negotiation. It SHOULD thus immediately generate a new request through the network.
オプション交渉がまるで交渉の完成の後にその要求をしたかのように実現が活動させなければならないその時を実現が内面的に要求を覚えていて、完成した交渉の結果への反対の状態にその要求があるなら完成すると。 それ、その結果、SHOULDはすぐに、ネットワークを通した新しい要求を発生させます。
The implementation MAY provide a method by which support for the queue may be turned off and back on. In this case, it MUST default to having the support turned on. Furthermore, when support is turned off, if the implementation is remembering a new request for an outstanding negotiation, it SHOULD continue remembering and then deal with it at the close of the outstanding negotiation, as if support were still turned on through that point.
実現は待ち行列のどのサポートがオフにされるかもしれないか、そして、後部のそばでオンな方法を提供するかもしれません。 この場合、それはサポートをつけさせているのをデフォルトとしなければなりません。 その上、実現が傑出している交渉を求める新しい要求を覚えているなら、いつ、サポートがあるかは興味を失って、それはSHOULDです。覚えてい続けてください、そして、次に、傑出している交渉の閉鎖でそれに対処してください、まるでサポートがそのポイントを通してまだつけられているかのように。
DISCUSSION:
議論:
It is intended (and it is the author's belief) that this queue
system restores the full functionality of TELNET. Dave Borman has
provided some informal analysis of this issue [1]; the most
important possible problem of note is that certain options which
may require buffering could be slowed by the queue. The author
believes that network delays caused by buffering are independent
of the implementation method used, and that the Q Method does not
cause any problems; this is borne out by examples.
この待ち行列システムがTELNETの完全な機能性を回復することを意図します(それは作者の信念です)。 デーヴ・ボーマンはこの問題[1]の何らかの非公式の分析を提供しました。 注意の最も重要な起こりうる問題は待ち行列でバッファリングするのを必要とするかもしれないあるオプションを遅くすることができるだろうということです。 作者は、バッファリングすることによって引き起こされたネットワーク遅延が方法が使用した実現から独立していて、Q Methodがどんな問題も引き起こさないと信じています。 これは例によって支持されます。
6. Rule: Separate WANTNO and WANTYES
6. 以下を統治してください。 別々のWANTNOとWANTYES
Implementations SHOULD separate any states of negotiating WILL/DO from any states of negotiating WONT/DONT.
SHOULDの別々のいずれも述べるウィル/を交渉する実現はWONT/ドントを交渉するどんな州からもします。
DISCUSSION:
議論:
It is possible to maintain a working TELNET implementation if the
NO/YES/WANTNO/WANTYES states are simplified to NO/YES/WANT.
いいえ/はい、/WANTNO/WANTYES州がいいえ/はい、/WANTに簡素化されるなら、働くTELNET実現を維持するのは可能です。
Bernstein [Page 7] RFC 1143 Q Method February 1990
バーンスタイン[7ページ]RFC1143Q方法1990年2月
However, in a hostile environment this is a bad idea, as it means
that handling a DO/WILL response to a WONT/DONT cannot be done
correctly. It does not greatly simplify code; and the simplicity
gained is lost in the extra complexity needed to maintain the
queue.
しかしながら、敵対的環境では、これが悪い考えである、aを扱うと/がすることを意味するとき、正しくWONT/ドントへのウィル応答ができません。 それはコードを大いに簡素化しません。 そして、獲得された簡単さは待ち行列を維持するのに必要である余分な複雑さで失われています。
7. Example of Correct Implementation
7. 正しい実現に関する例
To ease the task of writing TELNET implementations, the author presents here a precise example of the response that a compliant TELNET implementation could give in each possible situation. All TELNET implementations compliant with this RFC SHOULD follow the procedures shown here.
TELNETに実現を書くタスクを緩和するために、作者はここに対応するTELNET実現がそれぞれの可能な状況で与えることができた応答の正確な例を提示します。 このRFC SHOULDに伴う対応することのすべてのTELNET実現がここに示された手順に従います。
EXAMPLE STATE MACHINE FOR THE Q METHOD OF IMPLEMENTING TELNET OPTION NEGOTIATION
telnetオプション交渉を実行するQ方法のための例の州のマシン
There are two sides, we (us) and he (him). We keep four
variables:
2つの側があって、私たちが(私たち)であり、彼は(彼)です。 私たちは4つの変数を保ちます:
us: state of option on our side (NO/WANTNO/WANTYES/YES)
usq: a queue bit (EMPTY/OPPOSITE) if us is WANTNO or WANTYES
him: state of option on his side
himq: a queue bit if him is WANTNO or WANTYES
私たち: 私たちのサイド(いいえ/WANTNO/WANTYES/はい)usqにおけるオプションの州: 私たちであるなら、待ち行列ビット(EMPTY/OPPOSITE)はWANTNOであるかWANTYESは彼です: 彼のサイドhimqにおけるオプションの州: 彼であるなら、待ち行列ビットは、WANTNOかWANTYESです。
An option is enabled if and only if its state is YES. Note that
us/usq and him/himq could be combined into two six-choice states.
オプションが可能にされる、状態である場合にだけ、はいはそうです。 それに注意してください、私たち、2に6選択する状態で結合されていて、/himqがそうすることができた/usqと彼、州。
"Error" below means that producing diagnostic information may be a
good idea, though it isn't required.
それは必要ではありませんが、以下の「誤り」は、診断情報を作り出すのが、名案であるかもしれないことを意味します。
Upon receipt of WILL, we choose based upon him and himq:
NO If we agree that he should enable, him=YES, send
DO; otherwise, send DONT.
YES Ignore.
WANTNO EMPTY Error: DONT answered by WILL. him=NO.
OPPOSITE Error: DONT answered by WILL. him=YES*,
himq=EMPTY.
WANTYES EMPTY him=YES.
OPPOSITE him=WANTNO, himq=EMPTY, send DONT.
ウィルを受け取り次第、私たちは彼とhimqに基づいた状態で選びます: 私たちは、彼が可能にするべきであり、=はいに同意して、発信します。Ifがない、してください。 さもなければ、ドントを送ってください。 はいは無視します。 WANTNOは誤りを空にします: ドントはウィル彼=NO.で答えました。 反対の誤り: himq=EMPTY、ドントはウィル彼=はい*で答えました。 WANTYESは彼=はいを空にします。 彼=WANTNO(himq=EMPTY)がドントに送るOPPOSITE。
* This behavior is debatable; DONT will never be answered by WILL
over a reliable connection between TELNETs compliant with this
RFC, so this was chosen (1) not to generate further messages,
because if we know we're dealing with a noncompliant TELNET we
shouldn't trust it to be sensible; (2) to empty the queue
sensibly.
* この振舞いは論争の余地があります。 (1)がさらなるメッセージは発生させないようにこれに選ばれて、不従順なTELNETに対処しているのを知っているなら私たちが、それが感じていると信じるべきでないので、ドントはこのRFCと共に言いなりになっているTELNETsの間の頼もしい接続の上でウィルによって決して答えられないでしょう。 (2) 分別よく待ち行列を空にするために。
Bernstein [Page 8] RFC 1143 Q Method February 1990
バーンスタイン[8ページ]RFC1143Q方法1990年2月
Upon receipt of WONT, we choose based upon him and himq:
NO Ignore.
YES him=NO, send DONT.
WANTNO EMPTY him=NO.
OPPOSITE him=WANTYES, himq=NONE, send DO.
WANTYES EMPTY him=NO.*
OPPOSITE him=NO, himq=NONE.**
WONTを受け取り次第、私たちは彼とhimqに基づいた状態で選びます: いいえは無視します。 はい、彼、= いいえ、ドントを送ってください。 WANTNOは彼=NO.を空にします。 彼=WANTYES(himq=NONE)が送るOPPOSITEはします。 WANTYESはhimq=NONE彼=いいえ、**の反対側で彼=NO.*を空にします。
* Here is the only spot a length-two queue could be useful; after
a WILL negotiation was refused, a queue of WONT WILL would mean
to request the option again. This seems of too little utility
and too much potential waste; there is little chance that the
other side will change its mind immediately.
* ここに、唯一のスポットがあります。長さ-2待ち行列は役に立つかもしれません。 ウィル交渉が拒否された後に、WONT WILLの待ち行列は、再びオプションを要求することを意味するでしょう。 これはあまりに少ないユーティリティとあまりに多くの潜在的浪費について見えます。 反対側がすぐに気が変わるという見込みがほとんどありません。
** Here we don't have to generate another request because we've
been "refused into" the correct state anyway.
** ここで、私たちは、いたので、別の要求を発生させる必要はありません。とにかく正しい状態に「拒否されます」。
If we decide to ask him to enable:
NO him=WANTYES, send DO.
YES Error: Already enabled.
WANTNO EMPTY If we are queueing requests, himq=OPPOSITE;
otherwise, Error: Cannot initiate new request
in the middle of negotiation.
OPPOSITE Error: Already queued an enable request.
WANTYES EMPTY Error: Already negotiating for enable.
OPPOSITE himq=EMPTY.
私たちであるなら、以下を可能にするように彼に頼むと決めてください。 いいえ、彼=WANTYES、発信してください。してください。 はい誤り: 既に可能にされます。 WANTNO EMPTY If、himq=OPPOSITE、私たちは待ち行列要求です。 そうでなければ、Error、: 交渉の途中で新しい要求を開始できません。 反対の誤り: 既に列を作る、要求を可能にしてください。 WANTYESは誤りを空にします: 既に交渉する、可能にします。 正反対himq=は空になります。
If we decide to ask him to disable:
NO Error: Already disabled.
YES him=WANTNO, send DONT.
WANTNO EMPTY Error: Already negotiating for disable.
OPPOSITE himq=EMPTY.
WANTYES EMPTY If we are queueing requests, himq=OPPOSITE;
otherwise, Error: Cannot initiate new request
in the middle of negotiation.
OPPOSITE Error: Already queued a disable request.
私たちであるなら、以下を無能にするように彼に頼むと決めてください。 誤りがありません: 既に障害があります。 はい彼=WANTNO、ドントを送ってください。 WANTNOは誤りを空にします: 既に交渉する、無能にします。 正反対himq=は空になります。 WANTYES EMPTY If、himq=OPPOSITE、私たちは待ち行列要求です。 そうでなければ、Error、: 交渉の途中で新しい要求を開始できません。 反対の誤り: 既に列に並ばせられて、aは要求を無効にします。
We handle the option on our side by the same procedures, with DO-
WILL, DONT-WONT, him-us, himq-usq swapped.
私たちが側で同じ手順でオプションを扱う、ウィル、ドント-WONTをしてください、彼、-、私たち、himq-usqはスワップされました。
8. References
8. 参照
[1] Borman, D., private communication, April 1989.
[1] ボーマン、D.、私信、1989年4月。
[2] Borman, D., private communication, May 1989.
[2] ボーマン、D.、私信、1989年5月。
[3] Borman, D., private communication, May 1989.
[3] ボーマン、D.、私信、1989年5月。
Bernstein [Page 9] RFC 1143 Q Method February 1990
バーンスタイン[9ページ]RFC1143Q方法1990年2月
[4] Borman, D., Editor, "Telnet Linemode Option", RFC 1116, Cray
Research, August 1989.
[4] ボーマン、D.、エディタ、「telnet Linemodeオプション」、RFC1116、クレイリサーチ、1989年8月。
[5] Borman, D., BSD Telnet Source, November 1989.
[5] ボーマン、D.、BSD telnetソース、1989年11月。
[6] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", RFC 1123, USC/Information Sciences
Institute, October 1989.
[6] ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、RFC1123、科学が設けるUSC/情報、10月1989日
[7] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC
854, USC/Information Sciences Institute, May 1983.
[7] RFC854、科学が設けるUSC/情報がそうするポステル、J.とJ.レイノルズ、「telnetプロトコル仕様」1983。
9. Acknowledgments
9. 承認
Thanks to Dave Borman, dab@opus.cray.com, for his helpful comments.
彼の役に立つコメントをデーヴ・ボーマン、 dab@opus.cray.com をありがとうございます。
Author's Address
作者のアドレス
Daniel J. Bernstein 5 Brewster Lane Bellport, NY 11713
醸造者レーンBellport、ダニエル・J.バーンスタイン5・ニューヨーク 11713
Phone: 516-286-1339
以下に電話をしてください。 516-286-1339
Email: brnstnd@acf10.nyu.edu
メール: brnstnd@acf10.nyu.edu
Bernstein [Page 10]
バーンスタイン[10ページ]
一覧
スポンサーリンク
