RFC-310

by Darius Kazemi, November 6 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Reconsidering FTP

RFC-310 is titled “Another Look at Data And File Transfer Protocols”. It's by Abhay Bhushan of MIT and dated April 3, 1972.

The technical content

This document is published in advance of the file transfer workshop announced in RFC-309. The idea is for Network Working Group members to discuss the contents of the RFC at said workshop. The author is the organizer of that workshop and also the original author of the FTP specification in RFC-114.

The documents opens by talking about some prior art: a program called CPYNET available on BBN's TENEX operating system. (I imagine the name stands for “CoPY-over-NETwork”.) This is not a true FTP-style thing because FTP is supposed to work across all computers and operating systems and file systems. CPYNET only works if you're copying files from one TENEX-based machine to another.

Because it's optimized to work with a small number of computers, CPYNET is efficient. Because TENEX is a PDP-10 operating system; you're dealing with the same operating system and the same hardware so you know that it's a 36-bit byte length. Thus no translation or partitioning of data is required.

Another method of file transfer that's been used on the network is a weird and interesting hack. TELNET itself has been modified at some sites to send ASCII files from one host to another. The way you do this is by logging in to a remote computer from yours via TELNET. Let's say that you want to send a file to the remote computer. What you do is tell TELNET to literally type out the contents of the local file on your computer into an empty file on the remote computer! This is not very efficient and ends up being about 10x slower than a more direct network transfer.

There's a problem where the Terminal IMP (TIP) can't support the Data Transfer Protocol (the foundation of the current formulation of FTP). Recall that the TIP is a kind of low-power terminal where a user's terminal is connected directly to an IMP instead of via a (big, expensive) computer in the middle. As Bhushan notes in this RFC,

The TIP philosophy is that "the computational load and storage should be in the hosts or in the terminals and not in the terminal processor."

Anyway, because TIPs won't support DTP, Bhushan recommends removing the transfer mode that was included specifically for TIPs, since they won't be using it anyway.

Computer Corporation of America is requesting some changes to the FTP specifcation in order to help out with their Datacomputer project. Among other changes, they would like FTP commands to be printable ASCII strings, so that FTP commands can be natively a part of their “Datalanguage”, which presumably could not handle integers as tokens for commands. Later, Bhushan notes that wide adoption of FTP

would be possible if a user could use an FTP-server directly without the help of a mediating DTP/FTP-User process.  This would require that commands be ASCII strings instead of numeric codes, and that ASCII characters be an acceptable input.  Such a change in FTP would greatly increase its acceptance at the cost of making the server-implementation more complex.

Bhushan also would like to modify DTP and FTP to better support remote job systems. In particular, there is talk of merging NETRJS and NETRJT into a single thing, and Bhushan would like DTP to provide some of the backbone for this new system. There would need to be new features like error recovery if this is to be the case, though.

Bhushan provides no answers in this paper but that's by design; the idea is that he is highlighting questions that will be addressed at the workshop next month.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.