365 RFCs

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

Putting two keyboards in one

RFC-216 (PDF) is titled “Telnet Access to UCSB's On-Line System”. It's authored by Jim White of UCSB and dated September 8th, 1971.

The technical content

UCSB has implemented a Telnet server, as reported for the first time in the RFC-214 survey. This may not seem like an enormous feat, but the Culler-Fried On-Line System (OLS) is basically Mathematica or MATLAB but developed in the late 1960s. Its highly graphical nature means that figuring out a useful subset of text-only functionality is a pretty hefty design problem.

Curvilinear graphical output is thrown out, but Greek characters are simply relayed as lowercase a through z, so the letter a is the ASCII stand-in for α, b for β, and so on. The mapping isn't one-to-one, but the document provides a table with the exact mappings, and most are pretty intuitive.

The standard OLS keyboard is... anything but standard. It is literally a two-tiered keyboard!

As you might expect, the bulk of this document explains how they translate from this monster keyboard to a standard 7-bit ASCII teletype system. It's handled using an escape character (a semicolon) followed by a mnemonic code. All told it's pretty similar to putting α in your HTML to represent “α”.

The NETOLS system comes with a HELP function that will print out all the mnemonics for you. You can also change the escape character by issuing a PREFIX command! I imagine this would be really helpful for keyboards where you'd like to remap the escape character to something that is ergonomically located since you're going to be typing it a lot.

Analysis

Besides the character conversion tables, the document contains a few pages of examples of what it's like to interact with the system, which is always appreciated. Especially when entry of simple equations is as complicated as it is on NETOLS. For example, to enter the equation

x_k+1 =(x_k+N/x_k)/2

you have to enter the following program:

   ;LIST_)TYPE_%ENTER_N
   ;1_;REAL_;LOAD_;ENTER_;STORE_N
   ;TYPE_% ENTER_FIRST_GUESS
   ;1_;LOAD_;ENTER_;STORE_X
   ;TYPE_%#_OF_INTERATIONS?
   ;0_;LOAD_;ENTER_;STORE_N
   ;1_;REPT_(;LOAD_N ;/_X;+_X ;/_2
           ;STORE_X ; DISP_%/_X ;+_X ;/_2
   ;LIST_;STORE_;USER_;1_;SQRT_

Though honestly? It's not that much more complex than the <sub> tags I had to type into HTML to get it rendering! While there are all sorts of relatively-convenient ways to render mathematical notation on the internet today, I personally don't think we've come very far. You still need to learn specialty software to do it (and that might be okay, since mathematics is a specialty discipline).

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 3 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 tips

RFC-215 is titled “NCP, ICP, and TELNET: The Terminal IMP Implementation”.

The technical content

Let's back up and do some review. I'd like to talk about the Interface Message Processor (IMP) and the Terminal Interface Message Processor (TIP).

The IMP is a modem-like-thing that acts as the bridge between the computers at ARPANET host sites and the nationwide telephone infrastructure. I say “modem-like-thing” because that is what a present-day modem does for a computer: allows it to connect to telecommunication infrastructure. The IMP is what made the ARPANET possible, and RFC-1 was entirely about answering the question, “How do we connect our computers to the IMPs?”

The typical setup with an IMP is what you see in the diagram here from RFC-1:

A human sits at a terminal. A terminal is a device that is not a full computer; instead it's either a teletype (a typewriter that can receive information and type it back to you), or, if you're lucky, a keyboard connected to a monitor but lacking things like an operating system, significant memory, all that good stuff. The point is that a terminal can't do anything on its own, and its purpose is to be a device that connects to a big powerful computer in a closet somewhere.

The big computer in a closet it what talks to the IMP, which lets you access the ARPANET.

But at some point BBN decides that they could do one better and ship a new kind of IMP: the Terminal IMP, or TIP. In this 1972 paper, BBN engineers note that the ARPANET IMP infrastructure as a whole

constitutes a nationwide resource which could be made available to users who have no special facilities of their own to contribute to the resource pool. Such a user might be at a site either with no Host computer or where the existing computer might not be a terminal-oriented time-sharing system. [emphasis theirs]

The idea is that a user with a terminal (far, far cheaper than a computer) could connect directly to an IMP and access network resources without needing a computer.

According to Fenwick McKelvey and Kevin Driscoll, this new Terminal IMP

allowed up to sixty-three simultaneous connections from teleprinter or video terminals wired directly to one of sixty-four RS-232C serial ports or linked by telephone to one of sixteen optional modems[.]

So. This RFC is about the new Terminal IMP that BBN has recently been installing across the network. (According to shipping and installation manifests I found at the Charles Babbage Institute, the first TIPs shipped earlier in 1971.)

Specifically this RFC is about how TIPs handle the Host-Host Protocol, the Initial Connection Protocol, and the TELNET protocol. The author says that the biggest bottleneck for implementation was the highly limited memory on the TIP, combined with the fact that they want the TIP to support up to 64 terminals.

Since the TIP is just for connecting to the ARPANET, it has no sockets to which an external user can connect. This is because it's strictly a client rather than a server.

The TIP deviates from protocol standards in a few ways, but all of them boil down to: there is not that much memory on the TIP, and the TIP is never going to act as a server, so the TIP ignores a huge chunk of the existing protocols in order to save memory.

Further reading

For a great paper on the Interface Message Processor and its role as a broker between computers and the telecom infrastructure, see McKelvey and Driscoll's “ARPANET and its boundary devices” paper.

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 2 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.

Checking more boxes

RFC-214 is titled “Network Checkout”. It's authored by Eric Harslem of RAND and dated August 21, 1971.

The technical content

This is an update to RFC-193, which was RAND's survey of the protocols and software implemented at a bunch of host sites.

In RFC-193, five weeks prior, it looked like 7 out of 10 sites implemented NCPs that are compatible with the RFC-107 Host-Host Protocol, but apparently this is misleading. The author complains that they haven't done a thorough check of the Host-Host protocol, “mainly due to the tedium of such a process”, and that they are waiting on BBN to finish writing an automated testing tool. So the high degree of completion (now 9 out of 11 sites) is only based on very minimal tests.

Compared to five weeks ago, almost every site (barring three) now has a Telnet server, and 7 out of 11 sites have a Telnet client. It was less than half last time, so this is a huge improvement.

This isn't to say that there aren't problems. Attempting to log in to the host site at SDC causes the system to crash (presumably the remote one at SDC). And SRI NIC has a Telnet server but it doesn't work very well, processing messages incorrectly.

They ask anyone to report discrepancies via a phone call, and promise another survey in a month.

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 1 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.

BBN is walking on eggshells

RFC-213 is titled “IMP System Change Notification”. It's authored by William Cosell of BBN and dated August 20, 1971.

The technical content

This RFC lets readers know that there were some changes made to the Interface Message Processor.

IMPs can now handle four hosts each. Up to this point they could handle three hosts each. This results in a new status light for the fourth host on the IMP unit, and statistics collected on the network will necessarily collect more data.

IMPs now collect more statistics than before.

One of the statistics collected, about round-trip message time, has had its unit of measure changed.

BBN expects that none of this will effect host sites.

Analysis

This is almost certainly related to the communication issues referred to in RFC-209. BBN is now taking care to let the Network Working Group know about even minor changes that they assume won't effect the host sites, and they seem to have resigned themselves to the idea that even something as innocuous as changing backend logging code might break a user implementation somewhere for some ridiculous reason.

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, July 31 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.

Scheduling conflict

RFC-212 is titled “NWG Meeting On Network Usage”. It's authored by the Network Working Group Steering Committee (Crocker, Heafner, Kahn, Melvin, Vezza) and dated August 23, 1971.

The technical content

There are scheduling conflicts with the Network Working Group meeting that was announced in RFC-207 for late September. The new dates are October 10 through October 14.

The steering committee declares that the protocol implementation stage of the ARPANET is complete enough that they are in a transitional phase. The theme for the next meeting is Network usage, with a focus on what people can do with the ARPANET, rather than how to get the basics up and running.

In addition to the event mentioned in RFC-207, the meeting will include three activities on days three and four:

• a review of protocols by Alex McKenzie of BBN and Jon Postel of UCLA
• a tutorial on how to use the Network Information Center, presumably to upload and retrieve documents
• a session about the Terminal Interface Message Processor (TIP) and how one would use this new interactive IMP to access remote services

There will be cocktails and dinner Wednesday evening.

Analysis

I'm glad that the protocol review session includes someone from BBN and someone from UCLA. This means that Level 1 (IMP) and Level 2 (Host-Host) are adequately represented by people who know the most about them.

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, July 30 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.

More distribution lists

RFC-211 (PDF) is titled “ARPA Network Mailing Lists”. It's authored by Jeanne North and dated August 18, 1971.

The technical content

This RFC updates RFC-168, and consists of three different distribution list for documents related to ARPANET. As in RFC-168, List A is essentially the critical sites that need information as soon as possible, and lists B and C are for secondary sites.

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, July 29 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.

Fractions are bad

RFC-210 is titled “Improvement of Flow Control” and is authored by William Conrad of Harvard. It's dated August 16th, 1971.

The technical content

This RFC concerns the way memory allocation commands work over the Host-Host Protocol. In particular, if host A asks host B to free up X amount of memory, host B frees that up and replies with “I have freed up X amount of memory”. The author suggest that the reply instead say, “I have freed up X amount of memory and you have Y amount of total memory to work with”.

He also recommends that a request to free up memory be unable to be repeated until a reply is heard back from the other site, and reply shouldn't be sent until the other site has met all its obligations on the network in terms of memory allocation (incoming data messages, essentially).

He also says that the way the command to free up memory is issued uses a different numerical format (fractional!) from the other memory commands (absolute), and it would make sense to make all of them represent memory in the same format.

Analysis

The command in question is “give back”, known by its GVB moniker. This command is also the source of the issues that RFC-132 and RFC-154 are arguing about. In particular it's the fractional representations that are causing strife. Personally I think this author is correct and the fractions should be eliminated entire since they are clearly confusing people!

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, July 28 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.

Sorry about that, but also it's your fault

RFC-209 is titled “HOST/IMP Interface Documentation”. It's authored by Bernie Cosell of BBN, and dated August 13, 1971.

The technical content

BBN is writing to the Network Working Group to apologize for an issue with the Interface Message Processors. There's been a problem happening on the network recently where host sites would determine that an IMP was dead even though it was not. The reason for this is that BBN recently added a 30-second delay that was built into certain interactions between the IMP and a host site Network Control Program. This basically caused the NCP at the host to assume that the IMP was dead and then the NCP would shut down.

It turns out that BBN thought it would be safe to make this change because it was to an undocumented feature of the IMP. They assumed that no programmers at the host sites would be using the undocumented feature and so they assumed they could make the change on the sly and no one would be the wiser. This is unfortunately not true because the programmers at host sites are busy being extremely clever and figuring out things about the IMP that are not documented.

On behalf of BBN, the author says to host site programmers that if they encounter what appears to be a problem with the IMP, “please don't "code around" the problem or treat your IMP as a "black box" and extrapolate its characteristics from a series of experiments.” They would rather the programmer get in touch with BBN and they'll address the issue.

Analysis

I don't know whose side to take here! I think it's somewhat reasonable, especially in a small collegial environment like the ARPANET project, to assume that people won't hack away at your systems and only use the programming interfaces that you provide them. On the other hand, BBN probably should have made that clear from the 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 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, July 27 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.

Addresses from the future

RFC-208 is titled “Address Tables”. It's authored by Alex McKenzie of BBN, and dated August 9th, 1971.

The technical content

This RFC is a revision to BBN Report No. 1822, which I am still annoyingly unable to find an early version of. This contains a list of sites and their host numbers. We saw one of these lists recently in RFC-206, but this one is notable because it contains host numbers for sites that will not be on the ARPANET for another six months, including several US Air Force bases.

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, July 26 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 at Project MAC

RFC-207 is titled “A September Network Working Group Meeting”. It's authored by Al Vezza and the NWG Steering Committee, dated August 9, 1971.

The technical content

The next major Network Working Group meeting will be held over five days in late September 1971 at MIT's Project MAC in Cambridge, Massachusetts. Most participants aren't expected to attend for the whole five days but rather to pick and choose the days that are most relevant to them.

The first two days are for hardcore systems programming work: sharing demos, discussing protocols, and teaching other programmers how to use your systems.

The second two days are more general workshops on topics like the Network Information Center, the use of ARPANET for climate research, and so on. Workshop attendees need to apply in advance and have a week from publication of this RFC to make the phone call to do so.

The last day is a town hall open to NWG members and other interested parties that's intended to summarize the previous four days for people who couldn't be everywhere at once.

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.