365 RFCs

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

Gee, this is swell

RFC-226 is titled “Standardization of Host Mnemonics”. It's by Peggy Karp of MITRE, and dated September 20, 1971.

The technical content

The ARPANET hosts to date have been identified two ways: with a number, and with a short name. The host at UCLA is known to have host number “1” and goes by the name “UCLA”. The SRI-ARC host is known to have host number “2” and goes by the name... well, it's gone by more than one name in the last couple of years. While the number designations for hosts have tended to stay the same in these early days of the ARPANET (otherwise nobody could connect to anyone), the names are a totally different story.

In fact, each ARPANET site mantains their own list of known host numbers and names. There's no central source of information for this, though you could cobble one together by reading all 200 or so RFCs published thus far.

This RFC is Peggy Karp's proposal to formalize the names and numbers for each ARPANET host. It will garner a bunch of responses in RFCs to come.

Analysis

This RFC is less than a page, and it's ridiculously important to the history of the internet.

Our entire domain name system today is a way of mapping numbers called “IP addresses” to human readable “domain names”.

Karp's 1971 list is twenty entries long and begins:

            HOST #             DESIGNATOR
              1                  UCLA
             65                  UCLA36

On today's internet, we could have a similar list that is millions of entries long and perhaps begins:

            IP #             DOMAIN NAME
       216.58.195.78           google.com
         72.30.35.10           yahoo.com

Of course, DNS is orders of magnitude more complex than the host name table of the early ARPANET but the fundamental purpose of both remains the same.

Assignment of numbers and names to host sites would become a topic of heated debate on the ARPANET. Jim White published a missive on May 11, 1973 sarcastically titled “Gee Host Names and Numbers are Swell” which was part of an ongoing conversation at the Network Information Center that Spring about how to best handle the problem of proliferating sites.

Further reading

For a fascinating paper on this very subject, see Steven Malcic's “The problem of future users: how constructing the DNS shaped internet governance” (2016). It tracks the how the ARPANET naming problem of RFC-226 evolved over many years into the creation of an entirely new piece of internet infrastructure: DNS.

Jim White's 1973 post “Gee Host Names and Numbers are Swell” is viewable on page 23 of this PDF, which is online thanks to an amazing effort from the Computer History Museum to scan a huge portion of the SRI ARC Journal, which is kind of like the email or bulletin board records of the Network Information Center over the years. Because I like White's post so much, I transcribed it and put it on this blog for easy reading.

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, August 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.

On-Line from afar

RFC-225 is titled “RAND/UCSB Network Graphics Experiment”. It's authored by Eric Harslem of Rand and Ron Stoughton of UCSB. It's dated September 13, 1971.

The technical content

For about a month now, programmers at RAND Corporation have been accessing UCSB's On-Line System (OLS) via graphical consoles at the RAND offices.

Specifically, the OLS is being accessed via the Rand Video-Graphics System (VGS), which is equipped with a tablet input. It runs a special program locally that acts as a kind of virtual OLS interface that emulates the second keyboard needed to use the OLS. If you look at the ASCII art diagram you'll see it's divided into three parts:

• a feedback section at the top that tells you what screen you are looking at
• a big middle area that shows the text or the graphical output
• a virtual keyboard, not dissimilar from your phone keyboard, that you're supposed to use a tablet input to type on

(By the way, the figures in the original document are almost certainly not ASCII art. Most of the drawings in the early RFC series were converted to ASCII from their original form as line drawings in the late 1990s. If/when I can dig up the scans, I'll add them here.)

They plan to present the result of this work at the October graphics meeting in the form of both a paper and a film showing its use.

Analysis

We haven't heard from Ron Stoughton since the very earliest days of the Network Working Group! He was one of the original members and his name is listed in RFC-3 as the primary contact for UCSB. This is the first RFC he is listed as an author on, and he will only write one more after this.

Further reading

The Rand Video-Graphics System is described in detail in this 1971 paper.

Here is a poor-quality photo of the system in action, from the paper:

And here's a block diagram of the system, also from the paper:

There are more photos available in this less detailed but higher scan quality paper at the RAND website.

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, August 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.

Renting mail boxes

RFC-224 is titled “Comments on Mailbox Protocol”. It's authored by Alex McKenzie of BBN and dated September 14, 1971.

The technical content

The author would like to note that the Terminal IMP (TIP) as introduced in RFC-215 will be unable to provide a mail box under the proposed Mail Box Protocol. This is because the TIP can't operate as a server in any capacity, and at any rate it's not ever going to support the File Transfer Protocol, which is a new requirement as of RFC-221.

McKenzie isn't saying this is a reason to scuttle the Mail Box Protocol, but he says that TIP users should be able to “rent” a mail box on a more powerful server which they could then Telnet to and access their messages.

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, August 11 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.

Nine to five

RFC-223 is titled “Network Information Center Schedule for Network Users”. It's authored by John Melvin and Richard Watson of SRI-ARC. It's dated September 14, 1971.

The technical content

Something we take for granted on the modern internet is the idea that services will be online 24 hours a day, 7 days a week. This was not the case for the early ARPANET. Servers would be online at various times of day; sometimes during working hours as you might expect, sometimes only during off-hours as that was when the teams would be allowed to do network experiments with a given computer!

This RFC is a declaration that the Network Information Center (NIC) at Stanford Research Institute is ready provide regular service Monday through Friday for about 13 hours a day. Weekend availability will be “on an irreguar basis”.

When a user connects to the NIC via Telnet, “the system herald will be printed”, along with a message from the adminisrator. A “system herald” is an identifier for the server you're connected to. The following is an example I am making up of a herald (the first line) followed by a prompt asking for a user name:

YOYODYNE SYSTEMS INC REMOTE SERVICES STATION

USER NAME?

Over the next several decades heralds evolved to be pretty complex, sometimes including ASCII art.

A user should log in to the NIC using their host site identifier as their username. The password is ARPA. Then you enter an account number consisting of your host site identifier and your last name, like `ucsb-white.

There are telephone numbers provided for support if you're having trouble connecting to their services. The RFC closes with a list of host site identifiers.

Analysis

I love the plain communication of an access password in an RFC! This would not have been a huge security problem at the time, since RFCs were distributed to trusted parties.

Further reading

There is at least one website I know of that has limited operating hours. It's an energy-efficient website that is only online when its server has sufficient solar energy stored up. Check out this page on Low Tech Magazine for more—that is, if it's been sunny in Barcelona!

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, August 10 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.

Grueling workshop

RFC-222 is titled “System Programmer's Workshop” and authored by Bob Metcalfe of MIT Project MAC. It's dated September 13, 1971.

The technical content

This RFC describes the first two days of the next Network Working Group meeting in Cambridge, Massachusetts in mid-October. These days are a System Programmer's Workshop.

The workshop is described as “grueling” and they want no more than a dozen dedicated participants. Participants should have working knowledge of the various protocols and the inner workings of their own site's Network Control Program and Telnet client and server. The first order of the workshop is to use the PDP-10 at Project MAC to connect to as many Telnet servers on the network as possible. Then by connecting to those sites, they can Telnet to other sites, and hopefully exhaust every possible Telnet connection to every possible server, debugging as they go.

Analysis

“System programmer” is a term that came up a lot in older (late 1950s) computing documents that I've encountered in my research. Essentially, in the 1950s a “programmer” was considered a kind of code monkey, a sort of glorified typist. A “systems programmer” was a term used for someone who would design entire new systems from scratch, doing inventive computer science work, publishing papers, and so on. My sense is that this terminology was going out of style in 1971 but it's clearly still around enough that they named a whole workshop after it.

The workshop sounds really cool, actually. I like that the entire point is to get every computer on the network to Telnet to every other computer on the network!

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, August 9 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 for mail

RFC-221 is titled “A Mail Box Protocol, Version-2”. It's by Richard Watson of SRI-ARC and dated August 25, 1971.

The technical content

This RFC updates RFC-196, which is a proposal for a protocol for an email-like thing. The original proposal uses the Data Transfer Protocol for data transfer, but Network Working Group members would prefer to use File Transfer Protocol so this RFC incorporates that protocol instead.

The big issue with using FTP for the Mail Box Protocol is that FTP assumes the user understands something about the file system and path names of the remote site. The Mail Box Protocol would ideally not involve the end user who is sending a message to know anything about the file system of the recipient.

The proposed solution is for the ARPANET sites to agree on a virtual pathname for a Mail Box, then connect via FTP to the special Mail Box socket, issue an Append request to the path, and pass the ASCII string “NETMAIL” followed by an 8-bit byte corresponding to a mail box number. This would mean each host computer could support up to 256 inboxes.

The issue of spam and abuse is raised (”the possibility of someone accidentally or deliberately flooding the printer of a site with garbage”), but no good solutions have been discovered. The suggestion is made that the protocol not involve any safeguards and that it's up to individual sites to add their own safeguards, though perhaps at a later date there could be standards for safety agreed upon by all.

Analysis

I'm wondering why they would have to agree on a path name at all for the Mail Box, when there is already a specific socket reserved for the protocol. Individual host sites could simply interpret any Append request from FTP on the mail box socket as a request to append to the local mail box, wherever it happens to be on the file system.

A purely nerdy aside is that the end note of the RFC lists the author as “Richard W. Watson/RWW”, which means he typed up this RFC himself. I've wondered what percentage of RFC documents are prepared by secretarial workers...

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, August 8 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.

Not issued

RFC-220 was never issued.

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, August 7 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 datacomputer

RFC-219 is titled “User's View of the Datacomputer”. It's authored by Richard Winter of the Computer Corporation of America, and dated September 3, 1971.

The technical content

This RFC is about the “datacomputer”, aka the trillion-bit store last mentioned in RFC-164. The idea is that this is, basically, a big shared drive for files. Some files are limited to only certain users, but other files are meant to be accessed by the entire user population of the ARPANET.

The author says that the datacomputer should be conceptualized as a black box, and that the way to interface with the black box is via a “data language”. Generally speaking, CCA is trying to make the internals of the datacomputer unnecessary for a user to know about, and instead the user should only be concerned with accessing records via their correct identifiers.

The datacomputer only a priori knows about one file: this is the file that contains the information about where all other files are. So that file is the datacomputer's entry to and view on its universe. Files contain uniquely numbered records, and records contain named fields. Named fields are not necessarily unique. Fields correspond to elementary data, so it seems like what we have here is a sort of key-value store.

Files can also contain an index with pointers to records. The example they give is an index that points to all records where the named field “STATE” has the value “MASSACHUSETTS”. (This seems a lot like a database index to me, in that it's kind of a pre-baked relationship that lets you access things faster than usual, but I'm even less of an expert in databases than I am in computing history.)

The datacomputer does periodic garbage collection, because as records are inserted into the system, sequentially ordered files might not end up physically sequentially ordered, only logically sequentially ordered.

The datacomputer communicates in “streams”, which are sequences of records passed between the datacomputer and a using program.

Apparently, access to a full file at a time is not the primary use of the datacomputer. Rather, they expect users to request subsets of files, comprised of lists of record ID numbers. You can also do simple boolean queries on file indices, like “return all records where the named field STATE is MASSACHUSETTS and the named field MONTH is AUGUST”.

The primitives for writing files are:

• add a field/record
• delete a field/record
• replace a field/record

The author also notes that when the contents of a record is changed, any indices that point to the record must be recalculated.

The document ends with a list of potential uses for the datacomputer, including:

• storing and retrieving giant blobs of data
• a replacement for local tape drive storage
• text storage and retrieval
• storage and retrieval of a large database, like census data

Analysis

While modern programmers are probably really familiar with the concept of streams, a programmer in 1971 may not have been. I love this very simple description of the ephemerality of a stream:

There is no concept of permanent storage for streams.  The records move past the datacomputer one at a time, as though they were on a conveyor belt.

One record, the current record, is available to the datacomputer in each stream.

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, August 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.

Fake host

RFC-218 is titled “Changing the IMP status reporting facility”. It's authored by Bernie Cosell of BBN and dated September 8th, 1971.

The technical content

This is another warning from BBN that there will be changes made to the IMP. The IMPs send status reports back to BBN, and they are moving fully to a binary blob format for transmission instead of plaintext. They also have hardened their network measurement service so that it doesn't accept control input from random hosts anymore, to “prevent the Hosts from inadvertently interfering with the operation of the NCC”.

Analysis

There is mention of “fake host 3” in this RFC. I believe this is a host that could be connected to in order to have network measurements taken for the duration of your connection.

“NCC” is mentioned several times in this document. I found a reference to a Network Coordination Center but that appears to have been founded in the early 1990s. Clearly the purpose of this center is taking statistical measurements of the IMP network, and it's housed at BBN, but I can't confirm what it stands for. I'll update this if I hear back from BBN folks who are kind enough to respond to my emails.

Update: it stands for “Network Control Center”, also sometimes known as the “Network Operations Center”. Here is an early paper about the Network Control Center, courtesy of BBN alumnus Dave Walden.

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, August 5 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.

Changes to UCSB services

RFC-217 is titled “Specification Changes for OLS, RJE/RJOR, and SMFS”. It's authored by Jim White of UCSB and dated September 8, 1971.

The technical content

This RFC issues four revisions.

First, since literally nobody has tried to connect to the Network Control Program described in RFC-74, they have taken down that service.

Second, the Remote Job Entry (RJE) protocol outlined in RFC-105 used to throw away the first 8 bits of a message in order to ignore the “message type” field. Since that field is no longer in the RFC-107 version of the Host-Host Protocol, the RJE no longer expects to receive that spurious data.

Third, RJE now uses the Initial Connection Protocol to connect instead of its own unique system.

Fourth, RJE and the Simple-Minded File System now use an 8-bit byte when sending data to a remote user. (They still accept any declared byte size for incoming traffic.)

Analysis

All of these revisions really stem from making their services compliant with the RFC-107 version of the Host-Host 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.