RFC 486

Data Transfer Revisited 💖

The title block, bestie: this is from the Network Working Group, written by Bob Bressler at BBN, as RFC #486 (NIC #15064), dated 20 March 1973. The header doesn't list a category, an obsoletes, or an updates field. 🌸

Okay so, a lot of work has recently gone into developing and refining both the RJE and FTP protocols 🔥. If you zoom out past the details and tiny issues, you can describe them as two things: 1) a control connection where commands get passed around, and 2) a data connection where data gets passed around that the server process doesn't interpret 🧚. Both protocols are about identifying yourself to the server, setting up parameters, and transferring some data. Honestly, the vibes match 💅.

New ideas got introduced into one protocol or the other, like the "hot card reader" 🙈. But these concepts are generally useful for both! Also, a ton of effort went into making the structures of the two protocols as similar as possible. Iconic teamwork 👑.

So this discussion is basically leading to the suggestion that we stop treating them as two separate protocols and merge them into a single unit, maybe bringing back the name "data transfer" ✨. It's giving streamlined.

Merging them has advantages beyond simplicity 💜. Sites only need to build one server program, given that they can always respond with "command not implemented" 💀. That also means RJE users and servers don't have to spin up a (possibly) separate FTP user and server. No doubling of programs and Telnet connections, no cap 🫶.

There's another win too: new ideas and concepts get shared by all users and servers 🦋. An RJE user will be able to transfer their deck of cards (file) to storage on another machine's file system using the "hot card reader," which was previously only defined in the RJE protocol. Main character energy for the card reader 🎀.

The command set of the combined protocol would now consist of several sets of command types. They include:

• a. general system commands (e.g., USER, HELP)
• b. parameter settings (e.g., TYPE, STRU)
• c. data control (e.g., ABORT, REIN)

RFC 486                 Data Transfer Revisited               March 1973

• d. file operation (e.g., STOR, RETR, LIST)
• e. job execution (e.g., INPUT, OUTPUT, CHANGE)

I'm not going to fully specify the syntax of each command, since they're still being finalized (left as an exercise for the reader? 🙈).

An implementor who only cares about file transfer would implement the general data transfer routines and the small set of file transfer commands 📁. Another site might also want to implement the job execution commands 🧑‍💻.

Users at traditional RJE stations would be able to store their files on machines that don't support other RJE functions, by using the file transfer command package in their user machine 💖. Later on, they can connect to a batch server elsewhere on the net and tell it to accept its input from the site currently storing the files. So card reader availability and access to a batch machine wouldn't need to happen at the same time. Scheduling iykyk 🌈.

To get a feel for how complex this suggestion is, the latest FTP offering (RFC 454) was compared with the RJE document 🔍. The amount of change needed for the RJE document was actually pretty small (and it'll perhaps be a subsequent RFC) ✨. A possible plan, then, would be to take the "official FTP" that came out of the 16 March meeting at BBN and divide the commands into data transfer and file transfer components 🎀. The RJE documents could then be revised or rewritten so the "new" data transfer protocol also has an RJE subset. That works by recognizing and removing the parts of RJE that dealt with data transfer, which leaves a command subset focused exclusively on job submission and execution 💅. This plan is meant to cause minimal disruption to current implementations 🫶.

The point here isn't to cram everything into a single protocol 🚫. It's to make the big body of common code, the transfer of data, available to current and new protocols 🍓. New ideas, whether that's mail or load sharing, could be developed way more easily with this shared 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 ]