365 RFCs

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

A simple drawing format

RFC-86 is titled “Proposal for a Network Standard Format for a Data Stream to Control Graphics Display”. It's authored by Steve Crocker and dated January 5th, 1971. (We're in 1971 now, btw!)

The technical content

This document is one result of Crocker's comment at the November 1970 FJCC conference meeting where according to Meyer's notes, Crocker said:

What about graphics proposals? I will write my own paper as a proposal. It uses the DEC 340 as a model. Modes assumes scope system a memory. Both output-input are included in standards making. I want a competent protocol to be developed out of the working group.

In this RFC, Crocker is proposing a format for the data that is sent from a remote graphical computer system to a local user. It's for sending vector drawing data over the network.

He immediately defines five acronyms:

• network standard graphics data stream (NGDS)
• network standard display list (NGDL)
• network standard stream interpreter (NGSI)
• network standard list interpreter (NGLI)
• network standard screen (NGS)

The screen itself is assumed to be square. A point on the screen is an “order pair of unsigned 16 bit fractions”. These fractions represent a proportional distance from the left hand edge and from the bottom edge. No resolution is specified, so this is a normalized unit square of length 1.0 on each side, set up like a familiar Cartesian plane from math class with the origin at the lower left and (X,Y) pairs increasing as you go up and to the right. (This different from modern displays where the origin is usually at the top left and the Y value increases as you go down from the top.)

The NGLI (aka display controller) can move the drawing beam for the CRT to a new location, increase intensity of the beam, draw a vector, or draw a character. “Drawing a character” is defined as drawing a single ASCII character and then positioning the beam directly to the right of it.

The NGDL is the actual set of lists containing instructions for the NGLI. So a “program” would be a list of commands, and the possible commands are:

• Move beam to X,Y
• Draw a line from current beam position to X,Y
• Display a point at beam position
• Display the following n characters: [list of ASCII characters]
• Execute list G relative to position X,Y and make the new “origin” the new X,Y

That last one is really important because it means you could provide a list of commands that draw a picture, and then replicate that picture in another area of the screen without having to provide the same program twice! It's the same thing as doing a 2D translation of a canvas context.

The way the data is sent over the network is that lists of these commands, formatted as simple opcodes, are sent over the network. There is also an “erase” command that erases all lists.

Analysis

Crocker lists out all the piece of the protocol and then starts from the most concrete part (the screen) working his way up to the more abstract arena of the data stream itself. This is in my opinion a smart way to get this kind of thing across to people. If you start with the tangible, you're front loading the “why this is important” bit, which keeps the reader “on your side” and interested.

The square screen makes sense because it simplifies a bunch of math.

Unsigned 16 bit fractions are interesting to me. The IEEE 754 standard for floating point arithmetic was published in 1985, so we are operating a decade and half before this standard that most people take for granted.

I want to draw attention to the character rendering system, which assumes a left-to-right writing system. This system would not be very helpful for displaying a right-to-left or top-to-bottom language. ASCII doesn't support those languages anyway so it's a moot point.

This proposal seems simple and useful for all kinds of drawing. I would approve heartily were I reading this RFC in 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 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.

Quarterly meetings

RFC-85 is titled “Network Working Group Meeting.” (with the period). It's authored by Steve Crocker and dated December 28th, 1970.

The technical content

The group has decided to hold Network Working Group meetings every three months. In the spring and fall, these meetings will be at the Spring/Fall Joint Computer Conference. In winter and summer, the meetings will be at sites where it makes sense to promote exposure of the project.

The winter meeting will be at University of Illinois. The note concludes with a promise that the upcoming meeting will be more organized than previous meetings.

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 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:

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. She has been tasked with an administrative duty, which is a management antipattern that continues to this day.

For more reading on women in the ARPANET project, chapter eight of Claire L. Evans' Broad Band goes into detail.

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.