365 RFCs

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

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

Reddy Dively

RFC-84 is called “LIST OF NWG/RFC's 1-80”. It's by Jeanne B. North, who was a research analyst at SRI/ARC. It's dated December 23rd, 1970.

The technical content

This is a list of all RFCs from RFC-1 to RFC-80. It's the first published RFC to act as a directory for RFCs.

Further reading

Here are some photos of North from her time as NIC supervisor. She was also known as Reddy Dively at various points in her career, so anyone who wants to search for her should probably look for both names. She was President of the San Francisco chapter of the Special Libraries Association from 1966-67, which would mean that she was one of the many information management professionals recruited to the SRI/ARC NIC. She later worked at the Charles Babbage Institute back when it was still in Palo Alto, before it moved to Minnesota. This paper discusses the impact that these women had on the development of technology in the 20th century, and mentions North/Dively.

Here's a brief bio of her from the paper I link above:

Born Jeanne M. Barto in Independence, Missouri, North earned a certificate in aeronautical engineering from Cornell (1934), a B.A. in English from State University of Iowa (1947), and a B.S. in Library Science from Columbia University (1948) (Marquis, 1958). She worked as a Junior Liaison Engineer for both Curtis-Wright Corporation and Wilson Chemical Feeders before joining United Aircraft Corporation as a librarian (‘‘SLA,’’ 1960). Later, on the West Coast, she worked for Lockheed Missile and Space Company and Stanford University (Foremost, 1970, p. 474). She seems to have legally changed her name to Reddy Dively, perhaps in the 1970s when she was working on ARPANET as a member of Douglas C. Engelbart’s team at the Stanford Research Institute (SRI). Engelbart was the inventor of the computer mouse, and ARPANET was one of the networks that evolved into the Internet (Bardini, 2000). For a short time, North was supervisor of the National Information Center, which sought to ‘‘facilitate the flow of information between sites on the Network [i.e., ARPANET] and to and from other stations’’ (‘‘Jeanne,’’ n.d.; Watson & North, 1971, p. 1). North and her husband both died on the same day in 2005.

Funny enough, I'll be combing through records at the Charles Babbage Institute in June for this very project. I wonder if I'll touch any documents that Dively/North touched.

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, March 24 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 Language-Machine

RFC-83 is titled “Language-Machine for Data Reconfiguration” by R. H. Anderson, Eric Harslem, and John Heafner of RAND.

The technical content

This RFC is a followup to RFC-80. The Form Machine is discussed at length here, though it's been changed conceptually since RFC-80 into a syntax-driven interpreter, rather than a compiler/executor. (I am not sure what the fine difference is here but they call it out right at the start!)

The Form Machine is given an input address range, and an output address range, and a pointer to the “forms” which are a set of grammars for data transformation. Then, as it processes data from the input memory, it spews transformed data into the output range. It is, in modern terms, an I/O stream.

There is a LOT in this paper, but the examples are somewhat illustrative. Check out the following definition of a replacement rule:

a(A:10),b(A:70)->(a),(E'LIT':3),(b)

What this does is: when given a bunch of ASCII, it spews out the first 10 characters of ASCII unaltered, then the EBDIC-formatted characters for LIT, then 70 more characters of ASCII unaltered. (Recall that EBDIC is a kind of ASCII competitor at this point, used by many computer systems.)

You can make rules like: if given a bunch of ASCII, calculate the length of the ASCII and then output the length as an 8-bit field then followed by the unaltered ASCII. This would allow you to easily convert the data from your program into something that, for example, the NCP could send to the IMP.

Analysis

This seems really useful.

Further reading

This is all formally written up in The Data Reconfiguration Service—an Experiment in Adaptable, Process/Process Communication, a July 1971 paper by the authors of this RFC plus a number of other RFC series contributors.

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, March 23 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 fly on the wall

RFC-82 is titled “Network Meeting Report” by Edwin W. Meyer Jr. of MIT's Project MAC. It's dated December 9, 1970.

The technical content

This document was referenced in RFC-77:

Ed Myer [sic] took notes and agreed to also prepare a NWG/RFC summarizing these meetings.

Basically, this RFC is Meyer's notes from the meetings described in RFC-77, but from his perspective. He is careful in the introduction to state that his biases will inevitably come through.

Unlike RFC-77, which is a kind of summary of major points, Meyer's notes are presented in a transcription format. These are obviouly not full transcriptions of the meeting but rather of certain salient points that Meyer felt were important enough to write down. It's interesting though, because we get to see certain ideas attributed to specific people here.

Since RFC-77 itself summarizes the meeting nicely, I won't summarize it here. I will say that if you don't often read the RFCs themselves as you read these blog posts, this is a good one to try reading. Because it's a transcript I think it's easier to follow along, even out of context, and you can kind of pretend you're a fly on the wall in these seminal meetings!

Analysis

First, and most importantly, Crocker notes that “ARPA will not pay for the coffee and pastry being served, so please chip in to help me pay for it.” Those government cheapskates.

This exchange is very interesting to me:

Meyer: The position at Project MAC is that at this point we are opposed to changes other than critical fixes. Time spent on changes is time that won't be spent on developing other necessary and interesting protocols and systems. And we at Multics have a long lead time for creation and installation of changes.

Weissman: I prefer to put in changes in one chunk, say at 6 month intervals. rather than in bits pieces.

O'Sullivan: Can't current and new systems work simultaneously?

Crocker: If the changes involve the IMP, no, because all IMPs want to operate the same system.

Meyer: The feeling at M.I.T. is that to be a success, the network needs desperately to be used operationally. If another year passes without significant operational use, it might go down the drain.

—: And documentation is critical towards motivating operational usage.

Engelbart: Perhaps we should put off graphics several months so as not to delay typewriters. Typewriters are important.

—: But would that be sufficiently impressive for DOD people?

Meyer is representing the Multics project, which is probably the most mature timesharing operating system in existence in 1970. He has a good point when he says that the network will be dead in the water if they just keep tweaking the protocols, preventing users from using it for day to day research. Englebart floats the idea of putting off graphical protocol work in order to get typewriters (teletype, I'm assuming) working. Someone unnamed replies, “But would that be sufficiently impressive for DOD people?”

This is a dynamic that I'm used to in projects, where the externality of having to impress the funders often derails good work being done. This jumps out at me because it is, I believe, the first direct reference to needing to appease DOD funders in the text of an 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, March 22 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.

Please send reading materials

RFC-81 is titled “Request for Reference Information” by W. Jack Bouknight of the University of Illinois.

The technical content

Bouknight is asking people to send him references “in the subject areas of data communications and communications theory.”

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

Adaptive mechanisms

RFC-80 is called “Protocols and Data Formats”, authored by Eric Harslem and John Heafner of RAND, dated December 1st 1970.

The technical content

The first thing this RFC does is repeat the information in RFC-79, that there's a conflict between RFC-66 and RFC-54 (or some variant of it referred to as Protocol Document 1). I assume it's because they did not receive RFC-79 before submitting this RFC.

However, this document goes further than RFC-79, in that it provides a correction for the documentation in RFC-66, with the correct sequence required for an NCP to negotiate initial communication with a remote Host.

Next, they offer a streamlined tweak on the initial connection process, one that collapses four steps of the handshaking process into two, reducing redundant information transfer in the process.

The next section turns away from NCP stuff and gets into uses for message data types as proposed by Ancona in RFC-42 (recall this is something like MIME types for HTTP messages today). First, they reference the concept of “adaptable mechanisms”, referring to something called the “Adaptive Communicator Project”, a RAND machine learning project funded by ARPA. More on this in the Further Reading section below.

They go on to describe the “Form Machine”, which is reducible to a subset of regular expressions. These expressions are capable of defining data formats, and parsing data formats. I might very well have this wrong but seems to be a way of describing a set of rules that transform different streams of data in different formats into a universal compiled language that can then be executed upon. This will be discussed in much more detail in RFC-83. They ask for input from the community on this concept.

Futher reading

The “Adaptive Communicator Project” referenced in this December 1970 document was eventually described in the March 1972 paper, “A New Approach to Programming Man-Machine Interfaces”, which is available on RAND's website today. Heafner, a co-author of this RFC, is thanked in the paper for early discussions on this. I assume these early discussions were happening at the time of this document being written in late 1970.

Here's a diagram of what an adaptive communicator is for, from this paper:

a flow diagram with CRT, microphone, tablet, keyboard, and computer network communicating with an adaptive communicator, which then communicates with a computer program

Having read the paper, this is what it looks like at first glance: a machine learning module where you can specify behaviors you want in a high level language that then adapts to whatever inputs it receives and kind of “intuits” (my language here) what the inputs mean via a set of heuristics (rules of thumb). This is some 2019-sounding stuff but in 1972. As always, we have a lot to learn from the past.

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, March 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 conflict

RFC-79 is titled “Logger Protocol Error”. It's by Edwin W. Meyer of Project MAC at MIT. It's dated November 16, 1970.

The technical content

This is a notice of a conflict between RFC-66 and “Protocol Document 1”, which I believe is RFC-54 or some revision thereof.

Basically, in RFC-54 it says that a memory/buffer allocation command can only be sent once a connection is fully established. RFC-66 wants an allocation command send right after a connection request is made, which is before a connection is fully established. This RFC tells people that they can ignore RFC-66 in this case, because this doesn't agree with the NCP protocol and the NCP is on kind of a code freeze right now.

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

Human factors

RFC-78 is called “NCP Status Report: UCSB/RAND”. It's authored by Eric Harslem and John Heafner of RAND, and Jim White of UCSB. It appears to be undated but is listed as “October 1970” on the official RFC Editor site. However, I would date this as November 1970 because in RFC-77, the tests described in RFC-78 are described:

Eric Harslem mentioned that RAND and UCSB had conducted tests of their NCP implementations last week (10 Nov 70) and that things worked well.

So I imagine this was published in late November 1970, probably between Nov 20 and Nov 30.

The technical content

The UCSB and RAND sites connected to each other in order to test their Network Control Program (NCP) implementations. These implementations worked on a technical level. They were transmitting graphics over the network (!) and apparently there were “human factors” problems with the data transmitted. But the NCPs at both sites worked on a basic level.

Analysis

Reading between the lines, I imagine what happened was something like what happens to me a lot I'm programming something involving a graphics pipeline. “YES, I can write to the screen, it compiles and works! NO, it's a garbled mess.” So probably they looked at the mess and said, “Well, the data is transmitting so we'll call that win. We still need some work to make this useful to humans.”

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

A three-day meeting

RFC-77 is called “Network Meeting Report”, dated November 20th, 1970. It's authored by Jon Postel of UCLA.

The technical content

This RFC is a report of what was discussed and agreed upon at the three-day-long Network Meeting that was proposed in RFC-75.

There are a lot of topics discussed in this meeting, and I'm not going to summarize all of them, but ones that stand out to me are as follows.

The Host-Host protocol needs reworking in several areas: error control, overload conditions, allocation of resources, status information, and system crash problems.

So basically: the Host-Host protocol needs work in all the areas that most software needs more work. Errors and edge cases.

They need TELNET to be specified fully, and there is an “immediate need” for this. Recall that TELNET is a program that allows one computer to act as a terminal to a totally different kind of computer. It was proposed in RFC-15 by Steve Carr of UTAH but has yet to be actually specified in a way that would allow for implementation. TELNET is also referred to as a “third level program”, which backs up my assumption in my RFC-66 post that the third-level is understood to be some kind of application layer.

The need for documentation, particularly online documentation, is voiced. Lots of universities are starting to ask, “What does the ARPA Network have to offer?” Interestingly, online documentation is brought up as the kind of thing that could be stored on the trillion-bit store, which we haven't heard about before. As far as I can tell this never was implemented, but the proposal was for ARPANET to have kind of a shared network hard drive accessible for everyone to use. I'm assuming this wasn't implemented because this document was written in 1971, I see references to it coming soon in 1972, and also references to it coming soon in the Fiscal Year 1975 Authorization for Military Procurement, Research, and Development.

More noise made about a graphics protocol, like DEL or NIL, though neither is mentioned by name here. A deadline of January 1st 1971 is given for people to submit papers in the form of RFCs for discussion in the new year. However there was a lot of contention (“strong feelings were expressed” is code for anger, I believe) around graphics protocols too. A large contingent present at the meeting felt that they should learn to crawl before learning to walk, perfecting text/console transfer before moving on to graphics. Others feel that graphics shouldn't even be addressed at the protocol level but rather at the application level.

There is a lot of discussion about the pace of change on the main Host-Host protocol. Most people at the meeting seem to agree that major (breaking) changes should come in batches, perhaps every six months with three months of notice so people can prepare for these breaks. The idea that protocols could be backwards-compatible is brought up as well.

There is a massive discussion revolving around the fact that different computer systems process input on a line-by-line versus character-by-character basis, and that what we might call input buffering today happens in different ways. I like this note on this part of the conversation:

“It was discovered that many people don't really know where their own systems fit in this chart and are very vague about what it means to interact with a system in a different than their own.”

There is a heartily supported proposal that future Fall/Spring Joint Computer Conferences have an ARPANET hotel with its own block of rooms and a networking lounge. That seems like fun!

They want to have meetings of about 15-30 people at a rate of about one every three months, but it's also pointed out that these meetings are good for identifying problems but bad for settling on solutions. Crocker suggests that subcommittees form to solve problems that are identified at meetings that then report back.

Peggy Karp of MITRE is annointed as the new (first official?) RFC series editor. For now the editor's job is not to assign numbers to RFCs (that's the NIC's job) but rather to categorize RFCs as “hot issues”, “current”, “out of date”, or “superseded”.

Numerous other issues are brought up and in the end:

It was felt that these were hard problems that needed more thought. Thus the meeting was adjourned with the request that people circulate any ideas or proposals as NWG/RFC's.

Analysis

Interestingly, this document proposes that TELNET needs a “call for help” feature, that gets a live operator on the other end of your connection to help you if you need it. Reminds me of features that seem “new” like Glitch's “live help” feature.

The discussion about managing breaking changes versus backwards compatibility in the protocol continues until 2019 in one form or another.

Further reading

Peggy Karp is one of the (rare) women who has popped up in these RFCs so far. For more reading on women in the ARPANET project, chapter eight of Claire L. Evans' Broad Band goes into detail. She has been tasked with an administrative duty, which is a management antipattern that continues to this day.

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

A new kind of Host

RFC-76 is called “Connection-By-Name: User-Oriented Protocol”, dated October 28th, 1970. It's authored by W. Jack Bouknight, James Madden, and Gary Grossman of the University of Illinois.

The technical content

The plan is for the University to connect to the ARPANET beginning January 1st, 1971, a little more than two months' time from the publication of this document.

This RFC describes a new kind of node on the ARPANET: a computer whose sole job is to broker with the ARPANET. This would be an extension to the current Host-Host protocol.

The basic idea is that all the actual computing is designed to happen on other computers on the internal network at the university. Their reasoning is that typical computer users at the school understand computers on the file and device level, but sockets and links and protocol stuff is totally foreign to them. They want to abstract away all of this and not even have the NCP be exposed to the user at all.

The paper talks about these protocol extensions, and also specs out what the interface computer might look like (a relatively low-power PDP-11) and how users would interact with it.

Analysis

This overall idea is really interesting: why take up resources on a computer with an NCP program constantly running when you can just offload that part to a computer on the network? It makes total sense to me.

Further reading

W. Jack Bouknight wrote a seminal paper, An algorithm for producing half-tone computer graphics presentations with shadows and movable light sources, which was published in the 1970 SJCC conference proceedings. I have mentioned those here before because they were where the first Host-Host protocol papers were published. In fact, Bouknight's paper is the very first one in the massive 700+ page conference proceedings. It's a really fun graphics paper, or at least it is if you are the kind of person who reads this blog.

I couldn't find much on Gary Grossman but he seems to have been involved with a lot of early computer music, helping Herbert Brün with a PDP-11/45 based music project in 1976.

I could find even less on James Madden, though he would co-author two more RFCs and remained on the distribution list for the Network Working Group until at least 1971.

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

See you in Astroworld

RFC-75 is by Steve Crocker of UCLA, dated October 14th, 1970 and titled “Network Meeting”.

The technical content

This RFC informs all recipients that there will be a Network Meeting at the Fall Joint Computer Conference in Houston at the Astroworld Hotel at 8pm on Monday November 16th, 1970.

The purpose is to discuss “practical use” of the network, including:

  • accounting mechanisms

  • documentation distribution

  • person-to-person message sending and message storing

  • access to systems by foreign users

Further reading

The Astroworld Hotel was, in 1970, arguably the most luxury hotel in the world, and according to this history of the hotel featured “the most expensive suite in the world”, part of its variety of Celestial Suites offered to rich visitors. The meeting was not held in one of these suites, but I like to imagine that it was (check out the PT Barnum Suite!!!). There's another incredible gallery here.

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.