RFC141 日本語訳

Network Working Group                                      E. F. Harslem
Request for Comments: 141                                  J. F. Haefner
NIC 6726                                                            Rand
                                                           29 April 1971

F.Harslemがコメントのために要求するワーキンググループE.をネットワークでつないでください: 141 J.のF.のHaefner NICの6726年のランドの1971年4月29日

             COMMENTS ON RFC 141 (A FILE TRANSFER PROTOCOL)

RFC141のコメント(ファイル転送プロトコル)

   1.  A file transfer protocol is needed.  Bushan's proposal would
   satisfy a particular current need that we have, as well as short-term
   envisioned needs.

1. ファイル転送プロトコルが必要です。 Bushanの提案は私たちが短期的な思い描かれた必要性と同様に持っている特別の現在の需要を満たすでしょう。

   2.  Bushan's protocol would apear to be straight-forward in
   implementation, and extensible as claimed.

2. Bushanのプロトコルは、実装で簡単であって、要求されるとして広げることができるようにapearされるでしょう。

   3.  We would like to see implementations of such protocol be
   accomplished such that the file transfer program has general and
   complete access to the local file storage.  That is, it should be
   able to access a file that it did not create.  For example, if a
   program or user creates a file at site X (completely independent of
   the file transfer program), it would then be desirable to be able to
   retrieve the file via the file transfer program.  This is not a
   requirement of RFC #114 but we would like to see it implemented where
   possible.

3. そのようなプロトコルの実装が達成されるのを見たいと思うので、ファイル転送プログラムは一般的で完全なアクセスをローカルファイルストレージに持っています。 すなわち、それは作成しなかったファイルにアクセスできるべきです。 例えば、プログラムかユーザがサイトX(完全にファイル転送プログラムの如何にかかわらず)でファイルを作成するなら、ファイル転送プログラムを通してファイルを取ることができるのはその時、望ましいでしょう。 これはRFC#114の要件ではありませんが、それが可能であるところで実装されるのを見たいと思います。

   4.  Since implementation of a subset of transaction types is
   specifically permitted, we suggest inclusion of the following
   commands (in addition to append).

4. に加えてトランザクションタイプの部分集合の実装が明確に受入れられるので、私たちが以下のコマンドの包含を勧める、(追加、)

      insert records     within a file
      delete records     from within a file
      replace records    within a file

ファイルの中の差し込み記録は中から、ファイルがファイルの中で記録を置き換えるという記録を削除します。

   Although these operations are not directly supported under IBM
   OS/360, we have used them with a non-standard file subsystem under
   IBM OS/360 and find them quite useful.

これらの操作はIBM OS/360の下で直接サポートされませんでしたが、私たちは、IBM OS/360の下の標準的でないファイルサブシステムでそれらを使用して、それらがかなり役に立つのがわかりました。

   5.  In addition to retrieve and lookup, get names of files under my
   access control would be useful.

5. 私のアクセス制御の下でファイルの名前を得てください。に加えて検索、そして、ルックアップ、役に立つでしょう。

   6.  The absence of status requests and responses is apparent.
   Although this is typically a function associated with a remote job
   entry (RJE) system, since the execute request is present it would
   seem appropriate to inquire about the status of the process created
   by the execute command.  This becomes increasingly more important
   where the execute is implemented as an RJE-like operation and
   scheduling time of the job might be prolonged.

6. 状態要求と応答の欠如は明らかです。 これですが、通常機能が以来リモートジョブエントリ(RJE)システムに関連づけられる、実行、要求はそれが思えるプレゼントが、実行コマンドで作成されたプロセスの状態について問い合わせをするのを当てるということです。 これがますますより重要になる、どこ、実行、仕事のRJEのような操作とスケジューリング時間が長引くかもしれないとき、実装されるか。

Harslem & Haefner                                               [Page 1]

RFC 141                   Comments on RFC 141                 April 1971

Harslem&Haefner[1ページ]RFC141は1971年4月にRFC141を批評します。

   7.  When requesting execute, the using host sends parameters upon
   receipt of the rr response.  Executing a task can be implemented in
   several ways.  The options our 360 affords are RJE at job level and
   the attach macro.  Our preference would be the attach macro which
   immediately initiates an independent OS task within the partition of
   the program issuing the attach (presumably the File Service).  Such a
   task normally receives parameters upon initiation and can thereafter
   receive parameters from a program via some mechanism such as an event
   control block.  The second method requires special modifications to
   the program being executed; hence, it is not desirable.  Therefore,
   we either need the parameters included in the execute command or will
   not actually start execution until parameters are received.

7. いつ、要求が実行するか、使用しているホストはrr応答を受け取り次第パラメタを送ります。 いくつかの方法でタスクを実行するのを実装することができます。 そして、私たちの360が提供するオプションが賃仕事のレベルにおいてRJEである、マクロを付けてください。 私たちの好みがそうであるだろう、すぐにプログラム発行のパーティションの中で独立しているOSタスクを開始するマクロを付けてください、付いてください(おそらくFile Service)。 そのようなタスクは、通常、パラメタを開始に受け取って、その後、プログラムから事象制御ブロックなどの何らかのメカニズムでパラメタを受け取ることができます。 2番目のメソッドは実行されるプログラムへの特別な変更を必要とします。 したがって、それは望ましくはありません。 したがって、私たちは、実行コマンドにパラメタを含むのが必要であるつもりでない、またはパラメタが受信されるまで、実際に実行を始めるつもりではありません。

   8.  Upon abnormal termination, one should include part or all of the
   spurious request as well as an identify- ing code to facilitate
   precise error recognition.

8. 異常終了では、また、偽りの要求の部分かすべてを含むべきである、ingコードを特定して、正確な誤り認識を容易にしてください。

   9.  We would be interested in the outcome of the MIT/ Harvard
   experiments with the RFC #114 protocol.  What were the pitfalls,
   etc.?

9. 私たちはRFC#114プロトコルでMIT/ハーバードの実験の結果に興味を持っているでしょう。 落とし穴などは何でしたか?

         [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Simone Demmel 4/97 ]

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

Harslem & Haefner                                               [Page 2]

Harslem&Haefner[2ページ]