Data transfer revisited

R.D. Bressler

doi:10.17487/RFC0486

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC486

UNKNOWN

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)

Bressler                                                        [Page 1]


RFC 486                 Data Transfer Revisited               March 1973

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 [Page 2]

Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.