RFC 163

DATA TRANSFER PROTOCOLS 🦋

okay so this is RFC 163, titled DATA TRANSFER PROTOCOLS, from the Network Working Group 🌸 It's Request for Comments #163 (NIC #6775), written by V. Cerf at UCLA - NMC and dated 19 May 71. It's filed under category D.7 Computer Science, and it updates nothing and obsoletes nothing. Bestie, it's a total classic ✨

This is an informal write-up of stuff discussed at the SJCC. There are two big problems to sort out 💅

1. Moving data from one site to another.
2. Interpreting the data at the receiving site.

The first task (1) needs a simple protocol that does the following:

1. Sets up a standard connection procedure for the transmitting and receiving processes 🔌
2. Uses standard packaging so the network can collect the transmitted data stream in the right order and know when the end of the file has been reached 📦

Standard Connection Procedure

Picture this: every HOST has a process in charge 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 enough to set up a connection between a serving Data Manager and a using process. Lowkey so simple, iconic 👑

We totally skipped over data interpretation, and also the problem of control 🙈 For example, we haven't said how a process can ask the Data Manager to send a file with a particular name, or how to end the transmission of a file. That's getting deferred for later, periodt.

Another desirable ability is letting processes transmit files to each other without the HOST Data Manager in the middle. ICP should be enough to create a full duplex connection for that. File naming and format interpretation are left for the individual processes to figure out 💖

Here's a fun fact: files don't actually need names! If two processes are connected, the file name is kind of implicit in the sending and receiving socket pair ✨ BUT, one imagines that connections with Data Managers for file transmission are too transient to work as permanent file names. So the Data Manager will need info about the file name. That info could be either embedded in the file transmission data stream, or sent over a separate control connection set up at ICP time 🎀

It makes sense for a Data Manager to have a network-wide, fixed socket number where it listens for data transmission requests.* In that sense it acts a lot like the Network Logger 🫶 For inter-process file transmission, less rigidity seems needed, so we can leave those decisions to the individual processes talking to each other. Public processes at serving HOSTS could have known (nia NIC?) sockets where file transmission is acceptable.

Standard Packaging

We naively imagine that very little formatting is needed to move data across the connection 🍓 A few bits (8?) at the beginning of transmission could specify the formatting protocol (e.g. arbitrary bit string until connection closed, count field + data, break chars, etc.). Depending on the format mode you pick, the right control bits will or won't show up interspersed between the data bits. Message boundaries are totally transparent 🦋

A way of ending the file, possibly without closing the connection, is useful. Still, closing the connection after the RFNM from the final "record" sent is received by the sending process might be adequate (sufficient, but not palatable?) 🙈

*ICP causes sockets to be dynamically assigned for the ensuing conversation (which might be all 1-way).

Control

A great many problems come up if the Data Manager acts as part of the HOST filling system 😭 For example, the Data Manager must know whether the process it's serving wants to send a file or receive one. Either way, some kind of file name + qualifiers (user ID, security codes, access requested, etc.) will be needed to resolve the usual access legality and any potential file name ambiguities. This info can be supplied either within a single full duplex data stream (1 per ICP request) set up by a modified ICP for data transmission. The former seems simpler, sufficient, and immediately implementable 💜

Data transmission between arbitrary processes probably doesn't need as much formal control protocol as the process-to/from-DM (Data Manager) connection does. Ad hoc procedures can be set up by trading info over previously established connections. Regularity is nice, though, so maybe a standard set of control protocols can be devised that works regardless of which processes are transmitting data 🌈 Control data must be formatted and probably identifiable by prefix codes, so unnecessary control info can be left out if desired. (I'm thinking specifically of file names.)

Last but not least, it's still on the to-do list to establish a set of format protocols that permit packaging of data and identification of control information. That should be the job of the renamed Data Transmission Committee ⭐

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Simone Demmel 5/97 ]