365 RFCs

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

Re: satellites

RFC-355 is titled “Response to NWG/RFC 346”. It's authored by John Davisdon of the University of Hawaii's ALOHAnet project and dated June 9, 1972.

The technical content

This is a response to Jon Postel's consideration of satellite uplinks for the ARPANET in his RFC-346. Its author is a member of the ALOHAnet project, a packet radio network that would within about six months be connected to the ARPANET via satellite.

Apparently by the date of this RFC, the plans for this are already proceeding!

The University of Hawaii, being isolated on an island in the Pacific, has unsurprisingly been invested in the question of satellite telecommunications. They state that line-by-line interaction, rather than character-by-character interaction, is important to reduce perceived interaction delay in high-latency scenarios. This makes a lot of sense: better to type your whole command out and wait 2 seconds for a reply than to wait 2 seconds between each character you type to see it appear on your screen!

Generally speaking the author recommends buffering input wherever possible and then batch processing the result.

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.

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.

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

Network status

RFC-353 is titled “Network Host Status”. It's authored by Ellen Westheimer of BBN and dated June 12, 1972.

The technical content

This is another report from BBN on the status of various ARPANET hosts in the same series as RFC-344, RFC-342, RFC-332, RFC-330, RFC-326, RFC-319, RFC-315, RFC-306, RFC-298, RFC-288, RFC-287, RFC-267, RFC-266, RFC-255, RFC-252, RFC-235, and RFC-240.

The numbers, from May 22 to June 2:

• 45 dead
• 73 open
• 10 half open
• 12 timed out

Three TIPs came online in this period: Fort Belvoir in Fairfax, VA; the Seismic Array Analysis Center in Alexandria, VA; and the National Oceanic Analysis Agency in Boulder, CO. Online status across the network hasn't really changed since the last few reports.

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.

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

TIP questionnaire

RFC-352 is titled “TIP Site Information Form”. It's authored by David H. Crocker of UCLA and dated June 5, 1972.

The technical content

This RFC contains a questionnaire about whether your ARPANET site has special features enabled for Terminal IMP (TIP) users. Recall that the TIP is a low-end terminal that is connected directly to an IMP, bypassing the need for an expensive computer like a PDP-10. By collecting information about sites with special accomodations for TIP users, the hope is to make the network more useful in general for TIP users.

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.

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

Graphics questionnaire

RFC-351 is titled “(Graphics) Information form for the ARPANET Graphics Resources Notebook”. It's authored by David H. Crocker of UCLA and dated June 5, 1972.

The technical content

This RFC contains a questionnaire about graphics capabilities at ARPANET Host sites. The responses will be turned into an ARPANET Graphics Resources Notebook.

The information requested includes hardware, software, how your networked capability differs from your local capability, login procedure, escape signals, and any cool demos that people can run to get an idea of what your system can do.

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.

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

Accounting

RFC-350 is titled “User Accounts for UCSB On-line System”. It's authored by Ron Stoughton of UCSB and dated May 18, 1972.

The technical content

For about a year, UCSB has allowed people to log in to its On-line System (formerly the Culler-Fried On-Line System) and do interactive mathematical computation work. It provided this service free of charge, with the cost to the university coming out of its ARPA contract.

This is about to change—this RFC states that the service will continue to be free on a trial or experimental basis, but for serious usage people need to open a billing account with UCSB so that they can be charged.

When the service was free, everyone who used the service had the exact same login. In order to monitor usage by each individual user, they're going to need to provide user names to everyone. So the anonymous “ARPA” login will be retired in favor of logins for each ARPANET site, which they provide in an attached list.

Analysis

This gets to a minor revelation I had while writing about these RFCs: the reason that our unique identifier for an internet service is referred to as an “account” is because it was originally supposed to correlate directly to an account in a billing a system. Perhaps this is obvious, but hey, better I realize it later than never.

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.

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

The Czar of Socket Numbers

RFC-349 is titled “Proposed Standard Socket Numbers”. It's authored by Jon Postel of UCLA and dated May 30, 1972.

The technical content

This is the last of Postel's batch of four RFCs submitted on May 30. It is deceptively simple but will have long reverberations in the history of the internet. For starters, Postel suggests that a “czar” hand out standard socket numbers for things like FTP, Telnet, etc. He suggests in an is-he-kidding-or-is-he-serious way that he take on the role of czar himself.

He offers some socket assignments. These specific numbers will not stick for long, but the nickname “Numbers Czar” or “Czar of Socket Numbers” would be affectionately applied to him for the rest of his life. By RFC-433 he is referred to by the title in a tongue-in-cheek-yet-also-official capacity.

He would eventually become, for a time, the literal sole person who constituted the Internet Assigned Numbers Authority, aka the people who assign domain names to specific physical computers. This made him, in a very real sense, the Czar of All Numbers That Matter on the Internet.

Further reading

RFC-8700 was published this year. It is Heather Flanagan's 50-year retrospective on the RFC series and refers to Postel's title as Czar of Socket numbers. It is also the first RFC I ever commented on in its draft form (and my suggestions were incorporated, thanks Heather!).

RFC-2468 is a heartfelt remembrance of Postel by Vint Cerf, short and sweet.

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.

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

Discard process

RFC-348 is titled “Discard Process”. It's authored by Jon Postel of UCLA and dated May 30, 1972.

The technical content

This is another of Postel's batch of RFCs submitted on May 30. It proposes a discard process: unlike the echo process of RFC-347, this process will listen for requests from remote hosts, open the connection, and then immediately discard any data that is sent.

Analysis

Postel says this is useful for debugging but doesn't specify further than that. I'm guessing that it would be good for debugging “what happens if I send data to a valid, open remote process but never get a reply”?

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.

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

Echo process

RFC-347 is titled “Echo Process”. It's authored by Jon Postel of UCLA and dated May 30, 1972.

The technical content

Postel suggests that all willing hosts implement a special type of process that a remote user can connect to. All it does is receive a message from you and then as quickly as possible send back the exact same message, unmodified. This would help with measuring delay on the network.

Analysis

This RFC was submitted on the same day as RFC-346, Postel's thoughts on satellite connections. Presumably he was thinking about how one would measure satellite link delays and it occurred to him that this would be a useful debugging feature in general.

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.

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

The network: in space!

RFC-346 is titled “Satellite Considerations”. It's authored by Jon Postel of UCLA and dated May 30, 1972.

The technical content

Postel is looking to the future, asking Network Working Group participants to start taking seriously the idea of using satellite links to transmit ARPANET data. Postel notes that the main issue with a satellite uplink is transmission delay. By his back-of-the-envelope calculations, you could expect a 15x increase in delay time for your messages. He suggests some sleight-of-hand tricks that could be done with message buffers to mask the delay for interactive usage, and also mentions the (I thought long-forgotten!) RFC-5, which offloads a lot of the interactivity for rich applications onto the client.

Analysis

I read conflicting reports of exactly when it happened, but certainly by December 30, 1972 (a mere six months later!) there was a Terminal IMP installed in Hawaii and connected to NASA Ames via satellite link. You can see this in the map included in RFC-432, with the satellite link distinguished via its zig-zag line from Hawaii to Ames. Most accounts that I read say that this bridged the already-extant packet-radio-based ALOHAnet to the ARPANET.

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.