RFC486 - Data transfer revisited

Network Working Group Bob Bressler

RFC#486 BBN

NIC #15064 20 March 1973

Data Transfer Revisited

A lot of work has recently gone into the development and refinement

of both the RJE and FTP protocols. Stepping back from the details and

small issues, we can describe the two protocols as 1) a control

connection over which commands are passed, and 2) a data connection over

which uninterpreted (by the server process) data is passed. Both

protocols 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 been

introduced into one protocol or the other, but these concepts are

generally applicable to both. In addition, a great deal of effort was

made to make the structures of the two protocols be as similar as

possible.

This discussion is, of course, leading to the suggestion that we

stop considering these as two separate protocols, and merge them into a

single unit - perhaps resurrecting the name of "data transfer".

Several advantages besides simplicity are gained by this. Sites

need only build one server program - given that they can always respond

with "command not implemented". This will also prevent the RJE users

and servers from having to start up a (possibly) separate FTP user and

server - saving the resulting doubling of programs and Telnet

connections.

The further advantage of insuring that new ideas and concepts will

be shared by all users and servers will also be realized. A RJE user

will be able to transfer his deck of cards (file) to storage on another

machine's file system using the "hot card reader" previously defined

only in the RJE protocol.

The command set of the combined protocol would now consist of

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

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 (RFC454) 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 RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by Alex McKenzie with ]

[ support from GTE, formerly BBN Corp. 9/99 ]