365 RFCs

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

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

An experiment

RFC-96 is titled “An Interactive Network Experiment to Study Modes of Access the Network Information Center”. It's authored by Richard W. Watson of the Augmentation Research Center at Stanford Research Institute (SRI-ARC), dated February 12th, 1971.

The technical content

The RFC begins by explaining that SRI-ARC wants to provide network access to services at the Network Information Center. The original SRI-ARC Online System is a graphics-oriented one, and the author notes that they are now developing a “typewriter version”. This is presumably since the network doesn't have a graphics standard yet, though the author does not say so. By “typewriter” he means a teletype or teleprinter, and he recommends one that can print 30 characters per second as a good baseline.

The author proposes a three-month-long experiment to determine the best way to provide the NIC services throughout the network. They'd collect network statistics and subjective impressions of participants.

The paper then goes on to describe some remote connection methods that they want to try out on users. Essentially they want to see what user experience is like when individual ASCII characters are sent as they are typed (and whether this should be full duplex (simutaneous) or half duplex (taking turns)), versus sending a full line/command at a time over the network.

They mention that on the old SRI-UTAH connection it could take up to 4 or 5 seconds for a single character to be transmitted from one Host to the other.

Analysis

This seems like a good test to do.

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, April 5 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.

Paper

RFC-95 is titled “Distribution of NWG/RFCs Through the NIC”, authored by Steve Crocker on February 4th, 1971.

The technical content

Something that comes up every time I talk to people about this blog is: these RFCs are paper documents sent via the postal service. It's a mailing list, but at this point in time email had not been invented. So all of this was coordinated by secretaries at the various sites maintaining manual distribution lists.

This document notifies people in the Network Working Group that the Network Information Center (NIC) at Stanford Research Institute is going to be taking on a more authoritative role in managing offline communication between ARPANET sites.

This document makes a request that individual ARPANET sites should have a Technical Liaison Contact, who is the main person receiving the physical copies of RFCs. It's their job to notify the right people at their institution of the RFC content, so if something comes in about graphics, the liaison is supposed to notify their local graphics expert.

RFCs will only be sent to these liaisons.

RFC numbers are now being assigned by Jeanne North (aka Reddy Dively). NIC numbers (which is a separate numbering system used by SRI/NIC) are also currently being assigned by her.

If a person at an ARPANET site wishes to distribute an RFC, they can either send a document to North at the NIC, or send it themselves to everyone provided they let North know and get an updated mailing list membership from her.

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

Graphics suggestions

RFC-94 is titled “Some Thoughts on Network Graphics”, dated February 3, 1971. It's authored by Eric Harslem and John Heafner, the dynamic duo from RAND who have authored many RFCs to date.

The technical content

This document is a reaction to Steve Crocker's RFC-86, which was a simple drawing format to send over the network. They like the proposal but think it needs to be extended to be able to support drawing more complex objects.

The detailed constraints enumerated in Note 86 restrict many interesting features of the Rand display hardware that we consider necessary (from a human factors standpoint) to some current applications. [...] For example, the point, vector, and character capability of Note 86 excludes line type mode, intensity control, and many other attractive control operations; the maximum symbol sizes are too small for our large character size; the origin of all of our symbols is specified as the “centroid” of the symbol rather than the lower left corner of a virtual rectangle encompassing the symbol; under mode control for plotting purposes, the beam may not be advanced to the next character position; a 7-bit ASCII is insufficient; etc.

They make a few suggestions for a network graphics protocol:

  1. That a detailed survey of the graphics capability of the ARPA nodes be taken and that a union of current and anticipated hardware be supported.
  2. Data structures for images “should allow logical as well as pictorial representation”. I take this to mean that there be room for, essentially, annotation so that you can send logical metadata. So if you are sending a picture of a house as a series of lines, you could send not just LINE(X,Y) but LINE(X,Y, "roof") (syntax is my own pseudocode).
  3. Definitions of graphics should be sent before instances. For example, if you want to draw multiple houses and copy them over and over, the protocol should state that the house “primitive” should be defined and then multiple instances of HOUSE(X,Y). (This is something that Crocker's spec does, but I think the authors are speaking more generally now of what they want from a spec.)
  4. There should be a way to mark out rectangular areas of the screen for processing purposes. For example, you could assign one process to dynamically update one section, and a separate process to update another. Or you could mark a section of an image as static and unchanging. Or assign different sections of an image to different CRT monitors.
  5. They push their data reconfiguration language from RFC-83 as a way to do stuff like transform image data for file compression targets in addition to the obvious usage of monitor display targets.

They then suggest a completely different approach to RFC-86:

An alternative approach is to consider the situation of communication between non-minimal nodes (nodes with substantial memory and computing power).

They suggest that if an underpowered terminal connects to a remote machine with more capablity than the underpowered terminal, “the connection is invalid. A terminal should NORMALLY only connect to a program that addresses no more than its hardware capabilities.”

They also suggest a third network node that is an intermediary between the powerful graphical terminal a weaker terminal. This intermediary node would provide RFC-83 style data reconfiguration services and they tag this as an “essential part of this proposal”. Here's the network topology that they illustrate in Figure 2:

A network topology diagram showing a reconfiguration service linking two hosts.

Analysis

I don't like this proposal. I think it misses the point of having a minimal protocol with maximal compatibility. There should be a protocol like Crocker's, which then maybe has a higher level protocol on top of it that the big beefy graphics machines can use to talk to one another if they so wish. They also seem to be stretching to find uses for their data reconfiguration language. I actually really like their language but I think this is not the best place to push for it.

It also seems a little unnecessarily combative, to the point where they are missing details. I think they they missed the portion of Crocker's RFC which states that the NGLI would support primitives for intensity.

Anyway, Crocker's position is “let's crawl before we can walk and support a minimum set of maximally compatible features across the network”, whereas the RAND folks want their fancy features supported.

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

Code zero

RFC-93 is titled “Initial Connection Protocol”. It's authored by Alex McKenzie of BBN, dated January 1971 (no day of month).

The technical content

This RFC points out an ambiguity in RFC-66 and RFC-80. There is a control message sent during the initial connection “defined as 'exactly an even 32 bit number'”. It's unclear what the message type code for this message is supposed to be. This is kind of amusing because there is only one message type code currently defined (code zero), but they want things to be as clear as possible in case further message type codes are defined in the future. They suggest amending the intitial connection protocol to specify that it is, indeed, code zero.

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

Not issued

RFC-92 was not issued.

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

Thinking about users

RFC-91 is titled “A Proposed User-User Protocol”. It's dated December 27th, 1970 (so, chronologically before our last few RFCs) and authored by George H. Mealy of Harvard University.

The technical content

The RFC begins with a problem statement: namely, that the network interface has thus far been treated like generic I/O. This is inconvenient when you have no idea what is on the other side of the I/O though, as different operating systems have wildly different underlying concepts. If you're talking to another computer running the same OS over the network then it makes things really really easy to treat the network as generic I/O, but not so much when there is a mismatch.

The author proposes a User-User protocol that sits on top of the Host-Host protocol. Where the Host-Host protocol deals in messages, the User-User protocol deals in logical records.

Our point of view is that a link is a carrier of information. Information is carried in segments of a fixed maximum length called messages. That this is so is an accident, from the user's point of view; when he wishes to transmit a contiguous stream of data, he will in general, segment it in a different (from the IMP-IMP or HOST-HOST protocol view) manner — we will call his segment a record.

Basically, the user cares to do something like “write a file to the remote computer”, whereas the Host-Host protocol only wants to know about a stream of segmented messages. Mealy wants a protocol that operates on a more “human” level but has interoperability between wildly different operating systems.

There follows a protocol description but I think the more important part of this RFC is the philosophical bit at the beginnging.

Analysis

I think what Mealy is proposing here will eventually become FTP, the File Transfer Protocol. A file is a kind of logical record, and there was much effort put into FTP to make it into something that would work on all sorts of computers. In this 2014 interview with Bob Braden, he says

the IBM had a truly baroque file system, and we wanted to let customers have access to some of the features of it, whereas all the other systems were UNIX systems with a very simple file structure. So if you look at the FTP spec there’s some weirdness, complexity that’s there because I asked for it.

The “IBM” that he's referring to is the exact IBM computer that Mealy references in his intro to this RFC: the IBM 360. I don't think this is a coincidence. Mealy clearly wanted to be able to send files (or something like files) back and forth between a PDP-10 and an IBM 360.

Mealy writes in one of those collegial, casual, Feynman-esque academic styles. In some places his breezy style is really endearing.

ESC is intended as a (hopefully) unused escape hatch, for nonuse by those installations and/or applications wishing to avoid using more than four bits of the USER-USER protocol on any link. For instance, it may be desired to use a link as a bit stream, ignoring even message boundaries. If and when anarchists can achieve local agreement, more power to them!

And later:

The practical questions of implementation are something else! In the case of the PDP-10, I can pretty well see how to turn a SYS into either a LOGON request to execute a monitor command or UUO (would that they were the same) as the case might be. OS/360 is more sophisticated, unfortunately. MULTICS might make it. Naytheless, I hope that is clear that what we want to do, which is what the proto col should reflect, is quite a different question from that of how it is to be done in the context of a specific HOST system.

There is some casual sexism in this RFC, also recalling Feynman. Mealy proposes that bit flags in the protocol that are followed by data blocks be called “block flags”, and other flags be called “whyte flags”. The curious term “whyte” is footnoted as follows:

In memory of an attractive, but nonspelling, SDC secretary who could not distinguish between black and white, at least during 1957 and in manuscript form.

It's basically a bimbo joke. He could have left out “attractive” and this joke would have transitioned state from “creepy” to “mildly amusing”.

Further reading

George H. Mealy invented the Mealy machine, which is not a literal machine but a mathematical construct called a “finite state machine”, which is basically a kind of algorithmic yes/no decision flow chart that a computer or even a physical machine can be constructed to make. Mealy machines are taught widely in electrical engineering programs (or at least they were in the 2000s when I last took an engineering class). For the nerds: it's a type of state machine where the current output is dependent on both the current state and the value of all its inputs. It's an “unsafe” machine where unless you latch your inputs you can change output mid-clock cycle and end up with some nasty edge cases.

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 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. It's dated January 13, 1971.

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.

Enter your email to subscribe to updates.