rfc310.txt

RFC技术文档 从0000－05

   facility with Datalanguage as its command language.  From the
   viewpoint of Datacomputer as an FTP server, FTP commands be a subset
   of the Datalanguage.  It is therefore desirable that FTP commands be
   printable ASCII strings instead of numeric codes.

Remote Job Service Requirements

   Initially two separate protocols were proposed for Remote Job Service
   (RJS).  One was the NETRJS protocol (see ref 6) for remote job
   service from large Hosts and the other was the NETRJT Protocol (see
   ref 7) for remote job service from TIPs (and other mini-Hosts).  The
   current thinking however, is to move towards a single RJS with "as
   much overlap as possible between the methods of dealing with these
   two user populations."  (See ref 8.)  Perhaps inclusion of ASCII
   within DTP would make this feasible.

   The existing proposals for DTP and FTP have been considered somewhat
   less than optimal for RJS needs.  Specific drawbacks of DTP and FTP
   have been pointed out in the handling of data structures and data
   types.  Most of these problems seem relatively easy to resolve.  It
   would involve making Network ASCII the default data type (acceptable
   to all hosts) and providing a way in FTP for proposing and rejecting
   alternative data types and data structures.




Bhushan                                                         [Page 4]

RFC 310               Another Look At Data And FTP            April 1972


   Another inadequacy of FTP (which pertains to other applications as
   well) is in the area of error recovery.  Currently there is no way to
   "restart" transmission if an element in the transmission path fails.
   One solution suggested has involved the use of sequence number (see
   ref 9).  A number of other solutions exist to the problem.  These are
   discussed later in the section 'FTP Reconsidered'.

DTP Reconsidered

   The aspiration for DTP was that it would provide a uniform mechanism
   for separating information into its logical structure (records,
   files, and control), and rudimentary error control.  The evaluation
   of DTP and its modes should be on the basis of speed (real-time),
   efficiency (processing cost), reliability (error control and
   recovery), and the ease of its use.

   It is now clear that unless DTP was significantly revised, the TIP
   and other mini-Host user would find it difficult to use services
   based on use of DTP.  Allowing the use of ASCII within DTP, and using
   defaults instead of the "modes available" handshake, would alleviate
   this problem, but compromise the DTP error control function.  Whether
   error control belongs at the DTP level or at a higher level needs
   further discussion.

   DTP, in its present form, does not provide sufficient error control
   and recovery procedures.  To make DTP more useful, either it should
   be simplified (at least from a user viewpoint), or it should be
   extended to include better error control with built in error
   recovery, and possible handling of data types and data structures.

   In the simplified version, DTP would only be a format procedure in
   which data could be transmitted as ASCII (no format) with escape to
   an 8-bit transparent (indefinite bit-stream) mode or in data blocks
   (descriptor and count mode).  The choice of which mode to use, and
   all error control, error recovery, and aborts would be handled by the
   higher-level protocol.

   The utility of the block mode in data transfer has been questioned by
   many who suggest that it puts a large overhead for providing the
   simple function of indicating end-of-file, and separating data and
   control information.  The alternative data transfer strategy is to
   use separate connections for control and data information and/or
   close and reopen connections.  This causes an overhead of a different
   sort, but has the advantage that the byte size for connection may be
   chosen to optimize data transfer.






Bhushan                                                         [Page 5]

RFC 310               Another Look At Data And FTP            April 1972


   A drawback of present DTP is that it is geared to transfer of 8-bit
   bytes.  Perhaps a good strategy for data transfer would be to allow
   sending data in an agreed upon transfer mode.  The transfer mode
   chosen should determine the byte size for connection, the data type
   chosen, and any data structure information.  This mode may be chosen
   at the DTP level, or at the using protocol level.

FTP Reconsidered

   The aspiration for FTP was that it would facilitate file management
   and file transfer in the ARPANET Virtual File System.  FTP success
   should be evaluated by the extent of its use, convenience and
   efficiency in its use, and its suitability for other applications
   such as Datacomputer, RJS, and Mail.

   Wide use of FTP would be possible if a user could use an FTP-server
   directly without the help of a mediating DTP/FTP-User process.  This
   would require that commands be ASCII strings instead of numeric
   codes, and that ASCII characters be an acceptable input.  Such a
   change in FTP would greatly increase its acceptance at the cost of
   making the server-implementation more complex.  Combined
   implementation, however, would be simplified as the mediating FTP-
   user process (if used at all) would be simplified.

   Efficiency of transfer is an important factor affecting the
   usefulness of FTP.  File transfer may be very expensive (in terms of
   CPU time) and slow (in real-time) if an inappropriate transfer
   strategy is used (e.g., inappropriate byte size).  Every attempt
   should be made to optimize transfer of data.  A good strategy may be
   to allow transfer of files over a separate connection or close and
   reopen connections (using perhaps a different byte size).  A problem
   with indicating end-of-file by closing connection is that is
   uncertain if the connection was closed because end-of-file was
   reached, or because of a failure or error condition.  Perhaps "NCP
   interrupts" could be used in addition to a "close" to indicate
   definite end-of-file condition.

   A drawback in the present FTP strategy is that it has no restart
   procedure.  One proposal for restart has involved the use of the
   sequence numbers used in DTP block mode.  Our feeling is that perhaps
   restart may best be accomplished by incorporating a command in FTP
   that allows a user to specify the place in file where to begin
   retransmission.  A possible solution is to use the "SPF" command
   implemented in the UCSB Simple-Minded File System (see ref 10).
   Another solution may be to have optional arguments for retrieve and
   store commands that allow selective retrieval and replacement
   (specified by bits, character, words, lines, pages or segments).




Bhushan                                                         [Page 6]

RFC 310               Another Look At Data And FTP            April 1972


   Another useful addition to FTP would be a protocol procedure between
   user and server to agree to data type, data structure, and mode for
   file transfer.  This would enable the user and server to reach the
   optimum file transfer strategy acceptable to both.

Concluding Remarks

   We have discussed in this paper what we see as the major problem
   areas in the present DTP and FTP specifications.  We hope this
   discussion will stimulate thinking, so that we can arrive at revised
   specifications for DTP and FTP that satisfy all the diverse needs in
   an elegant manner.

REFERENCES

      1. The Data Transfer Protocol, Bhushan, et al, NWG/RFC #264, NIC
   #7212.

      2. The File Transfer Protocol, Bhushan, et al, NWG/RFC #265, NIC
   #7213.

      3. Data and File Transfer Workshop Announcement, A. Bhushan,
   NWG/RFC #309, NIC #9260.

      4. The Terminal IMP for the ARPA Compuer Network, Ornstein, et al,
   SJCC, 1972, NIC #8218.

      5. Datalanguage, Computer Operation of America, Datacomputer
   Project, Working Paper No.3, October 29, 1971, NIC #8208.

      6. Interim NETRJS Specifications, R. T. Braden, NWG/RFC #189, NIC
   #7133.

      7. NETRJT - - Remote Job Service Protocol for TIPs, R. T. Braden,
   NWG/RFC #283, NIC #8165.

      8. RJS Protocol Meeting Notes, 25 February 1972, A. McKenzie
   (limited distribution).

      9. A Suggested Addition to File Transfer Protocol, A. McKenzie,
   NWG/RFC #281, NIC #8163.

      10. Network Specifications for UCSB's Simple-Minded Files System,
   James E. White, NWG/RFC #122, NIC #5834

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




Bhushan                                                         [Page 7]