RFC430 日本語訳

Network Working Group                                          R. Braden
Request for Comments: 430                                       CCN/UCLA
NIC: 13299                                               7 February 1973

コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 430CCN/UCLA NIC: 13299 1973年2月7日

                   COMMENTS ON FILE TRANSFER PROTOCOL

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

   On January 23, 1973, Jon Postel (NMC), Eric Harslem (RAND), Stephen
   Wolfe (CCN), and Robert Braden (CCN), held and informal meeting at
   UCLA on FTP.  This RFC generally reports the consensus of that
   meeting on the following issues: server-server transfers (ref.  RFC
   438 by Thomas and Clements); site-dependent information; and
   miscellaneous questions/disagreements with RFC 354, 385, and 414.
   There was also a discussion of the print file muddle, but that
   subject is addressed in a separate RFC, No. 448.

1973年1月23日に、ジョン・ポステル(NMC)(エリックHarslem(RAND)、スティーブン・ウルフ(CCN)、およびロバート・ブレーデン(CCN))は、成立しました。そして、FTPのUCLAの非公式会議。 一般に、このRFCは以下の問題に関してそのミーティングのコンセンサスを報告します: サーバサーバ転送(審判。 トーマスとクレメンツによるRFC438); サイト依存する情報。 そして、RFC354、385、および414との種々雑多な質問/不一致。 また、印刷ファイル混乱状態の議論がありましたが、その対象は別々のRFC(No.448)で扱われます。

Miscellaneous Comments on FTP

FTPの種々雑多なコメント

   1. RFC 385, P. 1 (3)

1. RFC385、P.1(3)

      The question of print files will be discussed at length in another
      RFC.  However, we did feel that the word "still" on the second
      line from the bottom of Page 1 is gratuitous.

十分別のRFCで印刷ファイルの問題について議論するでしょう。 しかしながら、私たちは、「まだ」1ページの下から2行目に関する単語が無料であると感じました。

   2. RFC 385, P. 2 (5.)
      RFC 385, P. 3 (8.)
      RFC 414, P. 4 (11.i)

2. RFC385、P.2(5) RFC385、P.3(8) RFC414、P.4(11.i)

      To the extent that we understand these items, they seem to be
      unnecessary and probably undesirable concessions to particular bad
      implementations ("hacks").  In reference to the second item, No. 8
      in RFC 385, one should note that in an asynchronous multi-process
      system like the ARPA Network, the phrase "immediately after" has
      little meaning.  An implementation which depends upon "immediately
      after" is erroneous and should be fixed.  If the protocol as
      defined has an intrinsic race condition, of course, the protocol
      should be fixed, but we don't believe such a problem exists.  It
      would help if definitions of command-response sequences in the FTP
      document were tightened up considerably.  As for the last item, we
      don't understand why Wayne Hathaway is so strongly opposed to
      "implied eor".

私たちがこれらの項目を理解して、不要であるように思えるという範囲とたぶん特定の悪い実装への望ましくない譲歩(「ハッキング」)に。 第2項目に関して、RFC385、1のNo.8は、アーパネットのような非同期なマルチプロセスシステムでは、句が「直後」ほとんど意味がないことに注意するべきです。 「直後」のときによる実装は、誤って、修理されるべきです。 もちろん、しかし、定義されるとしてのプロトコルに本質的な競合条件があるならプロトコルは修理されるべきですが、私たちは、そのような問題が存在すると信じていません。 FTPドキュメントとのコマンド応答系列の定義がかなり強化されるなら、それは助かるでしょうに。 最後の項目に関して、私たちは、ウェインハザウェイになぜ強く「暗示しているeor」にそれほど反対されるかを理解していません。

   3. RFC 354, P. 13, Format Definitions for Block Mode

3. RFC354(P.13)はブロックモードのための定義をフォーマットします。

      (a) The definition of the header length presumably is meant to be
          the "smallest integral number of bytes whose length is greater
          or equal to 24 bits".

(a) おそらく、ヘッダ長の定義は「長さが24ビットと、より優れているか、または等しい最もわずかな整数のバイト」であることが意味されます。

Braden                                                          [Page 1]

RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973

ブレーデン[1ページ]RFC430は1973年2月にファイル転送プロトコルを批評します。

      (b) The same definitional problem occurs for restart markers.

(b) 同じdefinitional問題は再開マーカーのために起こります。

      (c) Why does the restart marker have to be greater than 8 bits?

(c) 再開マーカーはなぜ8ビット以上でなければなりませんか?

      (d) Note that changing the Descriptor coding to bit flags would
          abolish the implied eor as well as the problem of RFC 385, P.
          2, #6.

(d) 旗をビットにコード化するDescriptorを変えるとRFC385の問題と同様に暗示しているeorが撤廃されることに注意してください、P.2、#6。

   4. RFC 414, P. 5 (11.iii)

4. RFC414、P.5(11.iii)

          Note that text mode is not possible for any EBCDIC coded file.
          Since EBCDIC is an 8-bit code, Telnet control characters
          (128-255) cannot be used to distinguish either eor or eof.
          Stream and block modes will work, however.  We have found the
          diagram on the last page to be useful for keeping track of the
          three-dimensional space of FTP parameters.

どんなEBCDICにも、テキストモードが可能でないというメモはファイルをコード化しました。 EBCDICが8ビットのコードであるので、eorかeofのどちらかを区別するのにTelnet制御文字(128-255)を使用できません。 流れてください。そうすれば、しかしながら、ブロックモードは利くでしょう。私たちは、終面のダイヤグラムがFTPパラメタの立体の動向をおさえることの役に立つのがわかりました。

   5. RFC 354, P. 17, PASS Command

5. RFC354(P.17)はコマンドに合格します。

          There is no mechanism within FTP for changing a password.  A
          user shouldn't have to use a different protocol (e.g., log
          into a time sharing system) to merely change his password.

パスワードを変えるためのFTPの中にメカニズムが全くありません。 ユーザは、単に彼のパスワードを変えるのに、異なったプロトコル(例えば、タイムシェアリングシステムにログインする)を使用する必要はないはずです。

   6. RFC 385, P. 3 (9.), TYPE Before BYTE

6. RFC385(P.3(9))はバイト前にタイプします。

      This admonition (to send TYPE before BYTE) should be clearly
      labeled as a recommended procedure for user FTP, not a restriction
      on a server FTP.

この訓戒(BYTEの前にTYPEを送る)はサーバFTPにおける制限ではなく、ユーザFTPのためのお勧めの手順として明確にラベルされるべきです。

   7. RFC 385, P. 2-3 (7) Order of 255 Reply

7. RFC385、255回答のP.2-3(7)注文

      Some of the participants felt (strongly) that the timing problem
      dealt with in this item is the result of bad NCP implementations
      and ought not be dignified in the protocol.  The issue here is the
      old, familiar, and touchy one of queueing RFC's or not. (My own
      view is that the protocol asymmetry forced by NCP's which can't
      queue RFC's is at least unaesthetic, and makes some elegant
      solutions impossible.  For examples, see RFC 414 and the comments
      below on server-server interaction, and RFC 438 on Reconnection
      Protocol).

関係者の中には、この項目で対処されたタイミング問題が悪いNCP実装の結果であると(強く)感じて、プロトコルで威厳をつけない人もいます。 ここの問題はRFCのものであるか否かに関係なく、待ち行列の古くて、身近で、扱いにくい1つです。 (私自身の視点はRFCのものを列に並ばせることができないNCPのもので無理矢理のプロトコル非対称で少なくとも「非-美的」であり、いくつかの上品なソリューションが不可能になるということです。 例に関しては、Reconnectionプロトコルのサーバサーバ相互作用、およびRFC438の以下のRFC414とコメントを見てください。).

   8. RFC 354, P. 15, Restart

8. RFC354(P.15)は再開します。

      Following a RESTart command, APPend and STORe presumably have
      identical meanings.

おそらく、RESTartコマンドに続いて、APPendとSTOReには同じ意味があります。

Braden                                                          [Page 2]

RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973

ブレーデン[2ページ]RFC430は1973年2月にファイル転送プロトコルを批評します。

B. FTP Parameter Encoding

B。 FTPパラメタコード化

   RFC 448, which discusses print files, points out that the print file
   attribute is logically independent of the character code attribute
   (ASCII vs. EBCDIC) in the type dimension; the set of allowable types
   in FTP is the outer product of the individual attributes.  Thus FTP
   has (at least) four character types, summarized by the following two
   x two matrix:

RFC448(印刷ファイルについて議論します)は、印刷ファイル属性がタイプの重要性におけるキャラクタコード属性(EBCDICに対するASCII)から論理的に独立していると指摘します。 FTPにおける許容できるタイプのセットは個々の属性の外側の製品です。 したがって、FTPには、以下の2x2マトリクスでまとめられた(少なくとも)の4つの字種があります:

                  |  ASCII  |   EBCDIC
   ---------------+---------+------------
   Not Print File |         |
   ---------------+---------+------------
   Print File     |         |
   ---------------+---------+------------

| ASCII| EBCDIC---------------+---------+------------ Not Printファイル| | ---------------+---------+------------ 印刷ファイル| | ---------------+---------+------------

   I propose that the encoding in the TYPE command model this
   interdependence of the types.  Instead of using a distinct single
   ASCII character for each type, we should use multiple ASCII
   characters---qualifiers, if you wish.  For example:

私は、TYPEコマンドにおけるコード化がタイプのこの相互依存をモデル化するよう提案します。 各タイプに異なった単独のASCII文字を使用することの代わりに、私たちは複数のASCII文字を使用するべきです。---資格を与える人は願ってください。 例えば:

         A represents ASCII code
         E represents EBCDIC code
         P represents print file
         I represents image
         L represents local byte

Aが表す、ASCIIコードEがPが表すEBCDICコードを表す、印刷ファイルIが地方でLが表すイメージを表す、バイト

   Then the legal types according to RFC 385 would be:

そして、RFC385に従った法的なタイプは以下の通りでしょう。

         A
         AP
         E
         EP
         I
         L

AP E EP I L

   Note that the attributes under consideration here are type-like; they
   are not (logically) concerned with the structure or the transmission
   mode, only the internal encoding of the file.

ここでの考慮での属性がタイプのようであることに注意してください。 それらはファイルの構造か転送方式、内部のコード化だけに(論理的に)関係がありません。

   At present, this would be a trivial change.  However, I foresee the
   file transfer protocol expanding significantly over the next several
   years as new types are added.  Some servers will want to add server-
   specific type variations, and the NWG will want to add some.  How
   about an APL character set?  Or the multiple-overlay 256 character
   ASCII which has been proposed?  Multiple qualifiers (and later
   perhaps more structure) in the type seems to be the cleanest escape
   mechanism for future growth.

現在のところ、これは些細な変化でしょう。 しかしながら、新しいタイプが加えられるとき、私は次の数年間ファイル転送プロトコルの広げることについてかなり見通します。 いくつかのサーバがサーバ特定のタイプ変化を加えたくなるでしょう、そして、NWGはいくつかを加えたくなるでしょう。 APL文字集合はどうですか? 提案された複数のオーバレイ256キャラクタASCII-- そして、複数の資格を与える人、(その後、恐らくより多くの構造) タイプが思える中でものである最も清潔であるコネは今後の成長のためにメカニズムから逃げます。

Braden                                                          [Page 3]

RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973

ブレーデン[3ページ]RFC430は1973年2月にファイル転送プロトコルを批評します。

C. Server-Server Interaction

C。 サーバサーバ相互作用

   The FTP changes proposed by Thomas and Clements in RFC 438 are a
   particular solution to a general problem inherent in the current
   host-host protocol and higher-level protocols like FTP.  There seems
   to be a need for a secure and simple way for two (server) processes
   in different hosts to exchange socket names (i.e., 40-bit numbers) so
   they can subsequently exchange RFC's and establish a connection.
   Current second-level (host-host) protocol provides exactly one
   (secure) mechanism by which one host can learn a socket name of a
   process at another host in order to establish a connection: ICP.  The
   ICP mechanism by itself is not adequate for server-server connection
   in FTP.  Therefore, Thomas and Clements have proposed an extension to
   the FTP protocol, roughly as follows:

RFC438でトーマスとクレメンツによって提案されたFTP変化はFTPのように現在のホスト兼ホストプロトコルと上位レベル・プロトコルの固有である一般的問題の特殊解です。 異なったホストの2つの(サーバ)プロセスが次に、RFCのものを交換して、取引関係を築くことができるように、ソケット名(すなわち、40ビットの数)を交換する安全で簡単な方法の必要性はあるように思えます。 第2現在のレベル(ホスト兼ホスト)プロトコルはまさにホストが取引関係を築くために別のホストでプロセスのソケット名を学ぶことができる1つの(安全)のメカニズムを提供します: ICP。 FTPにおけるサーバサーバ接続には、それ自体でICPメカニズムは適切ではありません。 したがって、トーマスとクレメンツは以下の通りおよそFTPプロトコルに拡大を提案しました:

      (1) A controller ("user") process at Host A uses ICP to invoke and
          establish Telnet control connections to two automata
          ("server") processes at two other hosts.  An automaton process
          invoked in this manner then executes controller commands sent
          in a standard command language over the Telnet control
          connection.

(1) Host Aのコントローラ(「ユーザ」)プロセスは、他の2人のホストで2つのオートマトン(「サーバ」)プロセスにTelnetコントロール接続を呼び出して、証明するのにICPを使用します。 その時この様に呼び出されたオートマトンプロセスはTelnetコントロール接続の上で標準のコマンド言語で送られたコントローラコマンドを実行します。

      (2) The controller process commands each automaton to reserve a
          suitable data transfer socket and to return the socket name to
          the controller over the control connection.  An automaton
          presumably negotiates with his own NCP in a host-dependent
          manner to obtain the socket reservation.

(2) コントローラプロセスは、各オートマトンが適当なデータ転送ソケットを予約して、コントロール接続の上でソケット名をコントローラに返すと命令します。 おそらく、オートマトンはソケットの予約を得るホスト依存する方法で彼自身のNCPと交渉します。

      (3) The controller now knows both data transfer socket names; he
          will send them in subsequent commands to the automata so each
          automaton will know the foreign socket name to which he is to
          connect.  Later commands cause the automata to issue RFC's and
          open the data connection as needed.

(3) コントローラは今、両方のデータ転送ソケット名を知っています。 彼がその後のコマンドでそれらをオートマトンに送るので、各オートマトンは彼が接続することになっている外国ソケット名を知るでしょう。 後のコマンドは、オートマトンが必要に応じてRFCのものを発行して、データ接続を開くことを引き起こします。

   This appears to be useful general model for process-process
   interaction over the Network.  Personally, I believe this symmetrical
   model should be the basis of all FTP the controller and one of the
   automata could be in the same host.  Then the user/server problem
   (for any pair of hosts to transfer files, one must have a server FTP
   and the other a user FTP) would vanish.  At least one host somewhere
   in the Network would need a controller process; all other hosts would
   need only an automaton process.

これはNetworkの上のプロセスプロセス相互作用のための役に立つ一般的なモデルであるように見えます。 個人的に、私はすべてのFTPの基礎がコントローラであったならこの対称のモデルを信じています、そして、オートマトンの1つが同じホストにあるかもしれません。 そして、ユーザ/サーバ問題(ホストのどんな組もファイルを移すように、サーバFTPを持たなければなりません、そして、もう片方には、ユーザFTPがある)は消え失せるでしょう。 Networkのどこかの少なくとも1人のホストがコントローラプロセスを必要とするでしょう。 他のすべてのホストがオートマトンプロセスだけを必要とするでしょう。

   Perhaps at a future time the NWG should consider whether a socket-
   reservation-and-passing mechanism ought to be incorporated into
   second-level protocol rather than duplicated in a number of third-
   level protocols.  We should note that this model provides secure

恐らくNWGがソケット予約と通過メカニズムが第2レベルに法人組織であるべきであるかどうか考えるはずである将来の時に、多くの第3レベルにコピーするよりむしろプロトコルについて議定書の中で述べてください。 私たちは、このモデルが安全な状態で提供することに注意するべきです。

Braden                                                          [Page 4]

RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973

ブレーデン[4ページ]RFC430は1973年2月にファイル転送プロトコルを批評します。

   sockets only if both user and server processes "release" the socket
   reservations when the Telnet control connection breaks.  The same
   problem seems to occur with Thomas' Reconnection Protocol (426).

ソケットはユーザとサーバプロセスの両方である場合にだけTelnetコントロール接続が中断しているとソケットの予約を「リリースします」。 同じ問題はトーマスのReconnectionプロトコル(426)で起こるように思えます。

   In any case, for the present we would endorse the general third-level
   model of RFC 438.  However, we would propose a slightly different,
   and more symmetrical, approach.

どのような場合でも、そして、当分、私たちはRFC438の一般的な第3レベルモデルについて宣伝するでしょう。 しかしながら、私たちはわずかに異なって、より対称のアプローチを提案するでしょう。

      1. The requirement in FTP that the FTP user listen on the data
         socket before issuing a data transfer command should be
         removed.  The beauty of host-host protocol is that it doesn't
         matter which host sends the first RFC, as long as they both
         send matching RFC's "eventually".  (Timeouts, of course, are
         annoying, but I believe they are workable and ultimately
         unavoidable); queueing RFC's is also necessary).

1. データ転送コマンドを発行する前にFTPユーザがデータソケットの上に聴くFTPにおける要件は取り除かれるべきです。 ホスト兼ホストプロトコルの美はどのホストが最初のRFCを送るかが重要でないということです、それらの両方が「結局」合っているRFCのものを送る限り。 (タイムアウトはもちろん煩わしいのですが、私は、それらが実行可能であって、結局避けられないと信じています)。 また、待ち行列RFCのものも必要である、)

      2. We propose, instead of LSTN, a new command GETSocket.  The
         controller (i.e., user FTP) process would send a GETSocket to
         each automaton, probably after a successful login.  Upon
         receiving GETSocket, an automaton would assign a (send,
         receive) pair of data transfer sockets and return the numbers
         over the Telnet connection. (Alternatively, FTP could specify
         that a (send, receive) pair of sockets always be assigned when
         the server is first entered, and the numbers returned to the
         user process via unsolicited 255 replies).

2. 私たちはLSTNの代わりに新しいコマンドGETSocketを提案します。 コントローラ(すなわち、ユーザFTP)プロセスはたぶんうまくいっているログインの後に各オートマトンにGETSocketを送るでしょう。 GETSocketを受けると、オートマトンは、データ転送ソケットの(発信してください、そして、受信してください)組を選任して、Telnet接続の上に数を返すでしょう。 (サーバが最初に、入れられて、求められていない255の回答で数がユーザ・プロセスに戻ったとき、あるいはまた、FTPは、ソケットの(発信してください、そして、受信してください)組がいつも選任されると指定するかもしれません。)

      3. Then the user process would send the socket numbers to the
         opposite hosts by sending SOCK commands to both.

3. そして、ユーザ・プロセスは、両方へのコマンドをSOCKに送ることによって、ソケット番号を反対のホストに送るでしょう。

      4. When it receives a data transfer command, the automaton
         (server) process would issue an RFC containing the two socket
         numbers.  When both servers are fired up, RFC's are exchanged
         and data transfer starts.

4. データ転送コマンドを受け取るとき、オートマトン(サーバ)プロセスは2つのソケット番号を含むRFCを発行するでしょう。 両方のサーバを起動するとき、RFCのものを交換します、そして、データ転送は始まります。

D. Site-Dependent FTP Parameters

D。 サイト依存するFTPパラメタ

   Some hosts will have a problem with the current FTP because their
   file system needs additional host-specific parameters in certain
   cases.  As an example, the IBM operating systems tend to give the
   programmer a number of options on the logical and physical mapping of
   a file onto the disk.

彼らのファイルシステムがある場合には追加ホスト特有のパラメタを必要とするので、何人かのホストには、現在のFTPに関する問題があるでしょう。 例として、IBMオペレーティングシステムは、ディスクへのファイルの論理的で物理的なマッピングにおける多くのオプションをプログラマに与える傾向があります。

   This is true both of TSS/360 (see Wayne Hathaway's discussion of his
   STOR command implementation, Page 5 of RFC 418), and OS/360.  The
   large set of options and parameters to the OS/360 file system is, in
   fact, the (legitimate) origin of most complaints about OS Job Control
   Language (JCL).

これはTSS/360(彼のSTORコマンド実装に関するウェインハザウェイの議論を見てください、5RFCページ418)、およびOS/360に関して本当です。 事実上、OS/360ファイルシステムへの大きいセットのオプションとパラメタはOS Job Control Language(JCL)に関するほとんどの苦情の(正統)の発生源です。

Braden                                                          [Page 5]

RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973

ブレーデン[5ページ]RFC430は1973年2月にファイル転送プロトコルを批評します。

   If the FTP user merely wants to store data without using it at one of
   these sites, he has no problem; defaults can be chosen to handle any
   reasonable FTP request.  However, the FTP user who sends a file to an
   IBM/360 for use there may need to specify local file system
   parameters which are not derivable from any of the existing FTP
   commands.

FTPユーザが単にこれらのサイトの1つでそれを使用しないでデータを保存したいなら、彼には、問題が全くありません。 どんな合理的なFTP要求も扱うためにデフォルトを選ぶことができます。 しかしながら、使用のためにそこでIBM/360にファイルを送るFTPユーザは、既存のFTPコマンドのいずれによっても誘導できないローカルファイルシステム・パラメータを指定する必要があるかもしれません。

   In designing an FTP server implementation for CCN, for example, we
   first tried to handle the mapping problem by choosing a (possibly
   different) default mapping for each combination of FTP parameters--
   type, mode, and structure.  We hoped that if a user chose
   "reasonable" or "suitable" FTP parameters for a particular case
   (e.g., "ASCII, stream, record" for source programs, and "image,
   block, record" for load modules), then the right OS/360 file mapping
   would result.  We were forced to abandon this approach, however,
   because of the following arguments:

CCNのためにFTPサーバ実装を設計する際に、例えば、私たちは最初に、FTPパラメタの各組み合わせのための(ことによると異なる)のデフォルトマッピングを選ぶことによって、マッピング問題を扱おうとしました--タイプ、モード、および構造。 ユーザが特定のケースのための「妥当である」か「適当な」FTPパラメタを選んだなら(例えば、原始プログラム、ロードモジュールのために「イメージ、ブロックは記録すること」に関して「ASCII、流れてください、記録的です」、)正しいOS/360ファイルマッピングが結果として生じることを願っていました。 しかしながら、私たちは以下の議論のためにやむを得ずこのアプローチを捨てました:

      1. Some user FTP's probably may not implement all FTP
         type/mode/structure combinations (though they ought to!).

1. ユーザFTPの何らかのものは、たぶんすべてのFTPタイプ/モード/構造が組み合わせであると実装しないかもしれません(そうするべきですが!)。

      2. Some user FTP's may not give the user full or convenient
         control over his type/mode/structure.  Indeed, the mode should
         be chosen on grounds of efficiency, not end use.

2. FTPの何らかのユーザものは彼のタイプ/モード/構造のユーザの完全であるか便利な支配力を与えないかもしれません。 本当に、モードは最終用途ではなく、効率の理由で選ばれるべきです。

      3. There weren't enough logically distinct combinations of FTP
         parameters.

3. FTPパラメタの論理的に異なった組み合わせが十分ありませんでした。

      4. The result would have been a set of hard-to-remember rules for
         sending files to CCN for use here.

4. 結果は、使用のためにここでファイルをCCNに送るための覚えていにくい1セットの規則だったでしょう。

      5. Some common cases require non-invertible transformations on the
         data.  For example, most IBM language processors (i.e.,
         compilers) accept only fixed length records of (surprise!) 80
         bytes each, i.e., literal card images.  Such ugly (and
         logically unnecessary) implementation stupidities in OS/360 are
         a fact of life.  Now if a FTP user innocently sent a data file
         to CCN with the particular type/mode combination which
         defaulted to card images, he would find his records truncated
         to 80 bytes.  That would be downright unfriendly.

5. いくつかのよくある例がデータで非可逆変換を必要とします。 例えば、ほとんどのIBM言語プロセッサ(すなわち、コンパイラ)が(驚き!)の固定長レコードだけを受け入れます。 すなわち、それぞれ80バイト、文字通りのカードイメージ。 OS/360におけるそのような醜くて(論理的に不要)の実装蒙昧は現実です。 今、FTPユーザがカードイメージをデフォルトとした特定のタイプ/モード組み合わせと共にデータファイルをCCNに無邪気に送るなら、彼は80バイトに先端を切られた記録を見つけるでしょうに。 それは全く無愛想でしょう。

   Thus, the CCN server FTP would have to choose between being useful or
   being friendly.  We decided upon the following strategy:

したがって、CCNサーバFTPは役に立って、好意的であるときに選ばれなければならないでしょう。 私たちは以下の戦略に決めました:

      1. The defaults will be friendly; we will accept any FTP
         type/mode/structure and store it invertibly (except print
         files).  However, the user who uses only these defaults will
         probably find he has to later run a utility under TSO to
         reformat the data.

1. デフォルトは好意的になるでしょう。 私たちは、どんなFTPタイプ/モード/構造も受け入れて、invertibly(印刷ファイルを除いて)にそれを保存するつもりです。 しかしながら、これらのデフォルトだけを使用するユーザはたぶん後でTSOの下でユーティリティを再フォーマットに実行するために持っている掘り出し物にデータを望んでいます。

Braden                                                          [Page 6]

RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973

ブレーデン[6ページ]RFC430は1973年2月にファイル転送プロトコルを批評します。

      2. We will provide some mnmonic keywords associated with STOR
         commands to choose the proper disk mapping.  For example, if he
         wants to STORe a Fortran source file for compilation at CCN,
         the user will need only to specify "SOURCE" or "FORT" to get
         reasonable and workable OS/360 file system parameters.  In
         addition, we will provide fairly complete "DD" parameters for
         the sophisticated user.  The syntax and semantics of these
         keywords and parameters will be as close as possible to the
         corresponding TSO commands.  Full details will be published as
         soon as the implementation is working.

2. 私たちは適切なディスクマッピングを選ぶSTORコマンドに関連しているいくつかのmnmonicキーワードを提供するつもりです。 例えば、彼がCCNの編集のためのFortranソースファイルがSTOReに欲しいなら、ユーザは、OS/360の妥当で実行可能なファイルシステム・パラメータを得るために単に「ソース」か「とりで」を指定する必要があるでしょう。 さらに、私たちは完全な"DD"パラメタを洗練されたユーザに公正に提供するつもりです。 これらのキーワードとパラメタの構文と意味論ができるだけ対応するTSOコマンドの近くにあるでしょう。 実装が働いているとすぐに、一部始終は発行されるでしょう。

   All of this discussion leads to a general protocol question: how
   should such host-dependent information appear within FTP? Hathaway
   used the ALLO command (see RFC 418, P. 6).  CCN, on the other hand,
   feels that such information belongs in the only part of FTP syntax
   which is already host-dependent: the pathname.  So CCN plans to allow
   a "generalized" pathname in a STOR command, a (full or partial) file
   name optionally followed by one or keywords or keyword parameters
   separated by commas.

この議論のすべてが一般的なプロトコル質問に通じます: そのようなホスト依存する情報はFTPの中にどのように現れるべきですか? ハザウェイはALLOコマンドを使用しました。(RFC418、P.6を見てください。). 他方では、CCNは、FTP構文の唯一のホスト既に依存する部分にはそのような情報があると感じます: パス名。 それで、CCNは、STORコマンドにおける「一般化された」パス名を許容するのを計画しています、と(完全であるか部分的)のファイル名はコンマによって切り離された1、キーワードまたはキーワード・パラメータで任意に続きました。

   A third possible solution might be for the user to precede his STORe
   command by a server-dependent data set creation command, using
   Hathaway's proposed SRVR command.  The data set creation command
   could then have all the parameters necessary for the server file
   system.  CCN might change to this approach if SRVR is adopted and if
   people find the generalized pathname objectionable or unworkable.

3番目の可能なソリューションはサーバ依存するデータセット作成コマンドでユーザが彼のSTOReコマンドに先行することであるかもしれません、ハザウェイの提案されたSRVRコマンドを使用して。 そして、データセット作成コマンドで、すべてのパラメタがサーバファイルシステムに必要になるかもしれません。 CCNは、人々がSRVRが採用されるかどうかと、一般化されたパス名が好ましくないのがわかるか、または「非-実行可能」するかをこのアプローチに変えるかもしれません。

   For another interesting example of host-dependent problems, see
   Hathaway's discussion of his DELE command in RFC 418 (pp.6-7).

ホスト依存する問題の別のおもしろい例に関しては、RFC418(pp.6-7)での彼のDELEコマンドに関するハザウェイの議論を見てください。

Braden                                                          [Page 7]

RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973

ブレーデン[7ページ]RFC430は1973年2月にファイル転送プロトコルを批評します。

+-------++-------+-------+-------++-------+-------+-------++
| \ MODE||       |       |       ||       |       |       ||
|   \   ||STREAM | TEXT  | BLOCK ||STREAM | TEXT  | BLOCK ||
|TYPE \ ||       |       |       ||       |       |       ||
+-------++-------+-------+-------++-------+-------+-------++
|       ||       |       |       ||       |       |       ||
| ASCII ||       |       |       ||       |       |       ||
|       ||       |       |       ||       |       |       ||
+-------++-------+-------+-------++-------+-------+-------++
|       ||       |///////|       ||///////|///////|       ||
| IMAGE ||       |///////|       ||///////|///////|       ||
|       ||       |///////|       ||///////|///////|       ||
+-------++-------+-------+-------++-------+-------+-------++
| LOCAL ||       |///////|       ||///////|///////|       ||
| BYTE  ||       |///////|       ||///////|///////|       ||
|       ||       |///////|       ||///////|///////|       ||
+-------++-------+-------+-------++-------+-------+-------++
|       ||       |///////|       ||       |///////|       ||
| EBCDI ||       |///////|       ||       |///////|       ||
|       ||       |///////|       ||       |///////|       ||
+-------++-------+-------+-------++-------+-------+-------++
| ASCII/||///////|///////|///////||       |       |       ||
| ASA   ||///////|///////|///////||       |       |       ||
| VRC   ||///////|///////|///////||       |       |       ||
+-------++-------+-------+-------++-------+-------+-------++
|EBCDIC/||///////|///////|///////||       |///////|       ||
| ASA   ||///////|///////|///////||       |///////|       ||
| VRC   ||///////|///////|///////||       |///////|       ||
|       ||///////|///////|///////||       |///////|       ||
+-------++-------+-------+-------++-------+-------+-------++

+-------++-------+-------+-------++-------+-------+-------++ | \モード|| | | || | | || | \ ||ストリーム| テキスト| ブロック||ストリーム| テキスト| ブロック|| |\をタイプしてください。|| | | || | | || +-------++-------+-------+-------++-------+-------+-------++ | || | | || | | || | ASCII|| | | || | | || | || | | || | | || +-------++-------+-------+-------++-------+-------+-------++ | || |///////| ||///////|///////| || | イメージ|| |///////| ||///////|///////| || | || |///////| ||///////|///////| || +-------++-------+-------+-------++-------+-------+-------++ | ローカル|| |///////| ||///////|///////| || | バイト|| |///////| ||///////|///////| || | || |///////| ||///////|///////| || +-------++-------+-------+-------++-------+-------+-------++ | || |///////| || |///////| || | EBCDI|| |///////| || |///////| || | || |///////| || |///////| || +-------++-------+-------+-------++-------+-------+-------++ | ASCII/||///////|///////|///////|| | | || | アサ||///////|///////|///////|| | | || | VRC||///////|///////|///////|| | | || +-------++-------+-------+-------++-------+-------+-------++ |EBCDIC/||///////|///////|///////|| |///////| || | アサ||///////|///////|///////|| |///////| || | VRC||///////|///////|///////|| |///////| || | ||///////|///////|///////|| |///////| || +-------++-------+-------+-------++-------+-------+-------++

 KEY:
 +---+
 |///| Excluded
 +---+  case

キー: +---+ |///| +を除きます。---+ ケース

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

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

Braden                                                          [Page 8]

ブレーデン[8ページ]