RFC295 日本語訳

NWG/RFC #295                             JBP 2-JAN-72 15:35  8355
Protocol Workshop Report

NWG/RFC#295JBP2 1月の72 15: 35 8355プロトコルワークショップレポート

Report of the Protocol Workshop

プロトコルワークショップのレポート

   12 October, 1971

1971年10月12日

   By Jon Postel.

ジョン・ポステル。

Introduction

序論

   This is a report on the decisions reached at the protocol workshop
   held in conjunction with the Network Working Group meeting held in
   Cambridge from 10 to 14 October, 1971.

これは1971年10月10日〜14日の間にケンブリッジで行われるNetwork作業部会の会合に関連して開かれるプロトコルワークショップで達した決定に関するレポートです。

   The workshop addressed itself to protocols of four types: IMP-Host,
   Host-Host, Initial Connection, and Process-Process.

ワークショップは4つのタイプのプロトコルに話しかけました: 悪童ホスト、ホスト兼ホストは接続、およびプロセスプロセスに頭文字をつけます。

IMP-Host Protocol

悪童ホストプロトコル

   The idea of IMP provided status reports to be exchanged via new
   IMP-Host protocol messages was discussed and rejected because it was
   felt that the level of state information which could be reported was
   not sufficient to be worth the trouble of implementing this mechanism.

新しいIMP-ホストを通して交換されるべき現状報告がメッセージについて議定書の中で述べるなら、報告できた州の情報のレベルがこのメカニズムを実装するという問題の価値があるように十分でないと感じられたので、IMPの考えは、議論して、拒絶されました。

Host-Host Protocol

ホスト兼ホストプロトコル

   The Host-Host Protocol was discussed and several problems were brought
   to light, among them were the following listed together with the
   group's recommendations.

Host-ホストプロトコルについて議論しました、そして、いくつかの問題が火が付くのにもたらされました、そして、それらの中に、グループの推薦と共に記載された以下がありました。

      The GVB - RET mechanism may prove useful sometime in the
      future so it will be retained though no one appears to be
      using it now, however spontaneous RET commands are
      explicitly prohibited.

GVB--だれも、現在それを使用しているように見えませんが、それが保有される将来いつか、RETメカニズムは役に立つと判明するかもしれなくて、しかしながら、自然発生的なRETコマンドは明らかに禁止されています。

      The ECO - ERP commands are useful and should be supported,
      but spontaneous ERP commands are explicitly prohibited.  A
      further restriction is that a second ECO will not be sent
      until the first ECO has been answered.  Note that any of
      the following may be an answer to an ECO: ERP, RST,
      "Destination dead", or "Incomplete Transmission".

ECO--ERPコマンドは、役に立って、サポートされるべきですが、自然発生的なERPコマンドは明らかに禁止されています。 さらなる制限は最初のECOが答えられるまで第2のECOが送られないということです。 ↓これのどれかがECOの答えであるかもしれないことに注意してください: ERP、RST、「目的地死者」、または「不完全なトランスミッション。」

      The RST - RRP commands are useful, but the proper use of
      these commands for determining the status of host software
      is still open for discussion (please direct comments to Jon
      Postel), however spontaneous RRP commands are explicitly
      prohibited.

RST--議論において、これらのコマンドのホストソフトウェアの状態を決定する適切な使用がまだ開いている(ジョン・ポステルにコメントを向けてください)、RRPコマンドは役に立ちますが、しかしながら、自然発生的なRRPコマンドは明らかに禁止されています。

                                                                [Page 1]

NWG/RFC #295                             JBP 2-JAN-72 15:35  8355
Protocol Workshop Report

[1ページ]NWG/RFC#295JBP2 1月の72 15: 35 8355プロトコルワークショップレポート

   The problem of unmatched CLS commands are discussed and four
   "solutions" were proposed:

議論するのと4「ソリューション」が提案されたという優れたCLSの問題が、命令することです:

      Hold forever

いつまでも、成立してください。

      Send a RST and clear the entry

RSTを送ってください、そして、エントリーをクリアしてください。

      Clear the entry and possibly mess up a future connection

エントリーをクリアしてください、そして、ことによると今後の接続を台無しにしてください。

      Assign socket numbers in a sequential fashion to reduce
      the possibility of confusion and clear the entry.

連続したファッションでソケット番号を割り当てて、混乱の可能性を減少させて、エントリーをクリアしてください。

   Note that the first two suggestions follow the protocol while the last
   two do not.

最初の2つの提案が最後の2が従っていない間プロトコルに従うことに注意してください。

   The idea of flow control on the control link was suggested.  A Request
   for Comments is to be prepared exploring this idea more fully.

コントロールリンクの上のフロー制御の考えは示されました。 CommentsのためのRequestは、この考えをより完全に探りながら、準備されていることになっています。

   The usefulness of the ERR command is compromised if the receiver
   mearly throws it out.  Thus ERR's are to be logged, if at all
   possible, and checked out with the sending site.

受信機がmearlyにそれを放り出すなら、ERRコマンドの有用性は感染されます。 したがって、ERRのものは、できれば、登録されて、送付サイトで調べられることになっています。

   The NCP document should make clear the implications of queueing or not
   queueing STR & RTS commands.

NCPドキュメントは待ち行列STR&RTSコマンドではなく、待ち行列の含意を明らかにするはずです。

Initial Connection Protocol

初期の接続プロトコル

   The Initial Connection Protocol (ICP) was discussed and found to be
   satisfactory however the following points were stressed:

Initial Connectionプロトコル(ICP)は、以下のポイントがどのように強調されたとしても満足できるのが議論して、わかりました:

     The socket number sent by the logger (S) must be in
     agreement with the socket numbers used in the STR & RTS
     sent by the logger.

きこり(S)によって送られたソケット番号はきこりによって送られたSTR&RTSで使用されるソケット番号に一致しているに違いありません。

     The implications of queueing or not queueing of RTS & STR
     commands should be made clear in the ICP document.  This is
     particularly important if the user chooses the "listen"
     option.

RTS&STRコマンドの待ち行列ではなく、待ち行列の含意がICPドキュメントで明らかにされるべきです。 ユーザが「聴いてください」というオプションを選ぶなら、これは特に重要です。

                                                                [Page 2]

NWG/RFC #295                             JBP 2-JAN-72 15:35  8355
   Protocol Workshop Report

[2ページ]NWG/RFC#295JBP2 1月の72 15: 35 8355プロトコルワークショップレポート

Telnet Protocol

テルネット・プロトコル

   The Telnet committee has been reactivated to consider the following
   problems:

Telnet委員会は以下の問題を考えるために現役に戻されました:

     Clarification of the terminology half duplex, full duplex,
     character mode, line mode, ASCII, and echoing.

用語半二重、全二重、キャラクタ・モード、ライン・モード、ASCII、および反響の明確化。

     Clarification of the end of line convention. Especially to
     answer the question "Should there be a special end-of-line
     character?"

行末コンベンションの明確化。 特に、「特別な行末文字はそういるべきですか?」という質問に答えます。

     Clarification of the conditions for leaving Hide-your-input mode.

いなくなるための状態の明確化、Hide、あなたの入力モード

     Clarification of the operation of Break and Synch.

BreakとSynchの操作の明確化。

     Specification of a server-to-user Synch.

サーバからユーザへのSynchの仕様。

     Clarification of the definition of the Network Virtual Terminal.

Network Virtual Terminalの定義の明確化。

     Preparation of a new document defining the Telnet protocol
     with the above improvements.

上の改良でTelnetプロトコルを定義する新しいドキュメントの準備。

The protocol workshop did agree that:

プロトコルワークショップは、以下のことに同意しました。

  It is the servers option for disconnection to imply logout
  or not.

それは断線がログアウトするように含意するサーバオプションです。

  It is the servers option for logout to imply disconnection
  or not.

それがサーバオプションである、ログアウトして、断線を含意してください。

  Extra characters used locally to fill the time for format
  effectors to take effect should not be sent over the
  network

書式制御文字が効く時間をいっぱいにするのに局所的に使用される付加的なキャラクタをネットワークの上に送るべきではありません。

  Synch means to examine the data stream from the current
  point to a data mark (x'80').  If any break type characters
  (e.g. etx, sub, Break) are found they are to have their
  normal effect.

'電流からデータ・ストリームを調べる同時性手段がデータ・マークを示す、(x80年、'、) 何か中断タイプキャラクタ(例えば、etx、潜水艦、Break)が見つけられるなら、彼らには、彼らの正常な効果があることになっています。

  Upper and lower case are to be available to all Telnet users.

上側の、そして、より低いケースはすべてのTelnetユーザにとって利用可能であることです。

Data and File Transfer Protocol

データとファイル転送プロトコル

   The Data and File Transfer Committee will report separately.

DataとFile Transfer Committeeは別々に報告するでしょう。

                                                                [Page 3]

NWG/RFC #295                             JBP 2-JAN-72 15:35  8355
Protocol Workshop Report

[3ページ]NWG/RFC#295JBP2 1月の72 15: 35 8355プロトコルワークショップレポート

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                   12/96   ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの方向。 12/96 ]

                                                                [Page 4]

[4ページ]