RFC80 日本語訳

Network Working Group                                         E. Harslem
Request for Comments: 80                                      J. Heafner
NIC: 5608                                                           RAND
                                                         1 December 1970

Harslemがコメントのために要求するワーキンググループE.をネットワークでつないでください: 80 J.Heafner NIC: 5608年のランドの1970年12月1日

                       PROTOCOLS AND DATA FORMATS

プロトコルとデータ形式

   Because of recent discussions of protocols and data formats we issue
   this note to highlight our current attitudes and investigations in
   those regards.  We first discuss some specific sequences, and then
   offer some thoughts on two general implementation approaches that
   will handle these and other specifics.  We wish to place emphasis on
   the _general solutions_ and not on the specifics.

プロトコルとデータ形式の最近の議論のために、私たちは、それらの点における私たちの現在の態度と調査を目立たせるようにこの注意を発行します。 私たちは、最初にいくつかの特定の系列について議論して、次に、これらを扱う2つの一般的な実装アプローチと他の詳細に対してはいくつかの考えを提供します。 詳細ではなく、_一般解_を強調したいと思います。

INITIAL CONNECTION PROTOCOLS

初期の接続プロトコル

   We wish to make two points concerning specific Initial Connection
   Protocols (IPCs).  Firstly, the IPC described in NEW/RFC #66--its
   generality and a restatement of that ICP.  Secondly, a proposal for a
   variant ICP using basically the same logic as NWG/RFC #66.

特定のInitial Connectionに関する2ポイントをプロトコル(IPCs)にしたいと思います。 まず第一に、IPCはNEW/RFCで#66、について説明しました--一般性とそのICPの再声明。 基本的にNWG/RFC#66と同じ論理を使用する異形ICPのための第二に提案。

I. NWG/RFC #66

I. NWG/RFC#66

   The only technical error in this IPC is that as diagrammed both the
   Server and User send ALL messages before the connections are
   established which is inconsistent with Network Document No. 1.  This
   can easily be remedied as will be shown in the restatement below.

このIPCにおける唯一の技術的な誤りは接続が確立される前にServerとUserの両方が図解されるようにすべてのメッセージを送るということです(Network Document No.1に矛盾しています)。 以下での再声明で示されるように容易にこれを治すことができます。

   In terms of generality, any ICP that is adopted as a standard should
   apply to more situations than a process calling a logger.  That is,
   some Network service processes that hook directly to a user process,
   independent of logger action, could perhaps use a standard ICP.
   Thus, as is shown below, the process name field of the server socket
   should be a parameter with a value of zero being a special case for
   loggers.

一般性、きこりに電話をする規格がプロセスより多くの状況に適用されるべきであるとき採用されるどんなICPに関しても。 きこりの動作の如何にかかわらず直接ユーザ・プロセスを接続するすなわちいくつかのNetworkサービス過程が恐らく標準のICPを使用するかもしれません。 このようにして、そして、そのままで、以下に示されて、サーバソケットのプロセス名前欄はきこりにとって、特別なケースであるゼロの値のパラメタであるべきです。

   Restatement of NWG/RFC #66 (using the same wording where appropriate)

NWG/RFC#66の再声明(適切であるところで同じ言葉遣いを使用します)

      1. To initiate contact, the using process attaches a receive
         socket (US) and requests connection to process SERV socket #1
         in the serving HOST.  (SERV = 0 for ICP to the logger.)  As a
         result the using NCP sends:

1. 開始に、接触、使用の加工処理した大使館員aは、ソケット(米国)を受けて、給仕におけるプロセスSERVソケット#1との接続のためにHOST(きこりへのICPのためのSERV=0)を要求します。 その結果、使用NCPは発信します:

Harslem, et. al.                                                [Page 1]

RFC 80                 Protocols and Data Formats        1 December 1970

et Harslem、アル。 [1ページ] RFC80プロトコルとデータは1970年12月1日をフォーマットします。

            1              4                 3          1     1
         +-----+---------------------+---------------+-----+-----+
         | RTS |          US         |      SERV     |  1  |  P  |
         +-----+---------------------+---------------+-----+-----+

1 4 3 1 1 +-----+---------------------+---------------+-----+-----+ | RTS| 米国| SERV| 1 | P| +-----+---------------------+---------------+-----+-----+

         over link 1, where P is the receive link.

リンク1の上、リンクを受けてください。そこでは、Pがそうです。

      2. The serving process (SERV) may decide to refuse to the call, in
         which case it closes the connection.  If it accepts the call,
         the serving process completes the connection (via an INIT
         system call, hence an STR).

2. 給仕プロセス(SERV)は、呼び出しに拒否すると決めるかもしれません、その場合、それは接続を終えます。 呼び出しを受け入れるなら、給仕プロセスは接続(したがって、INITシステムコールを通したSTR)を終了します。

            1           3          1            4
         +-----+----------------+-----+--------------------+
         | STR |      SERV      |  1  |         US         |
         +-----+----------------+-----+--------------------+

1 3 1 4 +-----+----------------+-----+--------------------+ | STR| SERV| 1 | 米国| +-----+----------------+-----+--------------------+

      3. When the connection is completed, the user process allocates a
         nominal amount of space to the connection, resulting in the NCP
         sending:

3. 接続が終了しているとき、ユーザ・プロセスは名目上のスペースの合計を接続に割り当てます、NCP発信をもたらして:

            1     1            4
         +-----+-----+--------------------+
         | ALL |  P  |       SPACE        |
         +-----+-----+--------------------+

1 1 4 +-----+-----+--------------------+ | すべて| P| スペース| +-----+-----+--------------------+

         where SPACE is the amount.

SPACEが量であるところ。

      4. The serving process then selects the socket pair it wishes to
         assign this user.  It sends exactly an even 32 bit number over
         the connection.  This even 32 bit number (SS) is the receive
         socket in the serving HOST.  This socket and the next higher
         numbered socket are reserved for the using process.

4. そして、給仕プロセスはそれがこのユーザを配属したがっているソケット組を選びます。 それはちょうど32ビットさえの数を接続の上に送ります。 給仕HOSTでソケットを受けてください。この32ビットさえの数(SS)がそう、このソケットと次の、より高い番号付のソケットは使用プロセスのために予約されます。

      5. It then closes the connection.  The serving NCP sends (step 4):

5. そして、それは接続を終えます。 給仕NCPは(ステップ4)を送ります:

                    4
         +---------------------+
         |         SS          |
         +---------------------+

4 +---------------------+ | SS| +---------------------+

         on link P, and (step 5):

リンクP、および(ステップ5)に関して:

Harslem, et. al.                                                [Page 2]

RFC 80                 Protocols and Data Formats        1 December 1970

et Harslem、アル。 [2ページ] RFC80プロトコルとデータは1970年12月1日をフォーマットします。

            1            3         1             4
         +-----+----------------+-----+--------------------+
         | CLS |       SERV     |  1  |         US         |
         +-----+----------------+-----+--------------------+

1 3 1 4 +-----+----------------+-----+--------------------+ | CLS| SERV| 1 | 米国| +-----+----------------+-----+--------------------+

         on the control link (which is echoed by the using NCP).

コントロールのときに、リンクしてください(使用NCPによって反響されます)。

      6. Now that both server and user are aware of the remote socket
         pair for the duplex connection, <STR, RTS>s can be exchanged.

6. 重複の接続、<STRにおいて、サーバとユーザの両方がリモートソケット組を意識しているので、RTS>sを交換できます。

         _Sever sends User_

_切れてください、User_を送ります。

            1            4                     4
         +-----+--------------------+--------------------+
         | STR |      SS + 1        |          US        |
         +-----+--------------------+--------------------+---+
         | RTS |         SS         |        SS + 1      | Q |
         +-----+--------------------+--------------------+---+

1 4 4 +-----+--------------------+--------------------+ | STR| SS+1| 米国| +-----+--------------------+--------------------+---+ | RTS| SS| SS+1| Q| +-----+--------------------+--------------------+---+

         where Q is the Server's receive link.

QがServerのところであるところでは、リンクを受けてください。

         _User sends Server_

_ユーザはServer_を送ります。

            1             4                    4
         +-----+--------------------+--------------------+
         | STR |       US + 1       |         SS         |
         +-----+--------------------+--------------------+---+
         | RTS |          US        |       SS + 1       | R |
         +-----+--------------------+--------------------+---+

1 4 4 +-----+--------------------+--------------------+ | STR| 米国+1| SS| +-----+--------------------+--------------------+---+ | RTS| 米国| SS+1| R| +-----+--------------------+--------------------+---+

         where R is the User's receive link.

RがUserのところであるところでは、リンクを受けてください。

         ALLocates may then be sent and transmission begun.

ALLocatesはそうするかもしれません、次に、送ってください。そして、始められたトランスミッション。

II.  A Variation of NWG/RFC #66

II。 NWG/RFC#66の変化

   This variation reduces Network messages and eliminates duplication of
   information transfer.

この変化は、Networkメッセージを減らして、情報転送の複製を排除します。

   Steps 3 and 4 above are deleted.  The user process is not notified
   directly which of the Server's sockets it will be assigned.  The user
   process, however, will listen on sockets US and US + 1 for calls from
   SERV after step 5 above.  It can reject any spurious calls.  In
   accepting the calls from SERV, the connection is established.

上のステップ3と4は削除されます。 ユーザ・プロセスはそうです。直接、それが割り当てられるServerのソケットのどれに通知しなかったか。 しかしながら、ユーザ・プロセスは上のステップ5の後に呼び出しのためのソケット米国と米国+1でSERVから聴かれるでしょう。 それはどんな偽りの呼び出しも拒絶できます。 SERVから呼び出しを受け入れるのに、接続は確立されます。

   The following sample sequence illustrates this ICP.  (The notation is
   as above).

以下のサンプル系列はこのICPを例証します。 (記法が同じくらい上にあります。)

Harslem, et. al.                                                [Page 3]

RFC 80                 Protocols and Data Formats        1 December 1970

et Harslem、アル。 [3ページ] RFC80プロトコルとデータは1970年12月1日をフォーマットします。

   1. User --> Server

1. ユーザ-->サーバ

         1            4                    3         1     1
      +-----+--------------------+----------------+-----+-----+
      | RTS |         US         |       SERV     |  1  |  P  |
      +-----+--------------------+----------------+-----+-----+

1 4 3 1 1 +-----+--------------------+----------------+-----+-----+ | RTS| 米国| SERV| 1 | P| +-----+--------------------+----------------+-----+-----+

   2. Server --> User

2. サーバ-->ユーザ

      If accepted:

受け入れるなら:

         1           3          1             4
      +-----+----------------+-----+---------------------+
      | STR |      SERV      |  1  |         US          |
      +-----+----------------+-----+---------------------+
      | CLS |      SERV      |  1  |         US          |
      +-----+----------------+-----+---------------------+

1 3 1 4 +-----+----------------+-----+---------------------+ | STR| SERV| 1 | 米国| +-----+----------------+-----+---------------------+ | CLS| SERV| 1 | 米国| +-----+----------------+-----+---------------------+

      If rejected:

拒絶されるなら:

         1           3          1             4
      +-----+----------------+-----+---------------------+
      | CLS |      SERV      |  1  |         US          |
      +-----+----------------+-----+---------------------+

1 3 1 4 +-----+----------------+-----+---------------------+ | CLS| SERV| 1 | 米国| +-----+----------------+-----+---------------------+

   3. If accepted, user listens on US and US + 1.

3. 受け入れるなら、ユーザは米国と米国+1で聴きます。

   4. Server --> User

4. サーバ-->ユーザ

         1             4                     4
      +-----+--------------------+---------------------+
      | STR |       SS + 1       |          US         |
      +-----+--------------------+---------------------+---+
      | RTS |         SS         |        US + 1       | Q |
      +-----+--------------------+---------------------+---+

1 4 4 +-----+--------------------+---------------------+ | STR| SS+1| 米国| +-----+--------------------+---------------------+---+ | RTS| SS| 米国+1| Q| +-----+--------------------+---------------------+---+

   5. User accepts the calls, hence:

5. したがって、ユーザは呼び出しを受け入れます:

      User --> Sender

ユーザ-->送付者

         1              4                     4
      +-----+---------------------+--------------------+
      | STR |        US + 1       |        SS + 1      |
      +-----+---------------------+--------------------+---+
      | RTS |        US + 1       |          SS        | R |
      +-----+---------------------+--------------------+---+

1 4 4 +-----+---------------------+--------------------+ | STR| 米国+1| SS+1| +-----+---------------------+--------------------+---+ | RTS| 米国+1| SS| R| +-----+---------------------+--------------------+---+

      and the connection is established.

そして、接続は確立されます。

Harslem, et. al.                                                [Page 4]

RFC 80                 Protocols and Data Formats        1 December 1970

et Harslem、アル。 [4ページ] RFC80プロトコルとデータは1970年12月1日をフォーマットします。

   This reduces the number of network messages by two and only passes
   the information regarding the Server's sockets once via RTS and STR.

これは、ネットワークメッセージの数を2つ減少させて、RTSとSTRを通して一度Serverのソケットの情報を通過するだけです。

   PRE-SPECIFIED DATA FORMATS

あらかじめ指定されたデータ形式

   We would like to adopt those suggestions for data formats in NWG/RFC
   #42 and #63.  We subscribe to multiple standards as solutions to
   particular problem classes.

NWG/RFC#42、と#63のデータ形式のためのそれらの提案を採用したいと思います。 私たちは特定の問題のクラスへのソリューションとして平均物価標準に加入します。

   AN ADAPTABLE MECHANISM

融通のきくメカニズム

      We would like to adapt to Network use, problem programs that were
      not planned with the Network in mind, and which, no doubt, will
      not easily succumb to Network standards existing at the time of
      their inclusion.  This incompatibility problem is just as
      fundamental a part of the research underlying the Network as is
      different Host hardware.  To require extensive front-ends on each
      such program is not a reasonable goal.  We view the Network as an
      amalgamation of a) Hosts that provide services; b) parasite Hosts
      that interface terminals to the services, and c) a spectrum of
      Hosts that behave as both users and providers of services.  To
      require that each parasite Host handle different protocols and
      data formats for all services that its users need is not a
      reasonable goal.  The result is programs and terminals that wish
      to communicate but do not speak the same language.

Network使用、Networkと共に念頭に計画されないで、また間違いなく容易に彼らの包含時点で存在するNetwork規格に屈しない問題プログラムに順応したいと思います。 この非互換問題はNetworkの基礎となる研究の異なったHostハードウェアであるのとちょうど同じくらい基本的な部分です。 そのような各プログラムのときに大規模なフロントエンドを必要とするのは、妥当な目標ではありません。 私たちはa)の合併であるとNetworkをみなします。 サービスを提供するホスト。 c) サービスに端末を連結するb)寄生体Hosts、およびユーザとサービスのプロバイダーの両方として振る舞うHostsのスペクトル。 各寄生体Hostがユーザが必要とするすべてのサービスのために異なったプロトコルとデータ形式を扱うのが必要であるのは、妥当な目標ではありません。 結果はプログラムであり、端末は交信しますが、同じ言語を話さないというその願望です。

      One approach to the protocol and data format problems is to
      provide an adaptable mechanism that programs and terminals can use
      to easily access Network resources.  ARPA is sponsoring the
      Adaptive Communicator Project at Rand which is a research effort
      to investigate a teachable front-end process to interface man to
      program.  The variety of terminal devices being explored include
      voice, tablets, sophisticated graphics terminals, etc.

プロトコルとデータの形式問題への1つのアプローチはプログラムと端末が容易にNetworkリソースにアクセスするのに使用できる融通のきくメカニズムを提供することです。 ARPAは、プログラムを作るために男性を連結するように教えやすい前端プロセスを調査するために研究取り組みであるRandのAdaptiveコミュニケーターProjectを後援しています。 探られる端末装置のバラエティーは声、タブレット、高性能のグラフィックス端末などを含んでいます。

      The Adaptive Communicator looks very encouraging but it will not
      be ready for some time.  The Network Project at Rand chose to take
      the adaptable approach (_not_ adaptive, i.e., no heuristics, no
      self-learning).  Our problem is to get Rand researchers onto the
      Network easily, assuming that they have different simultaneous
      applications calling for different program protocols and data
      configurations.

Adaptiveコミュニケーターは非常に励みになるように見えますが、それはしばらく準備ができないでしょう。 RandのNetwork Projectが、融通のきくアプローチを取るのを選んだ、(_、_適応型でない、すなわち、いいえが自己に学ぶ発見的教授法がありません。 私たちの問題は容易にRand研究者をNetworkに得ることです、彼らには異なったプログラムプロトコルとデータ構成を求める異なった同時のアプリケーションがあると仮定して。

      Protocols and data formats will be described separately to
      illustrate what we mean by adaptation.  Protocols are sequences of
      "system calls" that correspond to (and result in NCP's issuance
      of) NCP commands.  Data formats are the descriptions of regular
      message contents and are not meaningful to an NCP.

プロトコルとデータ形式は、私たちが適合で言っていることを例証するために別々に説明されるでしょう。 そして、プロトコルがそれが相当する「システムコール」の系列である、(NCPの発行となる、)、NCPコマンド。 データ形式は、通常のメッセージ内容の記述であり、NCPに重要ではありません。

Harslem, et. al.                                                [Page 5]

RFC 80                 Protocols and Data Formats        1 December 1970

et Harslem、アル。 [5ページ] RFC80プロトコルとデータは1970年12月1日をフォーマットします。

   The Form Machine (adapting to data formats)

フォームマシン(データ形式に順応します)

      To put the reader in context, the Form Machine is of the class of
      finite state machines that recognize a form of _regular_
      expressions_ which, in our case, describe data formats.  The
      notation, however, is aimed at particular descriptions and
      therefore can be more succinct, for our purposes, than the
      language of regular expressions.

読者を置くために、私たちの場合でデータ形式について説明する式_は文脈、Form Machineでは、_通常の_のフォームを認識する有限状態機械のクラスのものです。 記法は、しかしながら、特定の記述が目的とされて、したがって、より簡潔である場合があります、私たちの目的のために、正規表現の言語より。

      The Form Machine is an experimental software package that couples
      a variety of programs and terminals whose data format requirements
      are different.  We envision Form Machines located (to reduce
      Network traffic) at various service providing Hosts.

Form Machineはさまざまなプログラムを結合する実験的なソフトウェアパッケージとデータの形式要件が異なっている端末です。 私たちは様々なサービス提供Hostsに位置する(Networkトラフィックを減少させる)Form Machinesを思い描きます。

      To test the Form Machine idea, we are implementing two IBM OS-
      callable subroutines; a compiler that compiles statements which
      describe forms of data formats; and an executor that executes a
      compiled form on a data stream.

Form Machine考えをテストするために、私たちは、2IBM OSが呼ぶことのできるサブルーチンであると実装しています。 データ形式のフォームについて説明する声明を編集するコンパイラ。 そして、データ・ストリームのコンパイルされたフォームを作成する執行者。

      To describe the Form Machine test, it is necessary to mention
      another program at Rand--the Network Services Program (NSP), which
      is a multi-access program that interfaces the Network Control
      Program both to arbitrary programs and to Video Graphics Consoles.
      (We view a terminal as just another program with a different
      interface, i.e., # characters/line, # lines/page, unique hardware
      features, the application to which it is put, etc.)  The Form
      Machine subroutines are callable from NSP upon consoles or program
      direction.

Form Machineテストについて説明するために、別のプログラムについてRandに言及するのが必要です--Network Services Program(NSP)。(そのNetwork Services Programは任意のプログラムと、そして、Video Graphics ConsolesにNetwork Control Programを接続するマルチアクセスプログラムです)。 (私たちは異なったインタフェースでただのプログラムであると端末をみなします、すなわち、#キャラクタ/系列、#系列/ページ、ユニークなハードウェア機能、それが置かれるなどアプリケーション) Form Machineサブルーチンはコンソールかプログラム方向でNSPから呼ぶことのできます。

      Operationally, a console user names and specifies the data forms
      that he will use.  The forms are compiled and stored for later
      use.  At some future time when the user wishes to establish
      Network connections and transmit data, he dynamically associates
      named forms with each side of a port--a symbolically named Network
      full duplex connection.  Data streams incoming or outgoing are
      executed according to the compiled form and the transformed data
      stream is then passed along to the console/program or to the
      Network, respectively.

コンソールユーザは、使用するデータフォームを操作上、命名して、指定します。 フォームは、後の使用のために編集されて、保存されます。 ユーザがNetwork接続を確立して、データを送りたがっているいつかの将来の時に、ダイナミックにポートの各端に命名されたフォームを関連づけます--象徴的に命名されたNetwork全二重接続。 データが入来を流すか、または外向的であるのは、コンパイルされたフォームと変成しているデータによると、実行されて、次に、ストリームがそれぞれコンソール/プログラム、または、Networkに回されるということです。

      The details of the syntax of our Form Machine notation are
      unimportant to the collective Network community.  However, the
      provisions of the notation are of interest.  It will eventually
      encompass the description of high performance CRT displays, TTY,
      and arbitrary file structures.  To test its viability, a subset of
      such features is being implemented.

私たちのForm Machine記法の構文の詳細は集合的なNetwork共同体に重要ではありません。 しかしながら、記法の条項は興味があります。 それは結局、高性能CRTディスプレイ、TTY、および任意のファイル構造の記述を成就するでしょう。 生存力をテストするために、そのような特徴の部分集合は実装されています。

Harslem, et. al.                                                [Page 6]

RFC 80                 Protocols and Data Formats        1 December 1970

et Harslem、アル。 [6ページ] RFC80プロトコルとデータは1970年12月1日をフォーマットします。

      The current version is characterized by the following features:

最新版は以下の特徴によって特徴付けられます:

         1)    Character code translation (viz., decimal, octal,
               hexidecimal, 8 bit ASCII, 7 bit ASCII, EBCDIC, and
               binary).

1) キャラクターコード変換(小数、8進、hexidecimal、つまり、8はASCII、7ビットのASCII、EBCDIC、およびバイナリーに噛み付きました)。

         2)    Multiple break strings (many terminals have multiple
               termination signals).

2) 複数の中断ストリング(多くの端末には、複数の終止コドンがあります)。

         3)    Insertion of literals (used primarily for display
               information presentation).

3) リテラル(主としてディスプレイ情報プレゼンテーションのために、使用される)の挿入。

         4)    Skip or delete arbitrary strings (used to remove record
               sequence numbers, etc., that are not to be displayed).

4) 任意のストリング(以前は、よく表示してはいけないレコードの順序番号などを取り除いていた)をスキップするか、または削除してください。

         5)    Record sequence number generation.

5) 一連番号世代を記録してください。

         6)    String-length computation and insertion.

6) ストリング長計算と挿入。

         7)    _Arbitrary_ data string length specifications, e.g., "a
               hex literal string followed by an _arbitrary_ number of
               EBCDIC characters, followed by a break string, .....".

7) _任意の_データは長さの仕様、例えば、「文字通りのストリングが中断ストリングが支えた_の任意の_番号のEBCDlC文字を続けた十六進法」を結びます…

         8)    Concatenation of Network messages, i.e., the execution of
               compiled forms on incomplete data strings.

8) すなわち、Networkメッセージの連結、不完全な資料ストリングにおけるコンパイルされた形式の実行。

         9)    Data field transposition.

9) データは転置をさばきます。

         10)   Both explicit and indefinite multiplicative factors for
               both single and multi-line messages.

10) 明白なものとともに単一の、そして、マルチ系列のメッセージのための同様に無期の倍数因子。

      Features that are not being implemented but will be added, if
      successful, include:

うまくいくなら、実装されませんが、加えられる特徴は:

         1)    Graphics oriented descriptions.

1) グラフィックスは記述を適応させました。

         2)    General number translations.

2) 一般数の翻訳。

         3)    Conditional statements.

3) 条件文。

         4)    A pointer capability.

4) 指針能力。

   The Protocol Manager (adapting to NCP command sequences)

プロトコルマネージャ(NCPコマンド・シーケンスに順応します)

      The NSP allows terminal users and programs to work at the NCP
      protocol level; i.e., LISTEN, INIT, et al.  It also allows them to
      transmit and massage information meaningful only to themselves.
      This "hands-on" approach is desirable from the systems

NSPはNCPプロトコルレベルで端末ユーザとプログラムを動作させます。 すなわち、LISTEN、INIT、他 それで、また、彼らは、自分たちだけに、重要な情報を伝えて、マッサージします。 この「実地」のアプローチはシステムから望ましいです。

Harslem, et. al.                                                [Page 7]

RFC 80                 Protocols and Data Formats        1 December 1970

et Harslem、アル。 [7ページ] RFC80プロトコルとデータは1970年12月1日をフォーマットします。

      programmer's, or exploratory point of view.  However, it is
      desirable to eliminate the laborious "handshaking" for the
      researcher who repeatedly uses a given remote program by allowing
      him to define, store, retrieve, and execute "canned" protocol
      sequences.

プログラマのもの、または踏査の観点。 しかしながら、彼が「缶詰」のプロトコル系列を定義して、保存して、検索して、実行するのを許容することによって繰り返して与えられたリモートプログラムを使用する研究者のために困難な「ハンドシェイク」を排除するのは望ましいです。

      We are currently specifying a Protocol Manager as a module of NSP
      that will allow the above operations on NCP command sequences.
      Features of the module are:

私たちは現在、NCPコマンド・シーケンスで上の操作を許すNSPのモジュールとしてプロトコルマネージャを指定しています。 モジュールの特徴は以下の通りです。

         1) The sequences may contain "break points" to permit the
            console user to dynamically inject any contextually needed
            information.

1) 系列は、コンソールユーザがダイナミックにどんな文脈的に必要な情報も注入することを許可するために「ブレークポイント」を含むかもしれません。

         2) The parameters of a command may contain tokens whose values
            are supplied by the remote party during the protocol dialog.
            For example, in Note #66 the socket number provided by the
            server is to be used by the user in subsequent RTS, STR
            commands.

2) コマンドのパラメタは値がプロトコル対話の間にリモートパーティーによって供給されるトークンを含むかもしれません。 例えば、Note#66では、サーバによって提供されたソケット番号はその後のRTS(STRコマンド)でユーザによって使用されることです。

   REQUEST

要求

      We would like to hear from anyone concerning the notion of
      adaptation to data formats and protocol.  Is this a reasonable
      approach?  What should it encompass?

データ形式への適合の概念に関してだれからも連絡をいただいて、議定書を作りたいと思います。 これは合理的なアプローチですか? それは何を取り囲むべきですか?

      JFH:EFH:hs

JFH:EFH:hs

Harslem, et. al.                                                [Page 8]

RFC 80                 Protocols and Data Formats        1 December 1970

et Harslem、アル。 [8ページ] RFC80プロトコルとデータは1970年12月1日をフォーマットします。

   Distribution

分配

      Albert Vezza, MIT
      Alfred Cocanower, MERIT
      Gerry Cole, SDC
      Bill English, SRI
      Bob Flegel, Utah
      James Forgie, LL
      Peggy Karp, MITRE
      Nico Haberman, Carnegie-Mellon
      John Heafner, RAND
      Bob Kahn, BB&N
      Margie Lannon, Harvard
      James Madden, Univ. of Ill.
      Thomas O'Sullivan, Raytheon
      Larry Roberts, ARPA
      Robert Sproull, Stanford
      Ron Stoughton, UCSB
      Chuck Rose, Case University
      Benita Kirstel, UCLA

アルバートVezza、MIT斜め継ぎのアルフレッドCocanower、長所ゲリー・コール、SDCビルEnglish、様のボブ・フレーゲル、ユタジェームスForgie、LLペギー・カープ、ニコ・ハーバーマン、カーネギー-メロンジョンHeafner、底ならし革ボブ・カーン、掲示板、およびNマージーLannon、ハーバードのジェームスは怒らせます、イリノイ州の大学 トーマス・オサリヴァン、レイセオンのラリー・ロバーツ、アルパロバート・スプラウル、スタンフォード・ロンストートン、UCSBチャック・ローズは大学ベニータKirstel、UCLAをケースに入れます。

           [This RFC was put into machine readable form for entry]
            [into the online RFC archives by Lorrie Shiota, 10/01]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロリー塩田によるオンラインRFCアーカイブへの10/01]

Harslem, et. al.                                                [Page 9]

et Harslem、アル。 [9ページ]