RFC-86

by Darius Kazemi, March 27 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 simple drawing format

RFC-86 is titled “Proposal for a Network Standard Format for a Data Stream to Control Graphics Display”. It's authored by Steve Crocker and dated January 5th, 1971. (We're in 1971 now, btw!)

The technical content

This document is one result of Crocker's comment at the November 1970 FJCC conference meeting where according to Meyer's notes, Crocker said:

What about graphics proposals? I will write my own paper as a proposal. It uses the DEC 340 as a model. Modes assumes scope system a memory. Both output-input are included in standards making. I want a competent protocol to be developed out of the working group.

In this RFC, Crocker is proposing a format for the data that is sent from a remote graphical computer system to a local user. It's for sending vector drawing data over the network.

He immediately defines five acronyms:

The screen itself is assumed to be square. A point on the screen is an “order pair of unsigned 16 bit fractions”. These fractions represent a proportional distance from the left hand edge and from the bottom edge. No resolution is specified, so this is a normalized unit square of length 1.0 on each side, set up like a familiar Cartesian plane from math class with the origin at the lower left and (X,Y) pairs increasing as you go up and to the right. (This different from modern displays where the origin is usually at the top left and the Y value increases as you go down from the top.)

The NGLI (aka display controller) can move the drawing beam for the CRT to a new location, increase intensity of the beam, draw a vector, or draw a character. “Drawing a character” is defined as drawing a single ASCII character and then positioning the beam directly to the right of it.

The NGDL is the actual set of lists containing instructions for the NGLI. So a “program” would be a list of commands, and the possible commands are:

That last one is really important because it means you could provide a list of commands that draw a picture, and then replicate that picture in another area of the screen without having to provide the same program twice! It's the same thing as doing a 2D translation of a canvas context.

The way the data is sent over the network is that lists of these commands, formatted as simple opcodes, are sent over the network. There is also an “erase” command that erases all lists.

Analysis

Crocker lists out all the piece of the protocol and then starts from the most concrete part (the screen) working his way up to the more abstract arena of the data stream itself. This is in my opinion a smart way to get this kind of thing across to people. If you start with the tangible, you're front loading the “why this is important” bit, which keeps the reader “on your side” and interested.

The square screen makes sense because it simplifies a bunch of math.

Unsigned 16 bit fractions are interesting to me. The IEEE 754 standard for floating point arithmetic was published in 1985, so we are operating a decade and half before this standard that most people take for granted.

I want to draw attention to the character rendering system, which assumes a left-to-right writing system. This system would not be very helpful for displaying a right-to-left or top-to-bottom language. ASCII doesn't support those languages anyway so it's a moot point.

This proposal seems simple and useful for all kinds of drawing. I would approve heartily were I reading this RFC in 1971.

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.