Movatterモバイル変換

Network Working Group                           Bob BresslerRFC #486                                        BBNNIC #15064                                      20 March 1973Data Transfer Revisited    A lot of work has recently gone into the development and refinementof both the RJE and FTP protocols.  Stepping back from the details andsmall issues, we can describe the two protocols as 1) a controlconnection over which commands are passed, and 2) a data connection overwhich uninterpreted (by the server process) data is passed.  Bothprotocols deal with the concept of identifying oneself to the server,setting up parameters, and transferring some data.    New ideas and concepts, such as the "hot card reader", have beenintroduced into one protocol or the other, but these concepts aregenerally applicable to both.  In addition, a great deal of effort wasmade to make the structures of the two protocols be as similar aspossible.    This discussion is, of course, leading to the suggestion that westop considering these as two separate protocols, and merge them into asingle unit - perhaps resurrecting the name of "data transfer".    Several advantages besides simplicity are gained by this.  Sitesneed only build one server program - given that they can always respondwith "command not implemented".  This will also prevent the RJE usersand servers from having to start up a (possibly) separate FTP user andserver - saving the resulting doubling of programs and Telnetconnections.    The further advantage of insuring that new ideas and concepts willbe shared by all users and servers will also be realized.  A RJE userwill be able to transfer his deck of cards (file) to storage on anothermachine's file system using the "hot card reader" previously definedonly in the RJE protocol.    The command set of the combined protocol would now consist ofseveral sets of command types.  These sets include:    a.  general system commands (e.g., USER, HELP)    b.  parameter settings (e.g., TYPE, STRU)    c.  data control (e.g., ABORT, REIN)Bressler                                                        [Page 1]

RFC 486                 Data Transfer Revisited               March 1973    d.  file operation (e.g., STOR, RETR, LIST)    e.  job execution (e.g., INPUT, OUTPUT, CHANGE)    I will not try to completely specify the syntax of each commandsince they are still being finalized (left as an exercise for thereader?).    An implementor who was only interested in file transfer wouldimplement the general data transfer routines and the small set of filetransfer commands.  Another site might also wish to implement the jobexecution commands.    Users at traditional RJE stations would be able to store their fileson machines that do not support other RJE functions, by using the filetransfer command package in their user machine.  At some later date,they can connect to a batch server elsewhere on the net and instruct itto accept its input from the site currently storing the files.  Thuscard reader availability and access to a batch machine would not need tobe concurrent.    In an effort to get a feel for the complexity of this suggestions,the latest FTP offering (RFC 454) was compared with the RJE document.The amount of change to the RJE document was in fact relatively small(and will perhaps constitute a subsequent RFC).  A possible course ofaction, then, would be to take the "official FTP" resulting from the 16March meeting at BBN and divide the commands into data transfer and filetransfer components.  The RJE documents can then be revised or rewrittensuch that the "new" data transfer protocol will also have an RJE subset.This would be accomplished by recognizing and removing those parts ofthe RJE that dealt with data transfer, leaving a command subset dealingexclusively with job submission and execution.  This course of action isintended to cause minimal perturbation on current implementations.    The intention of this suggestion is not to try and pack everythinginto a single protocol but to make the large body of common code - thetransfer of data - available to current and new protocols.  New ideas,be they mail or load sharing, could be developed more easily given thecommon availability of this data transfer mechanism.RB/jm       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by Alex McKenzie with    ]       [ support from GTE, formerly BBN Corp.             9/99 ]Bressler                                                        [Page 2]