RFC 163 (rfc163) - Page 1 of 3

Data transfer protocols

Network Working Group                            V. Cerf
Request for Comments #163                        19 May 71
NIC #6775                                        UCLA - NMC
Categories:  D.7                                 Computer Science
Updates:  None
Obsoletes:  None


                        DATA TRANSFER PROTOCOLS

This is an informal statement of material discussed at the SJCC.  There
are two peoblems.

   1.  Movement of data from one site to another.
   2.  Interpretation of the data at receiving site.

The first task (1) requires a simple protocol which accomplishes the
following

   1)  Standard connection procedure for connecting
       transmitting and receiving processes

   2)  Standard packaging which allows network to
       collect the transmitted data stream in the
       right order and know when the end of the
       file has been reached.

Standard Connection Procedure

Suppose every HOST has a process charged with the responsibility of
sending and receiving files between -HOSTS-(processes?)[The Data
Manager].  If the Data Manager offers to listen on a given socket for
file xmt requests, then ICP is sufficient to establish a connection
between a serving Data Manager and a using process.

We have completely avoided the discussion of data interpretation, and
also the problem of control.  For instance, we have not said how a
process can ask the Data Manager to send a file of a par- ticular name,
nor how to end the transmission of a file.  This is deferred for later.

Another desirable ability is to have processes transmit files to each
other independent of the HOST Data Manager.  ICP should suffice, for the
creation of a full duplex connection.  File naming, and format
interpretation are left to the individual process to solve.

It is of interest to note that files need not have names.  If two
processes are connected, then the file name is in a sense implicit in
the sending and receiving socket pair.  One imagines, however, that