rfc430.txt

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


RFC 430            COMMENTS ON FILE TRANSFER PROTOCOL      FEBRUARY 1973


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

   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.

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

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

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

      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.

D. Site-Dependent FTP Parameters

   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.

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




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


   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.

   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:

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

      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.

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

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

      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.

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

      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.



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


      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.

   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.

   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.

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






















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


+-------++-------+-------+-------++-------+-------+-------++
| \ MODE||       |       |       ||       |       |       ||
|   \   ||STREAM | TEXT  | BLOCK ||STREAM | TEXT  | BLOCK ||
|TYPE \ ||       |       |       ||       |       |       ||
+-------++-------+-------+-------++-------+-------+-------++
|       ||       |       |       ||       |       |       ||
| ASCII ||       |       |       ||       |       |       ||
|       ||       |       |       ||       |       |       ||
+-------++-------+-------+-------++-------+-------+-------++
|       ||       |///////|       ||///////|///////|       ||
| IMAGE ||       |///////|       ||///////|///////|       ||
|       ||       |///////|       ||///////|///////|       ||
+-------++-------+-------+-------++-------+-------+-------++
| LOCAL ||       |///////|       ||///////|///////|       ||
| BYTE  ||       |///////|       ||///////|///////|       ||
|       ||       |///////|       ||///////|///////|       ||
+-------++-------+-------+-------++-------+-------+-------++
|       ||       |///////|       ||       |///////|       ||
| EBCDI ||       |///////|       ||       |///////|       ||
|       ||       |///////|       ||       |///////|       ||
+-------++-------+-------+-------++-------+-------+-------++
| ASCII/||///////|///////|///////||       |       |       ||
| ASA   ||///////|///////|///////||       |       |       ||
| VRC   ||///////|///////|///////||       |       |       ||
+-------++-------+-------+-------++-------+-------+-------++
|EBCDIC/||///////|///////|///////||       |///////|       ||
| ASA   ||///////|///////|///////||       |///////|       ||
| 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]











Braden                                                          [Page 8]