RFC-195

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

Assumptions and their consequences

RFC-195 is titled “Data Computers — Data Descriptions and Access Language”. It's authored by George Mealy of Harvard and dated July 16, 1971.

The technical content

The author is writing in response to the minutes of the NWG meeting at SJCC as reported in RFC-164. In particular, Mealy has learned from that RFC that there's a concerted effort to work on issues of data management (data storage and data translation services) on the ARPANET, and he wants to add his ideas to the mix since he was unable to attend the SJCC meeting.

We immediately get some more of that collegial Mealy style that I highlighted in my post about RFC-91:

My main remarks are predicated on a few assumptions and their consequences.  Since some or all may turn out to be wrong, it seems appropriate to state them explicitly.

He says that the real problem facing data management is not figuring out backups, naming, etc, but rather "in reaching agreement on specifics while leaving sufficient ratholes for future expansion". In other words, the hard part is agreeing on flexible protocols and specifcations that won't screw everyone over five, ten, or twenty years down the line.

He proposes an assumption that in hindsight is very accurate: that most file access will be to parts of files, rather than entire files. That even transmission of a full file will happen piecemeal and nonsequentially.

He also proposes that they look at EL1, a language invented and implemented by Ben Wegbreit for his Harvard Ph.D. thesis (Mealy is Harvard faculty). The fact that EL1 is an extensible and strongly typed language means that complex data structures and types can be built from primitives, so you could have multiple definitions of “INT” (integer) and translate freely between them. This would be convenient for a data reconfiguration service whose job is to translate between data types. This would also allow the data computer to take “maximum advantage of the data descriptions at compile time rather than using a strictly interpretative mode of operation”.

He then discusses an “access language” for requesting ranges of data from remote files, favoring a model that abstracts away the hardware and storage specifics in favor of logical operations that let the programmer define features of a file that might help it be efficiently moved from one computer to another.

Analysis

I was really taken with Mealy's humanistic approach in both writing and in problem-solving back in RFC-91, and this RFC is no different.

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

365 RFCs