365 RFCs

by Darius Kazemi, December 20 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.

A fourth revision of FTP

RFC-354 is titled “File Transfer Protocol”. It's authored by Abhay Bhushan of MIT Project MAC and dated July 8, 1972.

The technical content

This is the third major revision of FTP, the File Transfer Protocol. It's the result of the work done at the Data and File Transfer Workshop, notes from which were published in RFC-327. The big outcome of that workshop, at least for me, was that the Data Transfer Protocol would be folded into FTP, giving us one specification instead of two specifications that have about 80% overlap. (Note that in the header of the RFC, it is listed as obsoleting both RFC-264 and RFC-265. These are, respectively, the DTP and FTP specs.)

I won't go over every aspect of the RFC because it's not TOO different from my coverage of its previous drafts, RFC-265, RFC-172, and RFC-114.

In addition to folding in DTP stuff, this draft adds a “terminology” section, basically a helpful glossary for all the technical terms therein. There are more verbose examples, better documentation of commands, and significantly improved error codes.

Analysis

One thing that jumps out to me is this block describing the FTP status codes:

   000 These replies are purely informative and constitute
       neither a positive nor a negative acknowledgement.

   1xx informative replies to status inrequiries. These constitute
       a positive acknowledgment to the status command.

   2xx Positive acknowledgment of previous command or other
       successful action.

   3xx Incomplete information. Activity cannot proceed without
       further specification and input.

   4xx Unsuccessful reply. The request is correctly specified
       but the server is unsuccessful in corretly fulfilling
       it.

   5xx Incorrect or illegal command. The command or its
       parameters were invalid or incomplete from a syntactic
       viewpoint, or the command its inconsistent with a previous
       command. The command in question has been completely
       ignored. 

This is almost identical to how modern HTTP status codes are organized! The major difference is that HTTP has no 000 statuses, and 3xx means redirect in modern HTTP rather than “incomplete information”. This is the first I've seen documentation of status codes using this scheme in the RFC series, but the FTP spec says that it's based on the scheme used by the Remote Job Entry protocol. Fun fact: this protocol has yet to be documented, but it is forthcoming in RFC-360. Although that RFC has a higher number assigned to it, it will is published with a date two weeks prior to this one.

RJE was a topic of discussion at the Data and File Transfer Workshop at MIT on April 14-15, 1972, so I am reasonably certain that these RFCs were developed in parallel and the status code conventions were settled on during that workshop. According to the meeting notes in RFC-327, “Standard error codes and responses will be provided for storage and I/O channel errors, at the FTP level.“

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.