RFC-264

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

Data Transfer Protocol revisions

RFC-264 is titled “The Data Transfer Protocol”. It's dated November 15, 1971. It's authored by Bhushan, Braden, Crowther, Harslem, Heafner, McKenzie, Melvin, Sundberg, Watson, and White.

The technical content

This RFC is an update to RFC-171, which is the specification for the Data Transfer Protocol. Recall that the Data Transfer Protocol is a generic protocol for moving chunks of data across the network that is intended to power other protocols like FTP, which tend to handle things like file systems.

This is a long RFC but thankfully the authors include an overview of exactly what was changed in RFC-171!

The sequence number fields are now all 16 bits long. This addresses Brodie's complain in RFC-250 about ambiguity of field length. It also does not reduce the field length to 8 bits as Brodie suggested, which I believe is entirely the right call.

Information separators now have a sequence number, which addresses Braden's concern in RFC-238.

The modes-available transaction is no longer sent in simplex connections and have been simplified to only advertise receiving modes. This also addresses Braden's concern in RFC-238.

Information separators and error messages now tell you their associated sequence number, which I think is intended to address the objection from both Braden and Brodie that you can never tell when you've received a complete message. The idea is that a full message will end with a separator, so if you don't get the separator at the end of your file, and in particular if you know the file starts at sequence 10, and you get a separator at 14, but only have messages 10, 11, 12, and 14, you know you haven't received the whole message.

Analysis

I doubt the authors of this RFC expected that writing their TL;DR would save the time of some random guy writing 50 years in the future but they absolutely did and I'm grateful for it.

Also I'm impressed that they quickly (within about a month) and efficiently addressed nearly every concern brought to them about this protocol.

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.