RFC 486 (rfc486) - Page 2 of 2

Data transfer revisited

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 command
since they are still being finalized (left as an exercise for the
reader?).

    An implementor who was only interested in file transfer would
implement the general data transfer routines and the small set of file
transfer commands.  Another site might also wish to implement the job
execution commands.

    Users at traditional RJE stations would be able to store their files
on machines that do not support other RJE functions, by using the file
transfer command package in their user machine.  At some later date,
they can connect to a batch server elsewhere on the net and instruct it
to accept its input from the site currently storing the files.  Thus
card reader availability and access to a batch machine would not need to
be 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 of
action, then, would be to take the "official FTP" resulting from the 16
March meeting at BBN and divide the commands into data transfer and file
transfer components.  The RJE documents can then be revised or rewritten
such that the "new" data transfer protocol will also have an RJE subset.
This would be accomplished by recognizing and removing those parts of
the RJE that dealt with data transfer, leaving a command subset dealing
exclusively with job submission and execution.  This course of action is
intended to cause minimal perturbation on current implementations.

    The intention of this suggestion is not to try and pack everything
into a single protocol but to make the large body of common code - the
transfer of data - available to current and new protocols.  New ideas,
be they mail or load sharing, could be developed more easily given the
common 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