Browse Prior Art Database

Data transfer revisited (RFC0486)

IP.com Disclosure Number: IPCOM000003627D
Original Publication Date: 1973-Mar-20
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 4K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.D. Bressler: AUTHOR

Abstract

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 67% of the total text.

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 c...