rfc430.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 452 行 · 第 1/2 页

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


                   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.

Miscellaneous Comments on FTP

   1. RFC 385, 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.

   2. RFC 385, P. 2 (5.)
      RFC 385, P. 3 (8.)
      RFC 414, 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".

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

      (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".




Braden                                                          [Page 1]

RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973


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

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

      (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.

   4. RFC 414, 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.

   5. RFC 354, P. 17, PASS Command

          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.

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

      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.

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

      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).

   8. RFC 354, P. 15, Restart

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






Braden                                                          [Page 2]

RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973


B. FTP Parameter Encoding

   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:

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

   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:

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

   Then the legal types according to RFC 385 would be:

         A
         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.



Braden                                                          [Page 3]

RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973


C. Server-Server Interaction

   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:

      (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.

      (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.

      (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.

   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.

   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




Braden                                                          [Page 4]