RFC-5

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

DEL – the rich application layer that never was

RFC-5 was published June 2, 1969 and authored by Jeff Rulifson of Stanford Research Institute. It's a really interesting one to me. It's the first RFC that I would call extremely technical, in that it appears to be the distribution of a technical paper that was presented by Rulifson on February 13 of that year. The paper is about DEL, the Decode-Encode Language.

But what is DEL? Well, it makes a lot more sense in the context of RFC-1, which describes the problem that DEL is trying to solve. Since sending a message over the network was estimated to take a half-second delay, if you naively sent every keystroke to a remote computer, you would need to wait at least a half second between every keystroke in an interactive console. So instead of naively sending every keystroke over the network in its own message:

A better solution would be to have the front-end of the remote program — that is the part scanning for <- and <CR> — be resident in our computer. In that case, only one five character message would be sent, i.e., H E L P <CR>, and the screen would be managed locally.

We propose to implement this solution by creating a language for console control. This language, current named DEL, would be used by subsystem designers to specify what components are needed in a terminal and how the terminal is to respond to inputs from its keyboard, Lincoln Wand, etc. Then, as a part of the initial protocol, the remote HOST would send to the local HOST, the source language text of the program which controls the console.

(Above quoted from RFC-1.) The idea is to not send data until the carriage return (<CR>, what would would call the Enter or Return key today) is pressed and then send that data all at once to the remote computer. Basically it batches local interactions and only sends them over the network when it makes sense from a user experience standpoint to wait a second for a response from the remote computer.

That's the first part of DEL. The other part of DEL, which was incredibly ambitious, was for sending essentially any kind of data including interactive graphical user interfaces and have it display cross-platform on basically any kind of computer.

Spoiler alert: DEL was never actually used in production. More on this later.

A Lincoln Wand, btw, is a kind of light pen and tablet input device invented by Larry Roberts at MIT Lincoln Labs. Kind of like a Wacom drawing tablet today. It was invented around the same time as the computer mouse and was one of the early “accepting x-y input from a user” devices. As I mentioned in my article about RFC-3, Roberts was known as the “father of ARPANET”, and died very recently on December 26, 2018. Lincoln Lab is still around and still doing US Department of Defense work.

The technical content

The document is laid out like a full paper, with an abstract and a foreword (misspelled “forward”). The foreword states:

The initial ARPA network working group met at SRI on October 25-26, 1968.

Which is good to know! It also means that it was almost exactly a calendar year between that first Network Working Group meeting and the first message sent over the network on October 29, 1969. It also means that it was about 6 months of NWG meetings until Steve Crocker wrote the first RFC. Also of note is that “It was generally agreed beforehand that the runmning of interactive programs across the network was the first problem that would be faced.”

The abstract does technically describe what DEL is for but not nearly as well as the part I quoted from RFC-1 above. It's your usual unhelpful scientific paper prose. The document as archived at the IETF is also extra difficult to understand because the block diagram illustrations have been converted to exceedingly unhelpful ASCII art during transcription.

DEL is paired with a subsystem called NST (Net Standard Translators) which basically translates any message from a sending computer that's not a meta command into a character set that the receiving computer can read. Recall that these computers could be using entirely different character encodings from one another, so the numerical value that represents the letter A could be different from one computer to the next.

There is a whoooole bunch of very technical specification of DEL syntax that frankly I am not going to take the time to learn in a day.

In addition to bundling and translating strings of character data, there is also code for passing along vector data over the network for graphical displays! Really cool how they are normalizing all the vector data to values between -1 and 1 (with 0,0 at the center of the screen) so you can send things from a display of arbitrary resolution to a display of a totally different arbitrary resolution.

I also like this warning:

It is assumed that all arithmetic and bit operations take place in the mode and style of the machine running the code. Anyone who takes advantage of word lengths, two’s compliment arithmetic, etc. will eventually have problems.

Because the hardware architecture of these computers could be so vastly different in this era (as everyone was making things up as they went along), there could be fundamental mismatches with how things like long numbers are stored. The classic example of this (possibly not what they are referring to here but the principle holds) is that some processors store numbers “big-endian” and some processors store number “little-endian”. This is an oversimplifcation but basically: if you want to represent a number large enough that it takes up more than one chunk of memory, what order do you store the number in? Like if the number consists of A combined with B and it takes two chunks of memory do you store it A B or B A? Some computers do it the first way, some do it the second way. This means that low-level math operations that work on one kind of computer will totally fail to work on the other kind of computer. I'm sure there were other incompatibilities between these machines that I'm not even thinking of, but that's the first one that comes to mind. Hence the warning. (More on “endianness” here.)

I mentioned that the paper doesn't do a great job setting things up in its abstract but it does manage to do something that a lot of modern computer science papers still don't do: it includes an example program at the end, which I imagine would be very very helpful to anyone trying to write their own translator in DEL.

In addition to the usual suspects we've seen so far, the distribution list at the end (people to whom this RFC was to be sent) includes one Mehmet Baray at UC Berkeley. This is the first mention of Berkeley in an RFC and the first mention of Baray. I can't find much information on him except that he's Turkish and got his Ph.D. in Electrical Engineering and Computer Science at UC Berkeley in 1970. This means he was probably a grad student assisting in these efforts at this time, but I'd love to know more.

Analysis

I'd never heard of DEL so I thought I'd look up what became of it, and at least according to Wikipedia it was never used. From the Wikipedia page for Jeff Rulifson:

He described the Decode-Encode Language (DEL), which was designed to allow remote use of NLS over ARPANET. Although never used, the idea was small “programs” would be down-loaded to enhance user interaction. This concept was fully developed in Sun Microsystems's Java programming language almost 30 years later, as applets.

“NLS” was Doug Englebart's amazing interactive GUI system that I've mentioned here before. The comparison to applets is apt; if implemented, DEL would have allowed for very complex, highly interactive graphical applications to be run over the network. This whole idea for DEL was scrapped by Spring of 1969 when BBN delivered the specification for HOST-IMP interaction. Here's a quote from Steve Crocker himself in RFC-2555, a historical look at 30 years of RFCs published as an RFC itself in April 1999 (twenty years ago, aaaaa):

When BBN issued its Host-IMP specification in spring 1969, our freedom to wander over broad and grand topics ended. Before then, however, we tried to consider the most general designs and the most exciting applications. One thought that captured our imagination was the idea of downloading a small interpretative program at the beginning of a session. The downloaded program could then control the interactions and make efficient use of the narrow bandwidth between the user's local machine and the back-end system the user was interacting with. Jeff Rulifson at SRI was the prime mover of this line of thinking, and he took a crack at designing a Decode-Encode Language (DEL) [RFC 5]. Michel Elie, visiting at UCLA from France, worked on this idea further and published Proposal for a Network Interchange Language (NIL) [RFC 51]. The emergence of Java and ActiveX in the last few years finally brings those early ideas to fruition, and we're not done yet. I think we will continue to see striking advances in combining communication and computing.

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.

365 RFCs