365 RFCs

Commenting on one RFC a day in honor of the 50th anniversary of the first RFC.

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

Meeting minutes

RFC-21 is meeting minutes from a Network Working Group meeting held on October 10, 1969. The RFC itself is dated October 17, 1969. Vint Cerf is once again listed as the author.

Technical content

The conversation is divided into three parts.

In part 1, they discuss revisions to BBN Report No. 1822. I am still unable to find a 1969 version of this report. I can only find a January 1976 revision that is significantly changed (the page numbers don't match up at all, for starters). The group discusses what to do if the IMP network is at maximum capacity, how to take advantage of some IMP quirks to aid in measuring ARPANET traffic, and reminding people that some of the numbers in the BBN document are in octcal (base 8) so when they see “type 10” that is really “type 8”.

In part 2 they tell us to disregard Déloche's RFC-11, and that new information will be coming in RFC-22. This is good. I didn't like RFC-11 very much.

In part 3 they tell us to keep an eye out for RFC-23, which will concern sending control messages over links.

Analysis

The meeting was attended by people from SDC, UCSB, and UCLA. Listed in the attendance list under UCLA is Jon Postel. I believe this is the first reference to Postel in an RFC. I mentioned this in my RFC-8 post but it bears repeating: Postel was the editor of the RFC series from almost the very beginning of the series until his untimely death in 1998. (He was not editor at this point because it was not a “series” or anything yet.) Postel was also in charge of top level domain assignment and IP addresses before ICANN was established right around the time of his death. For many years Postel essentially was the internet. There's a lot of information about him at USC's Postel Center and RFC-2468 is a remembrance of Postel by Vint Cerf... the author of this very RFC.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

ASCII

RFC-20 is another Vint Cerf RFC, dated October 16, 1969. This is 13 days before the first message will be sent over the ARPANET.

I've been waiting for this RFC. I love this RFC.

Technical content

This requires a bit of background before I get into the RFC itself.

Character encoding

This RFC is about character encoding, so, what's character encoding?

Well, computers store numbers. That's all they do. Everything on a computer, when you drill down deep enough, is a number stored in memory somewhere. And yet we use computers to deal with written text all the time. This means that somewhere in the computer there has to be an understanding that the letter “A” is this number, “q” is that number, and so on. That's all a “character encoding” is.

The problem with ARPANET is that there was no guarantee that the letter “A” on one computer would be represented by the same number on another computer. So without some kind of agreed upon standard, I could be sending “hello” to your computer, but your computer would read it as “ifmmp”.

ASCII is the agreed-upon standard. It is the “American Standard Code for Information Interchange”, and was formalized as an information encoding standard in 1963 (although first proposed in 1961). The reason for ASCII goes back to Morse Code and telegraphs. Morse Code only allowed for uppercase A through Z and the numbers 0 through 9. There wasn't even a “period” allowed, which is why old-timey telegraph messages look like this:

THIS IS THE FIRST SENTENCE STOP THIS IS THE SECOND SENTENCE STOP

People wanted lowercase letters. They wanted punctuation. This led to many, many newer standards. Telegraph standards led to teletype standards which ended up getting used by computers (since teletype was a primary input/output device for computers before monitors and keyboards).

By 1963 there were over 60 different encodings used by computers. ASCII was developed to provide a standard for this. President Johnson signed a memorandum saying US federal computers needed to use ASCII to communicate in 1968. Since ARPA was a military network, ASCII the only real choice for the job. From the memorandum:

All computers and related equipment configurations brought into the Federal Government inventory on and after July 1, 1969, must have the capability to use the Standard Code for Information Interchange and the formats prescribed by the magnetic tape and paper tape standards when these media are used.

The original content

This document is actually just a single paragraph written by Cerf. The remainder of the document is an attachment of what is presumably the official ASCII standard.

The part that Cerf writes explains that they are using the 7-bit ASCII encoding, meaning an ASCII character on an 8-bit computer looks like this in binary:

0010 0000

That first bit on the far left is always 0. We have to store the number in 8 bits of memory because it's an 8-bit computer, meaning the smallest amount of data we can work with is 8 binary bits. So the first '0' is just cruft. We only care about the remaining 7 bits on the right. This lets us represent 128 different characters because there are 128 different combination of 0's and 1's you can make with 7 bits.

Importantly, different computers have to follow this standard for what everything means except for special characters such as the end-of-line character. (More on this in the “Analysis” section.)

The remainder of the RFC is the attached ASCII standard.

The attached standard

It's worth reading the scan of the document rather than the transcribed document that I link above, because the table is much clearer:

An image of the table

This table of values that says what number corresponds to what character. It's a little confusing at first because it doesn't just tell you the number straight away — in the interest of saving space and having it all printed out in a single sheet, it's a table where the columns represent the value of the first 3 binary bits and the rows are the last 4 binary bits. So the column labeled “010” and the row labeled “0110” give you 010 0110, which is the encoding for the letter capital “F”.

Interestingly, there is a pronunciation guide here! The anonymous government author takes care to note that ASCII is pronounced “AS-key” and USASCII as “you-SAS-key” (in the document itself an apostrophe is used to denote syllabic emphasis; I prefer caps).

Analysis

The choice of this encoding has made ASCII-compatible standards the language that computers use to communicate to this day.

Even casual internet users have probably encountered a URL with “%20” in it where there logically ought to be a space character. If we look at this RFC we see this:

   Column/Row  Symbol      Name

   2/0         SP          Space (Normally Non-Printing)

Hey would you look at that! Column 2, row 0 (2,0; 20!) is what stands for “space”. When you see that “%20”, it's because of this RFC, which exists because of some bureaucratic decisions made in the 1950s and 1960s.

Remember that whole thing about a HOST providing custom definitions for stuff like its end-of-line character? If you are a computer programmer you've almost certainly hated having to deal with different end-of-line encodings in different operating systems and documents. Well, by my analysis you are pretty much looking at the source of your problems when you read this RFC. My condolences.

Further reading

The Wikipedia article for ASCII is pretty good. This Engineering and Technology History Wiki is better.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

Some suggestions

RFC-19 is by John E. Kreznar of Systems Development Corporation, dated Oct 9, 1969.

This RFC is two suggestions from Kreznar on how to reduce network congestion, somewhat in the spirit of RFC-18.

Technical content

His first suggestion seems to be to change how IMPs work so they consider the local state of the HOST machines when sending messages. So like if user A and B are logged into a HOST machine and the IMP has messages for them both, but user B is the one who is actively being addressed by the computer's memory, it would make sense to send the message for B first while user B's processes are in memory, then the message for A which the HOST machine could swap user A into its active memory. If the messages came in the reverse order there would be extra swapping, slowing down the computing experience for the users.

This seems like a really bad idea to me, since it would require the IMPs to have knowledge of the internal state of the HOST machines to some degree. That said, the internet has existed for literally my entire life and these folks were building it for the first time so... I'll let it slide.

The second suggestion is that maybe for transfer of large files between two HOSTs, the HOST could “lock” the program that it's running for the duration of the file transfer. Basically a way for both computers to say “we are going to prioritize this file transfer over anything else happening on the computer right now so we can quickly transfer the file between the two of us”. On a timeshare machine this would result in users who aren't involved in the file transfer having to wait for the transfer to complete before they can continue using the computer. That seems... also bad.

Analysis

Both of these ideas aren't great. But again, no internet exists yet so I can forgive bad ideas! The whole point of RFCs at this early stage is to get as many ideas out there as quickly as possible. And it seems to be working.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

Reducing congestion

RFC-18 is another short Vint Cerf RFC from September 1969. Here is the whole thing:

It is suggested that link 1 be used for the HOST-HOST control link and link 0 be used for IMP-IMP control.

This will facilitate communication between Hosts and reduce delays due to interference with IMP-IMP communications.

Technical content

If you'll recall, link 0 has been reserved for control communications like the initial handshake between HOSTs. But IMPs need to talk to each other too, and this proposes that IMPs coordinate over link 0, HOSTs coordinate over link 1. So HOST traffic wouldn't get in the way of IMPs coordinating with each other, I guess.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

Like email but slower

RFC-17 is by John E. Kreznar of Systems Development Corporation on Aug 27, 1969. I talk about that company in more detail in my post about RFC-10, but they were the first ever dedicated software company and did a lot of early experiments in modem communication.

This is technically RFC-17 and RFC-17a. Which is weeeeird. Basically the reason for this is, RFC-17 is some questions from Kreznar about the HOST-IMP interface, and RFC-17a is a response from Bob Kahn of BB&N, who would go on to co-invent TCP/IP with Vint Cerf.

Basically this is an email thread. But you know. Two months before the first modern computer network existed and two years before the invention of email.

Technical content

Kreznar asks four questions that boil down to the same question: have we considered certain failure modes for message transmission, particularly due to the fact that it could take a long time to hear back from a remote machine?

Kahn's answer is: yes we have, it's fine.

Analysis

This is an early example of an internet person asking some questions and being told they are wrong by another internet person.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

M.I.T.

RFC-16 is a brief note adding “Abhai [sic] Bhushan” of MIT to the distribution list on August 27, 1969.

Further reading

Abhay Bhushan is an Indian computer scientist. He was a grad student at MIT at this time. He would go on to write the FTP specification and contribute to the development of e-mail.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

Proposing TELNET

RFC-15 is authored by Steve Carr, a representative of University of Utah's computer science program (UTAH in ARPANET parlance). He was present at the first Network Working Group Meetings I mentioned in my RFC-1 post. I couldn't quickly find a lot of info on him but according to this article he was a grad student of early computer graphics expert David C. Evans when he authored this. (Incidentally, Carr would have been there at the same time as one of my personal computing heroes, Alan Kay.)

Titled “Network Subsystem for Time Sharing Hosts”, this RFC is dated Sep 25th, 1969, about one month before the first message would be sent over the ARPANET.

Technical content

This RFC is really important! It proposes a program called TELNET (now called Telnet) that solves the problem of how two computers running different hardware and different operating systems can somehow talk to one another over the network.

Carr begins by pointing to RFC-11 and summarizing Déloche's list of required “network primitives” that allow a computer to talk to ARPANET:

  • Open primary connection
  • Open auxiliary connection
  • Transmit over connection
  • Close connection.

He says that these will operate at the level of system calls, “most likely a part of the resident monitor” for maximum speed/responsiveness. Both the SDS 940 and the PDP-10 offered a way for users to write their own system calls, and in the context of a time-shared computer, all users would need access to these calls.

A “resident monitor” is a tiny program that is always present in memory that is run over and over — it is resident in memory and it is generally used to monitor when critical things need to happen. Usually the available memory for this program is very small so it often is just a single instruction that says “go to this other place in memory and run the program there”. These aren't used in modern computers but similar concepts are used in the simple embedded systems you might find in a kitchen appliance.

The RFC describes how computers running different hardware and different operating systems could talk to each other in the context of a time-sharing system. The process goes:

  • log in to your local computer
  • start up the TELNET program
  • define your local escape character (so you can define “this is the button I press when I'm about to send a special command rather than just plain old typing data”)
  • TELNET makes the system call to open the network connections so the individual doesn't need to worry about it. Assuming the remote computer is accepting remote logins, we then...
  • log in to the remote computer
  • you can type like you were locally logged in on the other computer now!
  • if you want to transfer a file from your local computer, there is a special routine for sending files (make sense, since the IMPs have their own file transfer methods, which require special link connections to be opened by the system)
  • logout, presumably (never mentioned but heavily implied!)

Carr also states that Telnet needs to take up a really small amount of memory so that it's fast. Which is why it doesn't do much (there's explicitly no translating between different character sets).

Analysis

Telnet has been in continuous use since 1969, and although it began to fall out of favor in the 1990s, it's had an incredible run as far as “ways to access the internet” go. Telnet was quickly adopted although there wasn't a formal attempt to standardize it beyond this proposal until RFC-97 in 1971.

In fact, telnet was standard on all modern consumer operating systems until very very recently. Apple only stopped shipping telnet on its Macs in 2017. On a personal note, Telnet was how I first accessed the internet, via Bulletin Board Systems when I was ten years old in 1993.

In this RFC about logging in to a remote computer the word “password” is never used. In fact the only prerequisites for accessing a remote computer are: the remote computer is accepting remote logins, and the local computer has the local user cleared for connecting to remote computers. This is the modern equivalent of “if you don't want strangers logging in to your computer, deny all login attempts.” Of course, at this point all the potential users of ARPANET knew each other! So, not a big deal yet.

Carr mentions an “SPOP” on the SDS 940 system. I believe he is referring to “SYSPOP”, which functions much like a UUO does on a PDP-10. This would make sense as Carr would have been much more familiar with the PDP-10 since that's what they used at UTAH. (A PDP-10 at UTAH would eventually become the fourth node on the ARPANET.)

In a sense, Telnet is a simpler, text-only alternative proposal to the media-rich DEL system outlined in RFC-5 that was never implemented.

Further reading

A history of Telnet.

A set of notes on SDS-940 lectures given by Butler W. Lampson in June 1966. Lampson was one of the developers of the SDS 940, and would later go on to cofound Xerox PARC and help invent a million other things.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

Miss Zarves

There is no Miss Zarves. There is no fourteenth RFC. Sorry.

Further reading

Sideways Stories from Wayside School, by Louis Sachar, 1978.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

End of file

RFC-13 is by Vint Cerf. It's called “Zero Text Length EOF Message” and is dated August 20th 1969.

Vint Cerf is I think our most famous participant in these RFCs so far. Of all the names I've named here, he is probably the person who an average web developer today might have heard of. He's not a household name like a Bill Gates or Steve Jobs but for a non-billionaire he is pretty high profile! Probably for a few reasons:

  • After his ARPANET work he went on to be instrumental in the civilian internet that we all use
  • Was and is heavily involved in various important technical organizations. These include ICANN, IETF, the Internet Society, the ACM, and so on
  • He is still actively authoring RFCs! Mostly recently he's listed as co-author on RFC-7934 from 2016
  • He gets around to conferences, does a lot of speaking and generally is a kind of “face” of the internet, most recently as Google's “Chief Internet Evangelist”, a position he got in 2005 and I believe continues to hold

Of course, at the time he authored RFC-13 he was a grad student at UCLA!

The technical content

This is a very simple addendum to RFC-11 that says there ought to be a way to designate that the file you're sending over the network has reached its end. This proposes sending an empty message to communicate that to a receiving HOST.

Analysis

RFC-11 tells us what an end-of-transmission message looks like but not end-of-file, so yeah, this addendum seems needed. An empty message seems like a bad idea? But who am I to question Vint Cerf.

Further reading

I recommending just searching the web for Cerf because there is a lot out there! This Wired interview from when he was inducted into the Internet Hall of Fame (which is a thing I guess exists??) might be a decent place to start.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

Flowcharts

RFC-12 is by Michael Wingfield, and is his only RFC, dated Aug 26th, 1969. According to the Kleinrock History Center at UCLA,

Michael Wingfield designed the interface linking the SDS Sigma 7 computer at UCLA with an Interface Message Processor (IMP) in 1969 and implemented TCP/IP for Unix in 1979.

The technical content

The document is a handful of flowcharts extracted from BBN Report No. 1822. Report 1822 was BBN's documentation on how to connect a HOST to an IMP.

Analysis

Since hooking up a HOST to an IMP was literally Wingfield's job, it makes sense that he'd extract some important summary diagrams and distribute them to the RFC recipients. They probably came in handy and made sense to have as a separate reference document while you were sitting down trying to figure out the physical hookups and data interchange of these machines.

Further reading

The only available scans of BBN Report No. 1822 I can find online are from its 1976 revision, which is 7 years after this document was written and according to its own foreword varies significantly from the original. I'm going to a bunch of archives this year and I'll try to dig up a 1969 edition.

The Kleinrock History Center hosts a collection of Wingfield's documents including many from the project to hook up UCLA's Sigma 7 HOST to an IMP. A lot of these documents are electrical engineering related rather than computer science, which I think is really neat. For example, these pages contain things like impedance calculations for cables and this page has a diagram of the actual wire-by-wire connections required:

a cable crimping diagram

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.