RFC719 日本語訳
0719 Discussion on RCTE. J. Postel. July 1976. (Format: TXT=4708 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group Jon Postel (SRI-ARC) Request for Comments: 719 Jul 76 NIC #36138
コメントを求めるワーキンググループのジョン・ポステル(様アーク)Requestをネットワークでつないでください: 719 7月76日のNIC#36138
Discussion on RCTE
RCTEについての議論
The following is the significant portion of a dialog on RCTE that has followed the publication of RFC 718.
↓これはRFC718の公表に従ったRCTEの上の対話の重要な部分です。
15-Jul-76 Nancy Mimno (BBN-NET)
1976年7月15日ナンシーMimno(BBN-ネット)
Jon, I've read RFC718 and have got some comments, in particular with respect to the "third problem" or clearing the input buffer part.
ジョン、私は、RFC718を読んで、いくつかのコメントを持っています、特に「3番目の問題」か入力バッファ部分を儲けることに関して。
1) I believe the stated implementation is backwards: in the normal case of the RCTE mode negotiation, the server sends "WILL RCTE" and the user sends ,"DO RCTE"; the reverse case is thus the server sending "DO RCTE" and the user "WILL RCTE" Also, it is probably wise to say explicitly that the server's sending "DO RCTE" requires the user process to respond "WILL (or WON'T) RCTE" and that this response is the synchronizing mark.
1) 私は、述べられた実現が後方にそうであると信じています: RCTEモード交渉、サーバに関するケースが「ウィルRCTE」を送って、ユーザが送る標準では、「RCTEをしてください」。 その結果、逆のケースは「ウィル(or WON'T)」を反応させるためにサーバが「RCTEをしてください」を送るのが必要とする「RCTEをしてください」とまた、明らかに言うのもたぶん賢明であるユーザ「ウィルRCTE」にユーザ・プロセスを送るサーバです。 「RCTE、」 この応答は連動マークです。
2) The problem is a real one and I think the RCTE protocol would be better with a "clear input, reset counters" function. The question is Ill now to do it. In talking with Rav yesterday, I learned that he had this in mind as a general function, not restricted to RCTE; in fact, TENEX sends the "reverse RCTE" option for "clear your input buffer" whether or not the connection is in RCTE mode. In this case, the statement about "cannot be confused with the normal use of the RCTE option" will not always be true. I think we both agreed that the current solution should just be an interim one.
2) 問題は本物です、そして、私はRCTEプロトコルが「明確な入力、リセットカウンタ」機能によって、より良いと思います。 質問は現在、それをするIllです。 昨日Ravと話す際に、私は、彼がRCTEに制限されるのではなく、一般的な機能としてこれを考えていたことを学びました。 事実上、接続がRCTEモードであるか否かに関係なく、TENEXは「入力バッファをきれいにしてください」のための「逆のRCTE」オプションを送ります。 この場合、「RCTEオプションの通常の使用には、混乱できないこと」に関する声明はいつも正しくなるというわけではないでしょう。 私は、私たち二人が、現在の解決策がまさしく当座のものであるのに同意したと思います。
3) I suggest a different way of performing this function, using the synch-datamark sequence. First, the RCTE option would have to explicitly require that this function reset the counters and cause a "clear your input buffer (of data)", all synchronized with the datamark of course. This is pretty much what it is now except for the reset counters; receiving Synch-data mark when in RCTE probably needed defining anyhow. Because RCTE won't work unless both sides agree, the "clear input and reset counters" meaning for synch-data mark would have to be a mandatory part of the RCTE option. Second, since the Synch-data mark is a "one-way" function, there needs to be a way for one side of the connection to tell the other side to "send me a Synch-data mark". The New Telnet protocol spec implied that Abort Output could be used for that purpose; if hot, then perhaps a new function could be defined. Again, the RCTE option should make some explicit statement requiring (or very strongLy recommending) this interpretation of AO. For non-RCTE mode, it's a nice idea but probably not required. Ray has tentatively agreed- thinks it could work on Tenex (server side). I would like your comments and Doug Dodds' (Tenex user RCTE). I don't know of any other existing RCTE implementations that would have to change. I also don't know what it
3) 私は同時性-datamark系列を使用して、この機能を実行する異なった方法を勧めます。 まず最初に、RCTEオプションは、この機能がカウンタをリセットして、もちろんdatamarkにすべて連動している「入力バッファ(データの)をきれいにしてください」を引き起こすのを明らかに必要としなければならないでしょう。 これは現在、リセットカウンタ以外のほとんどそれが何であるかということです。 RCTEにあるときSynch-データ・マークを受けるのは、たぶんとにかく定義する必要がありました。 両側が同意しないとRCTEが働かないので、同時性データ・マークへの「明確な入力とリセットカウンタ」意味はRCTEオプションの義務的な部分でなければならないでしょう。 2番目に、接続の半面が「Synch-データ・マークを私に送ります」ように反対側に言う方法が、Synch-データ・マークが「片道」の機能であるので、あるのが必要です。 New Telnetプロトコル仕様は、そのためにAbort Outputを使用できるのを含意しました。 熱いなら、恐らく、新しい機能は定義されるかもしれません。 一方、RCTEオプションはAOのこの解釈を必要とする(または、まさしくそのstrongLy推薦)何らかのはっきりした説明を作るべきです。 非RCTEモードにおいて、それは、良い考えにもかかわらず、たぶん必要ではありません。 レイは、それがTenex(サーバ側)に働くことができたと思うのに試験的に同意しました。 私は、あなたのコメントとダグ・ドッズ(TenexユーザRCTE)が欲しいと思います。 私は変化しなければならないいかなる他の既存のRCTE実現も知りません。 また、私がなにかを知らないか、それ
-1-
-1-
takes to extend official protocols these days, but maybe it's easier to do that than define a new option (ie reverse RCTE).
しかし、最近公式のプロトコルを広げる撮影、多分それは新しいオプション(ieの逆のRCTE)を定義するよりそれをしやすいです。
Regards, Nancy
敬具、ナンシー
15-Jul-76 Doug Dodds (BBN-RCC)
1976年7月15日のダグ・ドッズ(BBN-RCC)
Nancy,
ナンシー
Your suggestion for the RCTE-clear function being performed by the Au command (when RCTE is on) is a good one. I see no problem with it from the side of the Tenex User Telnet (NTELNET). At present NTELNET is ignoring AO (and some other commands) entirely; this is a good opportunity to implement it in general.
Auコマンド(RCTEがオンであるときに)で実行されるRCTE明確な機能のためのあなたの提案は良いものです。 私はTenex User Telnet(NTELNET)の側面からそれに関する問題を全く認めません。 現在のところ、NTELNETはAO(そして、ある他のコマンド)を完全に無視しています。 これは一般に、それを実行する好機です。
Doug
ダグ
21-Jul-76 Jon Postel (SRI-ARC)
1976年7月21日のジョン・ポステル(様アーク)
I met with Ray Tomlinson for a few minutes to discuss the RCTE-clear function and other RCTE features. We agreed that Nancy's suggestion for using the AO command for the clear function made sense. We also determined that the RCTE document should say something about the state some other options should be in when using RCTE. For example we believe that GO-AHEAD must be suppressed while RCTE is in use, that when one quits RCTE the ECHO mode must be restored to what it was at the time of entering RCTE,, and that BINARY and RCTE do not make sense as a combination because every byte would have to be assumed to be a break character. We also determined that it is unworkable to use RCTE and no break characters since there is no way to get out of that state.
私は、RCTE明確な機能と他のRCTEの特徴について議論するために数分間レイ・トムリンスンに会いました。 私たちは、明確な機能にAOコマンドを使用するためのナンシーの提案が理解できたのに同意しました。 また、私たちは、RCTEドキュメントがRCTEを使用するときある他のオプションがあるべきである状態に関して何かを書くはずであると決心していました。 例えば、私たちがRCTEが使用中である間GO-AHEADを抑圧しなければならなくて、1つがRCTEをやめるときRCTEに入る時点でそれが何であったかにECHOモードを回復しなければならないと信じている、あらゆるバイトが区切り文字であると思われなければならないでしょう、そして、したがって、BINARYとRCTEは組み合わせとして理解できません。 また、その状態を出る方法が全くないので、私たちは、RCTEを使用しますが、どんな区切り文字も使用しないのが「非-実行可能」であると決心していました。
22-Jul-76 Jon Postel (SRI-ARC)
1976年7月22日のジョン・ポステル(様アーク)
As a result of the above discussion I will prepare a revised RCTE specification document. A draft will be distributed to interested parties for comments and the final document will be published as an RFC.
上の議論の結果、私は改訂されたRCTE仕様ドキュメントを準備するつもりです。 草稿はコメントのために利害関係者に広げられるでしょう、そして、最終合意文書はRFCとして発行されるでしょう。
-2-
-2-
一覧
スポンサーリンク