RFC327 日本語訳

Network Working Group                                         A. Bhushan
Request for Comments: 327                                        MIT-MAC
NIC: 9261                                                 April 27, 1972

Bhushanがコメントのために要求するワーキンググループA.をネットワークでつないでください: 327 MIT-Mac NIC: 9261 1972年4月27日

                 DATA AND FILE TRANSFER WORKSHOP NOTES

データとファイル転送ワークショップ注意

   On April 14 and 15, 1972, a Data and File Transfer Workshop was held
   at M.I.T., Cambridge, Mass.  A list of attendees of the meeting for
   April 14 and 15 is appended to the notes.  This note attempts to
   summarize most of the topics discussed and all of the decisions
   reached at the workshop meeting.

1972年4月14日と15日に、DataとFile Transfer Workshopはマサチューセッツ工科大学、ケンブリッジ、マサチューセッツ州で持たれていました。 4月14日と15日のミーティングの出席者のリストを注意に追加します。 この注意は、議論した話題の大部分とワークショップミーティングで達した決定のすべてをまとめるのを試みます。

   The following is a summary of the talks and discussions on April 14,
   1972.

↓これは、会談の概要と1972年4月14日に議論です。

   Steve Crooker discussed a general theory for Network protocols.
   Protocols transformations should have a unique inverse, and should be
   transitive.  Transformation to a standard form requires only 2n
   transformations (n = number of different types of hosts), as compared
   with n(n-1) transformations with no standard form.  A standard
   approach is preferable for n >= 3.

スティーブCrookerはNetworkプロトコルのために一般理論について議論しました。 プロトコル変換は、ユニークな逆を持つべきであり、遷移的であるべきです。 標準形式への変換は2n変換だけを必要とします(nは異なったタイプのホストの数と等しいです)、標準形式のないn(n-1)変換と比べて。 n>=3に、標準のアプローチは望ましいです。

   For file transfer, one could define a Network Virtual File Image.
   There was some discussion on whether it was possible to satisfy the
   above rules for file structure transformations.  No agreement was
   reached and the problem was abandoned for the present.

ファイル転送のために、人はNetwork Virtual File Imageを定義できました。 何らかの議論がファイル構造変換のための上の規則を満たすのが可能であったかどうかありました。 合意に達しないで、問題は当分捨てられました。

   Further discussion lead to the following formulation of the Workshop
   goals:

Workshop目標の以下の定式化へのさらなる議論リード:

   To come up with data and file transfer protocol/strategy that
   satisfies the needs of ARPANET users including Maxi-HOSTs, Mini-
   HOSTs, TIPs, Datacomputer, RJE, and Mailbox users.

データとファイル転送プロトコル/戦略を思いつくために、それはMaxi-HOSTs、Mini- HOSTs、TIPs、Datacomputer、RJE、およびMailboxユーザを含むアルパネットユーザの需要を満たします。

      Goals for the protocols/strategy were set as:

プロトコル/戦略の目標は以下として設定されました。

      1.  It should preserve the integrity of data.

1. それはデータの完全性を保持するべきです。

      2.  It should preserve the integrity of character representation
          and interpretation.

2. それは文字表示と解釈の保全を保持するべきです。

      3.  It should preserve the integrity of structural information, to
          the extent conveniently possible.

3. それは便利に可能な範囲として構造的な情報の保全を保持するべきです。

      4.  It should lead to the development of a Network Virtual File
          System.

4. それはNetwork Virtual File Systemの開発に通じるべきです。

Bhushan                                                         [Page 1]

RFC 327          Data and File Transfer Workshop Notes        April 1972

Bhushan[1ページ]RFC327データとファイル転送ワークショップ注意1972年4月

   Richard Winter discussed the Datacomputer application.  The
   Datacomputer though usable from terminals directly will not be
   engineered for direct terminal users, but for use by programs.  In
   Datalanguage a user can define data and file structure, and also how
   the file/data is to be transferred.  Using the data language it is
   possible to transfer entire files, or only the relevant parts of
   files.  The following is an example of file transfer as currently
   envisioned in the Datacomputer.

リチャードWinterはDatacomputerアプリケーションについて議論しました。 端末から使用可能ですが、Datacomputerはダイレクト端末ユーザのために直接設計されるのではなく、プログラムによる使用のために設計されます。データとファイル構造を定義して、また、Datalanguageでは、ユーザはファイル/データがどうわたるかことであることを定義できます。 データ言語を使用して、ファイル全体、またはファイルの関連部分だけを移すのは可能です。 ↓これはDatacomputerの現在思い描かれるとしてのファイル転送に関する例です。

          LOGIN  <user> <password>
          CREATE  <file name> <description>
          CREATE  <port name> <description>
          PORT  <port name> <external name>
          <file name> = <port name> (for transfer to Datacomputer)
          <port name> = <file name> (for transfer from Datacomputer)
          LOGOUT

<ファイル名前>(Datacomputerからの転送のための)LOGIN<ユーザ><パスワード>CREATE<ファイル名><記述>CREATE<ポート名前><記述>PORT<ポート名前><外部名><ファイル名>=<ポート名前>(Datacomputerへの転送のための)<ポート名前>=LOGOUT

   (CREATE statements are needed only when the description(s) required
   are not already on file at the Datacomputer.  A port description can
   specify a standard "external name", thus making a port statement
   optional also.  "External name" is to be a HOST-socket specification.
   The data transfer is to be in accordance with network data transfer
   standards.  The File and Port descriptions are to be in
   Datalanguage.)

(必要である記述がDatacomputerにファイルの上に既にないときだけ、CREATE声明が必要です。 ポート記述は標準の「外部名」を指定して、その結果、また、ポート声明を任意にすることができます。 「外部名」はHOST-ソケット仕様であることです。 データ転送はネットワークデータ転送規格に従ってあることです。 FileとPort記述はDatalanguageにあることです。)

   Alex McKenzie discussed the TIP user needs, describing the current
   capabilities and limitations of TIPs and TIP terminals.  TELNET
   format is the first choice of TIP users, followed by DTP using the
   indefinite bit stream mode.  There are two TIPs with magnetic tape
   systems which are capable of transferring data between them using the
   current DTP (RFC 264) in the descriptor count mode (utilizing
   sequence number option).

TIPsとTIP端末の現在の能力と限界について説明して、アレックス・マッケンジーはTIPユーザの必要性について議論しました。 TELNET形式は無期ビットストリームモードを使用することでDTPによって続かれたTIPユーザの最初の選択です。 記述子カウントモードで現在のDTP(RFC264)を使用することで(一連番号オプションを利用して)それらの間にデータを移すできる磁気テープシステムがある2TIPsがあります。

   Bob Braden discussed the RJS protocol and presented some data on RJS
   use.  NETRJS is 1% of CCN job load representing 2,000 jobs, 10,000
   sessions and 1,000 hours connect time in the last 5 months.  Average
   job input is of the order of 100,000 bits (400 cards), average job
   output is 700,000 bits (1,000 lines).  Large files have about 10
   million bits representing about 8-10 minutes of transmission time.
   The RJS protocol will be defined in a forthcoming document.

ボブ・ブレーデンは、RJSプロトコルについて議論して、RJS使用に関するいくつかのデータを提示しました。 NETRJSはここ5カ月で2,000の仕事、1万のセッション、および1,000時間の接続時間を表す1%のCCN仕事の荷重です。 平均した仕事の入力は10万ビット(400枚のカード)の注文のものであり、平均した仕事の出力は70万ビット(1,000の系列)です。 大きいファイルで、およそ1000万ビットはトランスミッション時間のおよそ8-10分を表します。 RJSプロトコルは今度のドキュメントで定義されるでしょう。

   Ray Tomlinson described the CPYNET system BBN is using to transfer
   files among TENEX systems.  CPYNET commands are ASCII strings with a
   fixed syntax.  The original connection is closed after a command is
   accepted, and data is transferred on a new connection using previous
   socket number, but with possibly a different byte size.  The data
   transfer rate achieved in CPYNET has been about 10 Kb/s.

レイ・トムリンスンはBBNがTENEXシステムにファイルを移すのに使用しているCPYNETシステムについて説明しました。CPYNETコマンドは固定構文があるASCIIストリングです。 コマンドを受け入れた後にオリジナルの接続が閉じて、データは、前のソケット番号を使用することで新しい接続に移しますが、ことによると異なったバイトサイズで移します。 CPYNETで達成されたデータ転送速度はおよそ10KB/sです。

Bhushan                                                         [Page 2]

RFC 327          Data and File Transfer Workshop Notes        April 1972

Bhushan[2ページ]RFC327データとファイル転送ワークショップ注意1972年4月

   Abhay Bhushan discussed the evaluation of network protocols and
   presented some preliminary measurement results.  The evaluation
   criteria for protocols should include speed (real time delay and
   transmission rate), efficiency (cpu time or cost), reliability (error
   rate and failure rate), convenience (ease of use and implementation),
   and usage (suitability for various application and user classes).

Abhay Bhushanはネットワーク・プロトコルの評価について議論して、いくつかの予備の測定結果を提示しました。 プロトコルのための評価基準は速度(リアルタイムの遅れと通信速度)、効率(cpu timeか費用)、信頼性(誤り率と故障率)、便利(使いやすさと実装)、および用法(様々なアプリケーションとユーザのクラスへの適合)を含むべきです。

   The parameters that affect speed and efficiency for given system
   conditions (fixed load, etc.) are:

与えられたシステム条件(固定負荷など)のための速度と効率に影響するパラメタは以下の通りです。

      1)  Byte size used for NCP connection.

1) サイズがNCP接続に使用したバイト。

      2)  Average message size used for transmission.

2) トランスミッションに使用されるメッセージサイズを平均してください。

      3)  Data format conversion (e.g., into Network ASCII, DTP Blocks,
          etc.).

3) データの形式変換(例えば、Network ASCII、DTP Blocksなどへの)。

      4)  Buffer size and I/O mode used (unit or block mode, etc.).

4) バッファサイズと入出力モードは(ユニットやブロックモードなど)を使用しました。

      5)  Other protocol constraints (acknowledge, error checking,
          connection procedure, etc.).

5) 他のプロトコル規制(誤りがチェックして、接続手順などを承認します)。

   There was some discussion as to how data and file transfer protocols
   may be altered to make transfer faster and more efficient by using
   optimum byte size and minimizing some of the constraints that impose
   a large overhead.

データとファイル転送プロトコルが最適なバイトサイズを使用して、大きいオーバーヘッドを課す規制のいくつかを最小にすることによって転送をより速くより効率的にするようにどう変更されるかもしれないかに関して何らかの議論がありました。

   The follow up discussions on DTP and FTP lead to a list of discussion
   and decision items for the next day.  The following is a summary of
   decisions reached on Saturday, April 15, 1972.

DTPとFTPについての議論が翌日議論と決定項目のリストに導く追跡。 ↓これは1972年4月15日土曜日に達した決定の概要です。

      1.  Separate connections are to be used for data and control
          information.

1. 別々の接続はデータと制御情報に使用されることになっています。

      2.  Control connection is to be a "TELNET" full-duplex connection
          (NVT-ASCII), established via the ICP.  Data connections are to
          be simplex connections established directly.

2. コントロール接続によるICPを通して確立された「telnet」全二重接続であることになっています(NVT-ASCII)。 データ接続による直接確立されたシンプレクス接続であることになっています。

      3.  The File Transfer and File System commands and their arguments
          shall be printable ASCII strings, instead of numeric codes, so
          that they are directly usable by a user at a terminal.  The
          interaction, however, will be optimized for usage by programs.
          (indirect use).

3. File Transfer、File Systemコマンド、および彼らの議論は印刷可能なASCIIストリングになるでしょう、数字コードの代わりに、それらが端末のユーザが直接使用可能であるように。 しかしながら、相互作用は用法のためにプログラム(間接的な使用)で最適化されるでしょう。

      4.  The byte size and user socket for data connection, data
          representation, and transfer mode to be used in file transfer
          may be chosen by a user via one or more commands requiring a
          positive or negative acknowledgment.

4. ファイル転送に使用されるべきデータ接続のためのバイトサイズとユーザソケット、データ表現、および転送モードは肯定しているか否定している承認を必要とする1つ以上のコマンドでユーザによって選ばれるかもしれません。

Bhushan                                                         [Page 3]

RFC 327          Data and File Transfer Workshop Notes        April 1972

Bhushan[3ページ]RFC327データとファイル転送ワークショップ注意1972年4月

      5.  The following data representations are to be accepted by all
          servers:

5. 以下のデータ表現はすべてのサーバで受け入れることです:

          1)  Network ASCII (7-bit ASCII in 8-bit field with 8th bit
              zero).

1) ASCII(8番目のビットゼロがある8ビットの分野の7ビットのASCII)をネットワークでつないでください。

          2)  Local Byte (a server option to store data in an efficient
              manner, the storage scheme should be well publicized).

2) 地方のByte(効率的な方法、ストレージ体系でデータを保存するサーバオプションはよくピーアールされるべきです)。

          3)  Image (a sequence of bits which should be stored
              contiguously independent of the byte size chosen for
              transfer).

3) イメージ(転送に選ばれたバイトサイズの如何にかかわらず近接して保存されるべきであるビットの系列)。

          4)  ASCII Print file (convert ASCII file to a form suitable
              for printing).

4) ASCII Printはファイルします(印刷に適したフォームにASCIIファイルを変換してください)。

          5)  EBCDIC Print file (convert EBCDIC file to a form suitable
              for printing).

5) EBCDIC Printはファイルします(転向者EBCDICは印刷に適したフォームにファイルします)。

      6.  Record structures are allowed but not mandatory.  A user with
          no record structure in his file should be able to store or
          retrieve his file at any host.  If a serving host cannot
          accept record structure, it must inform the user of the fact.
          Any record structure information in the data stream may
          subsequently be discarded.

6. 記録的な構造は、許容されていますが、義務的ではありません。 彼のファイルの記録的な構造のないユーザは、どんなホストでも彼のファイルを保存するべきであるか、または取ることができるべきです。 給仕のホストが記録的な構造を受け入れることができないなら、それは事実をユーザに知らせなければなりません。 データ・ストリームにおけるどんな記録的な構造情報も次に、捨てられるかもしれません。

      7.  The following data transfer modes are defined:

7. 以下のデータ転送モードは定義されます:

          1)  Byte-Stream - End of File indicated by closing connection.
              No record structure.

1) バイト流れてください--接続を終えることによって示されたFileの端。 記録的な構造がありません。

          2)  Block - File is series of blocks preceded by a count
              field.  Appropriate means provided to indicate end-of-
              file, end-of-record, and restart markers.

2) ブロック--ファイルはカウント分野が先行したブロックのシリーズです。 適切な手段は、終わりを示すのを前提としました。-ファイルでは、記録を終わらせてください、そして、マーカーを再出発してください。

          3)  ASCII - The file is network-ASCII, end-of-record, and
              end-of-file are indicated by a special "TELNET-control"
              character with 8th bit set to "one".

3) ASCII--ファイルはネットワークASCII、記録の終わり、およびファイルの終りが「1つ」に設定された8番目のビットで特別な「telnetコントロール」キャラクタによって示されるということです。

          4)  File is network-ASCII with an end-of-record defined by CR
              LF, and end-of-file by closing connection.

4) ファイルはCR LF、およびファイルの終りによって接続を終えることによって定義された記録の終わりでASCIIをネットワークでつなぎます。

          5)  Hasp compressed file with end-of-record and end-of-file
              information.

5) 記録の終わりとファイルの終り情報で圧縮されたファイルを掛け金で締めてください。

Bhushan                                                         [Page 4]

RFC 327          Data and File Transfer Workshop Notes        April 1972

Bhushan[4ページ]RFC327データとファイル転送ワークショップ注意1972年4月

      8.  A restart procedure will be provided to protect user from
          system failures (either host or process dying).  The issue of
          bits lost or scrambled is handled best at the NCP level.
          Standard error codes and responses will be provided for
          storage and I/O channel errors, at the FTP level.

8. システム障害からユーザを保護するために再開手順を提供するでしょう(死亡を接待するか、または処理してください)。 ビットの問題は損をしたか、スクランブルをかけられているのが、NCPレベルにおいて扱われた最善です。 ストレージとFTPレベルにおける入出力チャンネル誤りに標準誤差コードと応答を提供するでしょう。

          The restart procedure would require that the sender of data
          insert a special marker in the data stream (the marker has
          meaning only to the sender.  It could be bit-count, record
          count, or page count, etc.).  The receiver of data would mark
          the corresponding position of this marker in its own system,
          and return this information to the user.  In the event of a
          system failure, the user can restart the transfer by supplying
          this information with a restart command.

再開手順は、データの送付者が特別なマーカーをデータ・ストリームに挿入するのを必要とするでしょう。(マーカーは送付者だけに意味を持っています。 それは、ビットカウント、レコード・カウント、またはページ数であるかもしれませんなど。). データの受信機は、それ自身のシステム、およびリターンにおけるこのマーカーの対応する位置がこの情報であるとユーザにマークするでしょう。 システム障害の場合、ユーザは、再開コマンドをこの情報に供給することによって、転送を再開できます。

      9.  DTP is no longer a separate protocol but a set of transfer
          modes or format procedures whose use is defined by the file
          transfer protocol.

9. DTPはもう別々のプロトコルではなく、使用がファイル転送プロトコルによって定義される1セットの転送モードか書式手続きです。

      10.  Abhay Bhushan will write the workshop notes and the draft
          specifications for the new file transfer protocol.

10. Abhay Bhushanは新しいファイル転送プロトコルのためのワークショップ注意と草稿仕様を書くでしょう。

   LIST OF ATTENDEES, DATA AND FILE TRANSFER WORKSHOP

出席者、データ、およびファイル転送ワークショップのリスト

   Abhay Bhushan            MIT-MAC        April 14,15
   Bob Braden               UCLA-CCN       April 14,15
   Arvola Chan              MIT-MAC        April 14,15
   Steve Crocker            ARPA           April 14
   Eric Harslem             RAND           April 14
   John Heafner             RAND           April 14
   Chuck Holland            UCSD           April 14,15
   Alex McKenzie            BBN (NET)      April 14
   Bob Metcalfe             MIT-MAC        April 14
   Hal Murray               CCA            April 14
   Bill Plummer             BBN            April 14
   Jon Postel               UCLA           April 14
   Neal Ryan                MIT-MAC        April 14,15
   Marc Seriff              MIT-MAC        April 14,15
   Bob Thomas               BBN            April 14
   Ray Tomlinson            BBN            April 14
   Dick Watson              SRI-ARC        April 14,15
   Doug Wells               MIT-MAC        April 14
   Jim White                SRI-ARC        April 14,15
   Richard Winter           CCA            April 14,15

Abhay Bhushan MIT-MAC15年4月14日のボブブレーデンUCLA-CCN15年4月14日ArvolaチェンMIT-MAC15年4月14日スティーブ4月14日医者アルパエリックHarslemランドの4月14日ジョンHeafner RANDの4月14日チャックオランダUCSD4月14日;

        [This RFC was put into machine readable form for entry]
     [into the online RFC archives by H駘鈩e Morin, Viag駭ie 10/99]

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

Bhushan                                                         [Page 5]

Bhushan[5ページ]