365 RFCs

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

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

A resource to be shared

RFC-90 is titled “CCN as a Network Service Center”. It's dated January 25th, 1971 and authored by one Robert T. Braden of the UCLA CCN.

The technical content

Braden was hired as Manager of Programming at the UCLA CCN some time around 1968. In a 2014 interview, he states that

the original purpose of the ARPANET was to do resource sharing and we were to be a resource to be shared.

This RFC is the first attempt of the CCN to invite the world to share in their resources via the ARPANET. It documents some of the services they made available to RAND and invites “requests and comments from other sites” for further services.

The CCN site offers an IBM 360 Model 91. This computer was extremely different from the computers at other ARPANET sites. As Braden explains in the 2014 interview referenced above:

The IBM system is a batch processing system, so we could supply batch remote job entry service over the ARPANET with the IBM mainframe. Almost all the other ARPAnet sites were computer science research outfits, usually university departments, who almost always had DEC 10, TOPS 10 systems; and used ASCII. Of course, IBM used EBCDIC character encoding, so there was a fundamental communication barrier. The IBM operating system wasn’t programmed, wasn’t designed, to be easily extended by customers. As a result our relationship with IBM was dicey at times, there was a little bad blood. For example, the first thing we had to do was to “invent” interprocess communication for OS/MVT. IPC is a fundamental function in an operating system, but it did not exist in the IBM system, so we designed one, the Exchange, and added it to the kernel as a Supervisor call. I say we; we didn’t invent IPC, of course, I was aware of the concept from the Project Mac work.

The computer offered a bunch of programming language compilers and assemblers, and file utilities. They also had an implementation of the Culler-Fried On-Line System available so users could do things like plot complex mathematical functions.

The CCN uses the RJS system described in RFC-88 (co-authored by Braden) for remote access.

Analysis

The CCN offered about “500 M bytes” of storage at a rate of “5s per kilobyte per month”. Assuming that's 500 million bytes, and I'm not sure what “5s” is but assuming that's $0.05, we are looking at $250/month which works out to about $1,570/month in 2019 dollars. And that's just the storage cost, though I imagine people used a fraction of the maximum per-user allotment.

According to this RFC, “Batch charges are based upon t(CPU time), I(number of I/O requests), and R(core memory region size).”

On the topic of funding, Braden mentions in the 2014 interview that

Connecting to the ARPANET was in a sense a hobby; ARPA did not pay for it. They said, “You make your money from sellingtime and we expect you to fund the software development yourselves.” At that point we needed ARPA’s money to survive financially, so we did the software.

Further reading

Bob Braden died in April 2018. For more on Braden:

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

Historic moments

RFC-89 is titled “Some Historic Moments in Networking”, authored by Bob Metcalfe of MIT's Project MAC, who would eventually go on to co-invent Ethernet among many other notable achievements. The RFC is dated January 19th, 1971.

The technical content

This RFC outlines some of the accomplishments of Project MAC. I'll write in the past tense rather than my usual present tense because the RFC is discussing past events.

They connected the MIT MAC Dynamic Modeling/Computer Graphics PDP-6/10 System (MITDG for short) to a Multics terminal. Essentially, they managed to get a PDP-10 connecting to a Multics OS and acting as a remote terminal for Multics. Though there were some problems; for example, their interface uses only ASCII characters to communicate, but in Multics a QUIT command is not natively an ASCII command in the same way that LINE FEED is, for example. They suggest that maybe an interrupt signal could stand in for QUIT. There is also no support for RUBOUT (what we call the “delete” key today).

They connected their MITDG to the PDP-10 at Harvard University. This is historic because the MITDG system is line-oriented, but the Harvard system is character-oriented. The complexities of incompatibilities between these types of systems were discussed at length at the November NWG meetings, and I think Metcalfe wants to show that they managed to overcome this in one case. Metcalfe reports the connection and the overall interactive experience to be as fast as sitting at the terminal in person, which is exciting considering the complexity of “two time-sharing systems, three user level processes, and three IMPs, all connected in series”.

And finally, they “received graphics programs and 3D data from Harvard's PDP-10, processed them repeatedly using our Evans & Sutherland Line Drawing System (the E&S), and transmitted 2D scope data to Harvard's PDP-1 for display.” This is pretty cool, coordinating 3 different machines to generate, transform, and display 3D data over the network! Unlike the previous experiment mentioned, it was apparently a very slow connection.

Analysis

All of these experiments were conducted on the “interim interim NCP” (IINCP) while they waited for the “interim NCP” (INCP) to be completed! I think that's what we'd called a pre-release alpha today but I think I'm going to start using “interim interim” from now on.

The bit about QUIT and RUBOUT not working via remote terminals is amusing to me, because I still sometimes encounter a variant of this problem. If you've ever SSH'ed to a a remote computer, especially on Windows via PuTTY, sometimes “delete” and “ctrl+c” to quit a process aren't correctly processed by the connection and you have to mess around in your settings to fix it.

There is a note at the end that they had to “bend over backwards” to implement message marking, so that is still a big big point of contention. The author is in favor of double padding rather than padding and marking.

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

Punch cards and printers

RFC-88 is called “NETRJS – A Third Level Protocol for Remote Job Entry”. It's authored by Bob Braden of UCLA (a professor there, not a grad student), and Stephen M. Wolfe, also of UCLA, who was last heard from in RFC-38.

The technical content

Once again we hear about levels, this time about a “third level protocol”, which is essentially a protocol that operates via the Host-Host protocol and the NCPs. NETRJS stands for NETwork Remote Job Service. The normal, non-network RJS is a system at UCLA's Campus Computer Network, or CCN.

This protocol lets you, for example, enter a batch of Fortran commands on a punch card system and then send them over the network to a computer to process as a “job”. You can also log in to the remote computer and ask it for the status of your job. You can submit a “stack of consecutive jobs” as well.

There are five different “channels” in play during a connection, although only two are open the whole time: operator input and operator output. So there's a constant open I/O stream, and then the other channels types are tied to specific devices: card readers, printers, and punches. These devices open connections as needed, only when they are in active use.

There's a section in the document about error checking. The authors assume that the IMP-IMP communications will have basically no errors, and that the IMP-Host interface “will either be reliable or fail catastrophically; it seems unlikely that “drop-outs” or other random failures will occur.” So they provide some crude error checks like a sequence number for each transmitted block of data so you can at least see if things are arriving in order.

The data block format is then laid out in the RFC.

Analysis

What strikes me the most about this RFC is it seems pretty normal and straightforward. As though defining network protocols is become less experimental and more routine. Login flow and message delivery in this document would be familiar to anyone who's used the Host-Host protocol, and marking is addressed by asking the reader to please be nice and send messages with boundaries at multiples of 8 bits.

There's a note at the end of the document that says:

We use the phrase “starting a session” rather than “logging on” because RJS has its own log on procedure, which is, we suppose, a fourth-level protocol.

This is the first we hear of a potential fourth level protocol!

Further reading

There's a brief instruction manual for the RJS available at the Internet Archive. It's pages 33, 34, and 35 of Scenarios for using ARPANET at the International Conference on Computer Communication, from 1972. The pages are somewhat out of order so make sure you're going by the page numbers at the bottom of each page as you read.

The RFC mentions “Hollerith cards”, which reference Herman Hollerith, who invented the punch card system for mechanical tabulation machines. They weren't using Hollerith's actual cards in 1972 but rather an ANSI standard named in honor of Hollerith. There's a 1980 book by Charles E. Mackenzie called Coded Character Sets: History and Development, which you can read 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.

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

A network graphics meeting

RFC-87 is called “TOPIC FOR DISCUSSION AT THE NEXT NETWORK WORKING GROUP MEETING” and is written by Al Vezza of MIT and dated January 12th, 1971.

The technical content

There's going to be a “network graphics meeting” held at Project MAC in April 1971 and they'd like to figure out the format of the meeting. The idea for the meeting is:

  • it will be two full days
  • every participating organization should have at least an oral presentation prepared on work they've been doing
  • most of the two days will be presentations followed by Q&A
  • the last 3 hours of the second day will be allotted to other discussion

Appropriate content for the oral presentations will be:

  • detailed description of graphical computing facilities (existing or planned) that will be connected to the network
  • a detailed functional description of a purely theoretical graphical computing facility
  • network graphic protocol proposals
  • insight from personal experiences in network graphics (this would be for non-packet-switched networks; such network graphics did exist in 1971 and experience with these systems would probably provide valuable lessons)

They are going to use the February Network Working Group meeting in Illinois to plan this April meeting further.

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