RFC-172
by Darius Kazemi, June 21 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.
FTP, again
RFC-172 is titled “The File Transfer Protocol”. It's authored by Abhay Bhushan, Bob Braden, Will Crowther, Alex McKenzie, Eric Harslem, John Heafner, John Melvin, Dick Watson, Bob Sundberg, and Jim White. It's dated June 23rd, 1971.
The technical content
This document is an iteration on FTP specification laid out in RFC-114 and also has a lot of overlap with RFC-171. I'll describe some of the new things in this document that differ from what was included in RFC-114.
First off, now that the TIP (terminal IMPs) are more in use, the opening paragraph of this document mentions them as a specific use case. This new FTP spec is also an extension of the RFC-171 data transfer protocol, so the reader is expected to have read that RFC for background.
The RFC mentions the concept of “indirect usage” once again as a primary motivator for FTP. I'll quote myself in my blog post about RFC-114 where I explain the term and its counterpart, “direct usage”:
Direct usage is when a user logs in to an actual account on the remote computer and uses it as though they were sitting there in front of it, typing all the same commands that a local user would. Indirect usage is where you don't get anything approaching operating system access and rather some kind of mediating system is involved that interacts with the operating system on your behalf.
Importantly, FTP is meant to "shield the user from variations in file and storage systems of different hosts", acting as an abstraction on top of complex technical problems.
In RFC-114, a file is said to be uniquely identified "by its file name and directory name", and the concept of a “pathname” is mentioned in passing, but in this RFC the “pathname” is now the primary organizing concept of a file and it's explicitly stated that a pathname merely “usually” consists of a file name and directory name, but could also consist of a device name or other unique identifiers.
Access control (or at least support for it) is now a core part of FTP. In RFC-114, access control was mentioned as a possible extension to the protocol, but it seems it's been upgraded in status now.
As I mentioned above, FTP is now built on the Data Transfer Protocol of RFC-171, and the authors note that FTP is not compatible with DTP's “bit stream” mode so a host would need to support one of the other two DTP modes, which are block transfer or the byte count mode.
Error codes have moved to sequential numbers rather than ascii shortcodes. For example, in RFC-114 an “undefined” error was sent as the ASCII character “U”, type error was sent as “T”, and so on. Now error codes simply have numbers assigned to them with no particular semantic meaning, starting with 0 for “system error”. Also a lot of the original FTP error codes are now handled at the DTP layer.
Analysis
Despite my dislike of the design-by-committee nature of RFC-171, I like that it's made RFC-172 a much simpler document than its original form in RFC-114.
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.