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