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.


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.