RFC513 日本語訳

Network Working Group                                     Wayne Hathaway
RFC # 513                                                        AMES-67
NIC # 16444                                                  30 May 1973

ワーキンググループウェインハザウェイRFC#513エームズ-67NIC#16444 1973年5月30日をネットワークでつないでください。

               COMMENTS ON THE NEW TELNET SPECIFICATIONS

新しいtelnet仕様のコメント

I would like to make the following comments on the proposed new TELNET
Protocol Specification (NIC # 15372) and TELNET Option Specification
(NIC 15373).  In general I feel the new TELNET protocol is far superior
to the previous version.  There are, however, a few items of substance
which I feel should be changed, as well as some recommended editorial
changes.

提案された新しいTELNETプロトコルの以下のコメントをSpecification(NIC#15372)とTELNET Option Specification(NIC15373)にしたいと思います。 一般に、私は、新しいTELNETプロトコルが旧バージョンよりはるかに優れていると感じます。 しかしながら、私が変えられるべきであると感じる物質の数項目があります、いくつかのお勧めの編集の変化と同様に。

I feel the most significant error concerns the "Note on 'Sub-
negotiations'" section of the Option Specification (page 2).  The
problem stems from the statements "Each party is presumed to be able to
parse the parameter(s)" and "Finally, if parameters in an option
'subnegotiation' include a byte with a value of 255, it is not necessary
to double this byte in accordance with the general TELNET IAC."  These
two statements make the completely unwarranted but all too prevalent
assumption that there is only one "Telnet Interpreter" and that all
TELNET functions are carried out by it.  In particular, problems arise
when a TELNET "synch" is received, and the receiving NCP is required to
scan the input looking for "interesting" things.  If the subnegotiation
was in fact being carried out by a user process (and not the "TELNET
interpreter") then that user process is probably the only one that knows
how to interpret the SB parameters; the NCP itself would have no way of
parsing them.  As a solution to this problem I propose that all
subnegotiation parameters be delimited at the end (perhaps with the same
TELNET command SB) and that they be required to obey all TELNET rules,
including doubling of IAC's.  It may be argued that the user process
interpreting the SB itself should do the scanning for "interesting"
things, but I do not feel that this burden should be place on all user
processes.

私は、最も重要な誤りはOption Specification(2ページ)の「'サブ交渉'に関する注」セクションに関係があると感じます。 問題は「あえて各当事者をパラメタを分析できる」声明によります、そして、「'副交渉'というオプションにおけるパラメタが255の値に従った1バイトを含むなら、最終的に、一般的なTELNET IACによると、このバイトを倍にするのは必要ではありません」。 これらの2つの声明が1「telnetインタプリタ」だけ、があって、すべてのTELNET機能が行われるという完全に保証のない、しかし、一般的過ぎる仮定をします。 TELNET「同時性」が受け取られていて、受信NCPが「おもしろい」ものを探しながら入力をスキャンするのに必要であるときに、特に、問題は起こります。 副交渉がユーザ・プロセス(そして、「TELNETインタプリタ」でない)によって事実上ユーザ・プロセスがたぶん唯一無二であるのについてその時、行われていたなら、それはSBパラメタを解釈する方法を知っています。 NCP自体には、それらを分析する方法が全くないでしょう。 この問題の解決として、私は、すべての副交渉パラメタが終わり(恐らく同じTELNETコマンドSBと)に区切られて、それらがすべてのTELNET規則に従わなければならないよう提案します、IACのものを倍にするのを含んでいて。 ユーザがSB自身が「おもしろい」もののためのスキャンをするはずである解釈を処理すると主張されるかもしれませんが、私は、この負担がすべてのユーザ・プロセスの場所であるべきであると感じません。

The solution to the above problem is in fact fairly simple to define and
implement.  The general problem, however, is one of not taking proper
cognizance of what I called "user processes" (processes which are not
network standards, but which are simply programs attempting to do work
using the network).  I feel we must be more careful to shape all future
network standards with these very real user processes in mind if in fact
the network will ever be as useful as is possible.

事実上、上の問題の解決は定義して、実行するのはかなり簡単です。 しかしながら、一般的問題は私が「ユーザ・プロセス」(ネットワーク規格ではありませんが、単にネットワークを使用することで働くのを試みるプログラムである過程)と呼んだものに関する適切な認識を取らないものです。 私は、事実上、ネットワークができるだけ役に立つなら私たちがこれらの非常に本当のユーザ・プロセスですべての将来のネットワーク規格を念頭に形成するのにより慎重であるに違いないと感じます。

The second item I object to is the incredibly loose definition of
"interesting" things (an aside: words which are so imprecise as to
require quotation marks should never appear in protocol specifications).
The specifications do define some of these "interesting" things (eg,

私が反対する第2項目は「おもしろい」ものの信じられないほどゆるい定義(余談: 引用符を必要とするほど不正確な単語はプロトコル仕様に決して現れるべきでない)です。 仕様がこれらの「おもしろい」ことのいくつかを定義する、(eg

Hathaway                                                        [Page 1]

RFC 513        COMMENTS ON THE NEW TELNET SPECIFICATIONS        May 1973

ハザウェイ[1ページ]RFC513は1973年5月に新しいtelnet仕様を批評します。

most TELNET commands) but they then include "and perhaps other
characters or character strings as well".  To eliminate the difficulty
of implementing an undefined set of "interesting" things, I would
propose that the set of "interesting" things, contain only the DM
command itself.  The TELNET "synch" would thus be defined as "discard
all input up to and including the next DM command."  This change should
cause no problems with user-generated "interesting" things if they are
sent after the "synch" (as specified in the proposed new File Transfer
Protocol Specifications).  System-generated signals (such as option
requests) could be discarded, however, so some additional discussion is
in order.  If the recommendation that requests not be sent except when
something changes is followed, the spontaneous generation of
"interesting" things by TELNET itself (whatever that implies) would seem
to be rare, especially at the same time that users are generating
"synch's".  A more positive solution could be had by defining a "synch
response" (SR) TELNET command.  The SR command would be sent when the
INS and DM had both been processed (ie, when the "synch" had been
completely received).  If a process should ever receive an SR when it
has an option request outstanding, the request has been discarded and
must be repeated.  User processes which carry on option negotiations
would be the generators of any "synch's" so they can handle discarded
option requests as desired.  Note that this assumes that the TELNET
process itself will never generate a spontaneous "synch"; comments are
solicited on this.  Another possible solution would be to define a
"TIMING-MARK" TELNET command (see "TELNET Timing Mark Option", NIC #
16238), which would be sent immediately following the DM of a "synch".
The response to the TIMING-MARK (also to be defined) would mean the same
as the proposed SR command.

次にTELNETコマンド) それらだけが含む大部分と「恐らく他のキャラクタかまた、文字列。」 未定義のセットの「おもしろい」ものを実行するという困難を排除するために、私がそれを提案するだろう、セット、「おもしろい」ものでは、DMコマンド自体だけを含んでください。 その結果、TELNET「同時性」は「次のDMコマンドを含めてすべて入力された破棄」と定義されるでしょう。 「同時性」の後にそれらを送るなら(提案された新しいFile TransferプロトコルSpecificationsで指定されるように)、この変化はユーザが発生している「おもしろい」ものに関する問題を全く引き起こすはずがありません。 システム生成の信号(オプション要求などの)を捨てることができたので、しかしながら、何らかの追加議論が整然としています。 何かが変化する時以外に、要求が送られないという推薦が続かれているなら、「興味を持っていて、」 TELNET(それが含意することなら何でも)自身によるものはまれであるように思えるでしょう、特にユーザが「を同時性発生させているのと同時に」偶然発生です。 「同時性応答」(SR)を定義することによって、より積極的な解決策を持つことができるでしょう。 TELNETは命令します。 ともにINSとDMを処理したとき(「同時性」が完全に受け取られたie)、SRコマンドを送るでしょう。 オプションがそれから傑出していて、要求を捨てられて、繰り返さなければならないよう要求するとき、過程がSRを受けるなら。 」 どんな「の同時性ジェネレータもそれらが扱うことができるそうであったならオプション交渉のときに運ばれるユーザ・プロセスは望まれているようにオプション要求を捨てました。 これが、TELNETの過程自体が自然発生的な「同時性」を決して発生させないと仮定することに注意してください。 コメントはこれで請求されます。 別の可能な解決策は「タイミング・マーク」telnetコマンド(「telnetタイミング・マークオプション」を見てください、NIC#16238)を定義するだろうことです。(それは、すぐに、「同時性」のDMを続かされているでしょう)。 提案されたSRが命令するようにTIMING-マーク(また、定義される)への応答は同じであることを意味するでしょう。

The final non-editorial comment concerns the need for some means of
specifying horizontal tab positions and use.  This is quite a nuisance
when dealing with systems which normally handle tabs for local
terminals.  Perhaps this issue can be best handled with an appropriate
option; comments are solicited.

最終的な非社説コメントは水平タブの位置と使用を指定するいくつかの手段の必要性に関係があります。 通常、ローカル・ターミナルのためにタブを扱うシステムに対処するとき、これはかなりの迷惑です。 恐らく、適切なオプションでこの問題を扱うことができるのは最も良いです。 コメントは請求されます。

The only editorial comments are on the TELNET Protocol document, which I
reference below by page number.

TELNETプロトコルドキュメントの上に唯一の編集のコメントがあります。私は以下でページ番号でドキュメントに参照をつけます。

On page 8 the parenthetical comment "(i.e., when a process at one end of
a TELNET connection is 'blocked on input')" should either be removed or
rewritten to avoid the (to me) incomprehensible phrase "blocked on
input."  If additional discussion is felt to be necessary, I would
propose "i.e., when a process at one end of a TELNET connection cannot
proceed without additional input)."  If examples are felt necessary, I
would propose "(e.g., in the state characterized by the Multics term
'blocked on input')."  The parallel could also be drawn between the GA
and the concept of a "read command" being issued to request more input.

8ページでは、「入力のときに妨げられた」(私への)不可解な句を避けるために、「(すなわち、TELNET接続の片端の過程が'入力のときに、妨げられる'とき)」という挿入句のコメントを取り除くべきであるか、または書き直すべきです。 追加議論が必要であると感じられるなら、私が提案するだろう、「すなわち、TELNET接続の片端の過程が追加入力なしで続くことができない、)、」 例が必要であると感じられるなら、私は提案するでしょう「(例えば'入力に妨げられる'というMultics用語によって特徴付けられた状態で)」という。 また、より多くの入力を要求するために発行されながら、「読みコマンド」のジョージアと概念の間に平行線を描くことができました。

Hathaway                                                        [Page 2]

RFC 513        COMMENTS ON THE NEW TELNET SPECIFICATIONS        May 1973

ハザウェイ[2ページ]RFC513は1973年5月に新しいtelnet仕様を批評します。

On page 10 I feel that there needs to be some more discussion of the
Abort Output (AO) command, particularly the statement that it "allows a
process... to run to completion... but without sending the output to the
user's terminal."  The problem is that nothing is said about when output
is to resume (presumably at the next system prompt character).  I
realized that the AO is meant only to invoke this function on systems
which already provide it, but it would seem to be more useful if more
fully specified.

10ページでは、私は、Abort Output(AO)コマンド(それが「過程が…完成にもかかわらず、…送付のない出力にユーザの端末に駆けつけるのを許容する」という特に声明)のそれ以上の議論があるのが必要であると感じます。 問題は何も再開する(おそらく次のシステムプロンプト文字で)出力がことである時に関して言われていないということです。 私は、AOが単に既にそれを提供するシステムの上のこの機能を呼び出すことになっているとわかりましたが、より完全に指定されるなら、それは、より役に立つように思えるでしょう。

On page 11 I do not understand what the example "(e.g., an over-strike)"
is trying to say.  Speaking of an overstrike on output would imply to me
that both characters are to be printed in the same print position,
reducing the EC to a backspace.  Some more discussion should also be
added as to what EC (and EL) mean on output (if anything).

11ページでは、私は、「(例えば、重ね打ち)」という例が何を言おうとしているかを理解していません。 出力のときに重ね打ちについて話すのは、バックスペースキーを押して印字位置を一字分戻るようにaへのECを減少させて、同じ印刷位置に印刷されるために両方のキャラクタがいる私に含意するでしょう。 また、それ以上の議論が(どちらかと言えば)の出力のときにどんなEC(そして、EL)平均に関して加えられるべきであるか。

On page 11 I would like to see the word "promptly" (which is in
quotation marks) either eliminated or defined, as per my earlier aside
comment.  The phrase "if necessary" in the last line also seems
unnecessary.

11ページでは、「即座に」という言葉(引用符にはある)が排除されるか、または定義されるのを見たいと思います、私の以前の余談コメントに従って。 また、「必要なら」最終ラインの句は不要に見えます。

On page 12 my proposed redefinition of "interesting" signals would
remove the middle paragraph entirely and would modify the third
paragraph substantially.  The line "discard all characters which would
have had an effect on the NVT printer" should be changed, however, as it
seems BELL's should also be discarded.

12ページでは、私の「おもしろい」信号の提案された再定義は、展開部を完全に取り除いて、実質的に第3パラグラフを変更するでしょう。 線は「NVTプリンタに影響を与えたすべてのキャラクタを捨てます」。しかしながら、また、ベルも捨てられるべきであったように思えるとき、変えるべきです。

On page 14 I see no reason why the sequence "CR NUL" is required to
generate a "CR" only, and also object to "and the CR character must be
avoided in other contexts."  Either some supporting discussion should be
added or this restriction should be removed.

14ページでは、私は系列"CR NUL"が必要である"CR"だけ、を発生させて、また物を発生させる理由が全くわかりません、そして、「他の文脈でCRキャラクタを避けなければなりません」。 何らかのサポート議論を加えるべきですか、またはこの制限を取り除くべきです。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.             9/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社9/99]

Hathaway                                                        [Page 3]

ハザウェイ[3ページ]