RFC529 日本語訳

Network Working Group                                        A. McKenzie
Request for Comments: 529                                      B. Thomas
NIC: 17165                                                  R. Tomlinson
References: RFCs 454, 513,                                     BBN-TENEX
            NIC # 15372                                        K. Pogran
                                                             MIT-MULTICS
                                                            29 June 1973

コメントを求めるワーキンググループA.マッケンジー要求をネットワークでつないでください: 529 B.トーマスNIC: 17165 R.トムリンスンの参照: RFCs454、513、BBN-TENEX NIC#15372K.Pogran MIT-MULTICS1973年6月29日

                   A Note on Protocol Synch Sequences

プロトコル同時性系列に関する注

   This note is motivated by Wayne Hathaway's RFC 513 which comments on
   the interpretation of the TELNET SYNCH sequence (INS/Data Mark).  We
   agree with Wayne's observation that the phrase "interesting things",
   as it appears and is explained in the TELNET Protocol Document (NIC#
   15372), is much too imprecise to appear in a protocol specification.
   However, we disagree with his proposal that the interpretation of the
   TELNET SYNCH sequence should be redefined.  Hathaway's comments led
   us to examine the notion of "interesting things" with respect both to
   TELNET protocol and to protocols built upon it.

この注意はTELNET SYNCH系列(INS/Dataマーク)の解釈を批評するウェインハザウェイのRFC513によって動機づけられています。 私たちは、プロトコル仕様に現れるのをそれが現れて、TELNETプロトコルDocument(NIC#15372)で説明されるように「おもしろいもの」という句が非常に不正確過ぎるというウェインの観測に同意します。 しかしながら、私たちはTELNET SYNCH系列の解釈が再定義されるべきであるという彼の提案と意見を異にします。 ハザウェイのコメントは、私たちが敬意をもってTELNETプロトコルと、そして、それで築き上げられたプロトコルに「おもしろいもの」の概念を調べるように導きました。

   We feel that the definition of the TELNET SYNCH sequence in the
   TELNET Protocol Document is the proper one [1].  More important, we
   feel that the (potential) difficulties with respect to the TELNET
   SYNCH sequence noted in RFC 513 are not the reflection of a TELNET
   design flaw but rather reflect misuse of the TELNET SYNCH sequence by
   "higher level" protocols (in particular FTP) that are based on
   TELNET.

私たちは、TELNETプロトコルDocumentとのTELNET SYNCH系列の定義が適切なもの[1]であると感じます。 より重要です、私たちはRFC513に述べられたTELNET SYNCH系列に関する(潜在的)の困難がTELNET設計上の欠陥の反映でないと感じますが、TELNETに基づいている「より高いレベル」プロトコル(特にFTP)でむしろTELNET SYNCH系列の誤用を反映します。

   The remainder of this note examines the notion of a synch sequence
   and suggests an approach to the design of protocols which are to use
   the TELNET protocol as a basis.

この注意の残りは、同時性系列の概念を調べて、基礎としてTELNETプロトコルを使用することであるプロトコルのデザインへのアプローチを示します。

   The reason for defining a synch sequence for a protocol is to provide
   a mechanism by which signals, represented as characters, that for one
   reason or another are "stuck" in the pipeline between the sender and
   the protocol interpreter, can promptly be brought to the attention of
   the interpreter.  Flow through the pipeline is, of course, controlled
   by the receiver; the process operating the interpreter may be doing
   something else at the moment, and may not be paying attention to the
   incoming data stream.  The sender would like to get the attention of
   the receiving process, to have it read its incoming data stream and
   take action as directed by the "interesting" characters in that
   stream, which will, in general, be protocol commands.  To accomplish
   this, a "SYNCH sequence" is transmitted.  A synch sequence consists
   of:

プロトコルのために同時性系列を定義する理由は即座にキャラクタとして表された何らかの理由のために送付者とプロトコルインタプリタの間のパイプラインで「張り付けられる」信号をインタプリタの注意に持って来ることができるメカニズムを提供することです。 パイプラインを通した流れはもちろん受信機によって制御されます。 インタプリタを操作するプロセスは、現在他の何かをしていて、受信データストリームに注意を向けていないかもしれません。 送付者は、それに受信データストリームを読ませるように受信プロセスの注意を得て、そのストリームで「おもしろい」キャラクタによる指示されるとしての行動を取りたがっています。(一般に、それは、プロトコルコマンドになるでしょう)。 これを達成するために、「SYNCH系列」は伝えられます。 同時性系列は以下から成ります。

McKenzie, et. al.                                               [Page 1]

RFC 529            A Note on Protocol Synch Sequences       29 June 1973

etマッケンジー、アル。 [1ページ] プロトコル同時性系列1973年6月29日の1注意あたりRFC529

      1. An "out of band" signal which serves to get the attention of
         the protocol interpreter; and

1. プロトコルインタプリタの注意を得るのに役立つ「バンド」信号。 そして

      2. An "in band" marker which serves to mark how much of the data
         stream is to be processed by the protocol interpreter in
         response to the "out of band" signal.

2. データ・ストリームの多くがプロトコルインタプリタによってどう「バンド」信号に対応して処理されるかことであることをマークするのに役立つ「バンド」マーカー。

   For the TELNET protocol the "out of band" signal is the INS of Host-
   Host Protocol and the "in band" marker is the TELNET Data Mark
   character (DM).  Ignoring for the moment the use of TELNET as a basis
   for higher level protocols (such as FTP), the class of characters
   "interesting" to a TELNET interpreter is the set of TELNET commands
   (including the commands for option negotiation and sub-negotiation
   [2]).

TELNETプロトコルのために、「バンド」信号はHostホストプロトコルのINSです、そして、「バンド」マーカーはTELNET Dataマークキャラクタ(DM)です。 さしあたりより高いレベルプロトコル(FTPなどの)の基礎としてTELNETの使用を無視して、TELNETインタプリタに、「おもしろい」キャラクタのクラスはTELNETコマンドのセットです。(オプション交渉とサブ交渉[2])のためのコマンドを含んでいます。

   One might reasonably argue that this class could be enlarged by a
   server Host to include the set of signals of interest to the terminal
   support software of that particular Host.  For example, in case of
   TENEX such a set would include the "terminal interrupt" characters
   enabled by the process reading from the TELNET connection (e.g., ^C,
   ^T, etc.).  Other hosts, such as Multics, might look only for the
   TELNET commands, such as Interrupt Process (IP), Abort Output (AO),
   etc.  Whether or not one chooses to consider additional signals as
   interesting during the processing of a TELNET SYNCH sequence should
   cause the implementer no problem:

1つは、サーバHostがその特定のHostの端末の支援ソフトウェアに興味がある信号のセットを含むようにこのクラスを拡大できたと合理的に主張するかもしれません。 例えば、TENEXの場合に、そのようなセットはTELNET接続(例えば、^C、^Tなど)から読むプロセスによって可能にされた「端末の中断」キャラクタを含んでいるでしょう。 Multicsなどの他のホストはTELNETコマンドだけを探すかもしれません、Interrupt Process(IP)、Abort Output(AO)などのように 人が、TELNET SYNCH系列の処理の間、追加信号がおもしろいとみなすのを選ぶかどうかが問題を全くimplementerに引き起こすべきではありません:

      He must treat all TELNET commands as interesting by interpreting
      them.  He may choose either to ignore such additional signals or
      to pass them on to the process; in either case there is no
      vagueness since the implementer knows which characters his
      terminal support software considers interesting.

彼はそれらを解釈することによっておもしろいとしてすべてのTELNETコマンドを扱わなければなりません。 彼は、そのような追加信号を無視するか、またはそれらをプロセスに通過するのを選ぶかもしれません。 どちらの場合には、implementerが、彼の端末の支援ソフトウェアが、おもしろいとどのキャラクタが考えるかを知っているので、あいまいさが全くありません。

   The difficulty noted in RFC 513 concerning the vagueness of
   "interesting things" occurs when a higher level protocol makes use of
   the TELNET SYNCH sequence to force commands of interest to it through
   to its interpreter.  A higher level protocol designed in such a way
   represents a violation of the protocol layering discipline:

より高い平らなプロトコルがそれに興味があるコマンドをインタプリタにおいて突き抜けるのに強制するのにTELNET SYNCH系列を利用するとき、RFC513に「おもしろいもの」のあいまいさに関して述べられた困難は起こります。 そのような方法で設計されたより高い平らなプロトコルはプロトコルレイヤリング規律の違反を表します:

      The TELNET SYNCH mechanism is being misused by attempting to give
      it meaning at two different levels of protocol.

プロトコルの2つの異なったレベルで意味をそれに与えるのを試みることによって、TELNET SYNCHメカニズムは誤用されています。

   The problem stems from the fact that, in general, a (increasing)
   number of different higher level protocols can be designed with
   TELNET as a base.  A TELNET interpreter has no way of knowing the
   higher level protocol interpreter (if any) to which it is passing
   characters, and therefore, can not tell which things are
   "interesting" to the higher level protocol interpreter.  That is,
   just as an NCP should not have to know whether the data it handles is

問題は一般に、(増加すること)の数の異なったより高い平らなプロトコルがTELNETと共にベースとして設計される場合があるという事実によります。 TELNETインタプリタには、それがキャラクタを渡しているより高い平らなプロトコルインタプリタ(もしあれば)を知る方法が全くありません、そして、したがって、より高い平らなプロトコルインタプリタに、どのものが「おもしろいか」わかりません。 NCPがそれが扱うデータがそうであるか否かに関係なく、知るだけである必要はないはずであるようにそれはそうです。

McKenzie, et. al.                                               [Page 2]

RFC 529            A Note on Protocol Synch Sequences       29 June 1973

etマッケンジー、アル。 [2ページ] プロトコル同時性系列1973年6月29日の1注意あたりRFC529

   for a TELNET connection, an FTP data connection, etc., a TELNET
   interpreter should not be required to know the kind of process for
   which it is handling characters.  This should, in fact, result in a
   simplification of the design and implementation of TELNET protocol
   interpreters.

TELNET接続、FTPデータ接続などにおいて、それが取り扱いキャラクタであるプロセスの種類を知るためにTELNETインタプリタを必要とするべきではありません。 事実上、これはTELNETプロトコルインタプリタの設計と実装の簡素化をもたらすべきです。

   This difficulty can be resolved by proper design of protocols that
   make use of TELNET as a base.  In particular, if in such a higher
   level protocol it is important to be able to force commands through
   to the protocol interpreter, the higher level protocol should include
   its own synch sequence:  i.e., an "out of band" signal used with an
   "in band" data mark.  The TELNET protocol provides the Interrupt
   Process character (IP) for use as an "out of band" signal.  A synch
   sequence for a protocol built upon TELNET would be:

ベースとしてTELNETを利用するプロトコルの適切なデザインはこの困難を決議できます。 そのようなより高い平らなプロトコルでは、プロトコルインタプリタにおいて突き抜けるのにコマンドを強制できるのが重要であるなら、特に、より高い平らなプロトコルはそれ自身の同時性系列を含むべきです: すなわち、データがマークする「バンド」に使用される「バンド」信号。 TELNETプロトコルは使用のために「バンド」信号としてキャラクタ(IP)をInterrupt Processに供給します。 TELNETで築き上げられたプロトコルのための同時性系列は以下の通りでしょう。

      1. Insert the TELNET IP control character into the data stream;

1. TELNET IP制御文字をデータ・ストリームの中に挿入してください。

      2. Insert the higher level protocol data mark character (HDM) into
         the data stream following whatever higher level protocol
         commands are important at the time.

2. どんな当時、重要なより高い平らなプロトコルコマンドにも続いて、より高い平らなプロトコルデータ・マークキャラクタ(HDM)をデータ・ストリームの中に挿入してください。

   Receipt of the IP TELNET command causes the higher level protocol
   interpreter to be interrupted, enabling it to scan the data stream
   (up to and including the HDM) for commands it considers important.

IP TELNETコマンドの領収書で、より高い平らなプロトコルインタプリタを遮ります、重要であると考えるコマンドのためにデータ・ストリームをスキャンするのを(HDMを含めて)可能にして。

   As an example, consider the case of the File Transfer Protocol (RFC
   454) and the problem of aborting a file transfer in progress.  To
   accomplish such an abort the FTP user (process) should:

例として、File Transferに関するケースがプロトコル(RFC454)と進行中のファイル転送を中止するという問題であると考えてください。 そのようなアボートを実行するために、FTPユーザ(プロセス)はそうするべきです:

      1. Send the TELNET IP character;

1. TELNET IPキャラクタを送ってください。

      2. Send the TELNET SYNC sequence, that is:

2. すなわち、TELNET SYNC系列を送ってください:

         a. Send the TELNET Data Mark (DM);

a。 telnetデータ・マーク(DM)を送ってください。

         b. Send the Host-Host Protocol INS;

b。 ホスト兼ホストプロトコルINSを送ってください。

      3. Send the FTP ABOR command; and

3. FTP ABORコマンドを送ってください。 そして

      4. Send the FTP data mark character [3].

4. FTPデータ・マークキャラクタ[3]を送ってください。

   The user (or process acting on his behalf) must transmit the TELNET
   SYNCH sequence of step 2 above to ensure that the TELNET IP gets
   through to the server's TELNET interpreter.

ユーザ(彼の代理に影響しながら、処理する)はTELNET IPがサーバのTELNETインタプリタに通じるのを保証するためには上のステップ2のTELNET SYNCH系列を伝えなければなりません。

McKenzie, et. al.                                               [Page 3]

RFC 529            A Note on Protocol Synch Sequences       29 June 1973

etマッケンジー、アル。 [3ページ] プロトコル同時性系列1973年6月29日の1注意あたりRFC529

Endnotes

エンドノート

   [1] I.e., any TELNET commands appearing before the Data Mark are to
   be interpreted; the Data Mark is to be used to terminate the scan
   initiated by the INS; characters that are not TELNET commands may be
   discarded or passed to the user process as the implementer sees fit.

[1] Dataマークの前に現れるすなわちどんなTELNETコマンドも解釈されることです。 DataマークはINSによって開始されたスキャンを終えるのに使用されることになっています。 implementerが適していると決めるように、TELNETコマンドでないキャラクタは、ユーザ・プロセスに捨てられるか、または通過されるかもしれません。

   [2] We support Hathaway's proposal to fully parenthesize sub-
   negotiations.  Further, we believe that the "closing parenthesis"
   should be a new command rather than a second SB command; this will
   aid the receiver in recovering from errors, either in parsing at the
   receiver or in generation at the transmitter.  We disagree with his
   proposal that sub-negotiations be discarded when encountered during
   processing of a TELNET SYNCH.

[2] 私たちはサブ交渉を完全にparenthesizeするというハザウェイの提案をサポートします。 さらに、私たちは、「閉じ括弧」が2番目のSBコマンドよりむしろ新しいコマンドであると信じています。 これは送信機でエラーを回復するか、受信機で分析するか、または世代で受信機を支援するでしょう。 私たちはTELNET SYNCHの処理の間、遭遇するとサブ交渉が捨てられるという彼の提案と意見を異にします。

   [3] For FTP such a data mark character has not yet been defined and,
   in fact, may not be necessary under the constraint that the FTP
   command interpreter should look for exactly one command after being
   interrupted; this is consistent with the general command-reply
   orientation of FTP.

[3] そのようなデータ・マークキャラクタは、FTPに、まだ定義されていなくて、また事実上、FTPコマンドインタープリタが中断された後にまさに1つのコマンドを探すはずであるという規制で必要でないかもしれません。 これはFTPの一般的なコマンド回答オリエンテーションと一致しています。

          [This RFC was put into machine readable form for entry]
     [into the online RFC archives by Helene Morin, Via Genie 12/1999]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ヘレーネのモーリンによるオンラインRFCアーカイブへのVia Genie12/1999]

McKenzie, et. al.                                               [Page 4]

etマッケンジー、アル。 [4ページ]