365 RFCs

Commenting on one RFC a day in honor of the 50th anniversary of the first RFC.

by Darius Kazemi, July 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. There is a table of contents for all my RFC posts.

Rotating cubes on the network

RFC-186 is titled “A Network Graphics Loader”. It's authored by first-time RFC author Jim Michener, who is personnel working on the MIT Project MAC Dynamic Modeling Computer Graphics PDP-10.

The technical content

The Dynamic Modeling Computer Graphics computer at MIT Project MAC had an Evans and Sutherland Line Drawing System Model 1 (LDS-1) vector display. This RFC describes a way for network users to write graphics programs for the vector display, run them remotely, and get output from the program on their local host.

The way this happens is the LDS-1 can dump a list of all rendered line segments to a data format, and this data format is sent over the network. A remote user can send commands like “SETUP the following program, EXECUTE it 3 times, TRANSMIT the image back to me”.

A user might want to execute a program a bunch of times, with minor updates to variables between executions, to create animations, for example:

(It might be programmed to make an object appear to rotate.)  The user of the routine typically would want to set up the matrices and then "let 'er rip" with ten or twenty (or more) executions.

As these commands are sent, the DMCG computer sends back “ACKNOWLEGDE” messages so the user can be sure that each message has been received. (Though if there's a problem, an “ERROR” message with a special code depending on the error is returned to the user.)

Further reading

According to this 1973 Project MAC report, Michener did a ton of graphics-related work.

The LDS-1 was a vector display and apparently the first graphical device with its own GPU. I found this photo at this discussion between PDP-10 enthusiasts, where there are other photos as well.

Two men in suits lean on a computer about the size of a closet with a 20" display with some squiggles on it.

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.

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

Bring enough for the whole class

RFC-185 is titled “NIC Distribution of Manuals and Handbooks”, authored by Jeanne North of the SRI Network Information Center (NIC). It's dated July 7th, 1971.

The technical content

This is something of a follow up to RFC-182. The NIC asks that anyone who sends them a manual should also send enough copies that that can distribute them to all Station Agents. They request 100 copies, since they currently distribute to about 80 addresses, and they only expect the number to go up.

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.

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

Supercomputer graphics

RFC-184 is titled “Proposed Graphic Display Modes”. It's by first-time RFC author Karl Kelley of the University of Illinois, and dated July 6, 1971.

The technical content

This is yet another report on a computer graphics system being developed. This one is for the ILLIAC IV supercomputer at the University of Illinois.

Honestly the contents of this RFC are extremely similar to what we've seen in RFC-86, RFC-177, and RFC-178. The main thing of note here is the first usage in the RFC series of “viewport” and “window” as different coordinate systems relative to the user.

Analysis

The ILLIAC IV would go on to be the first supercomputer connected to the ARPANET, though it would not be fully available until November 1975.

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.

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

Character correspondences

RFC-183 (PDF) is titled “The EBCDIC Codes and Their Mapping to ASCII”. It's by Joel Winett of MIT Lincoln Laboratory and dated July 21, 1971.

The technical content

In 1971 the two most popular character encodings on ARPANET are ASCII and something called EBCDIC, the Extended Binary Coded Decimal Interchange Code. It's a character encoding invented by IBM and used on many of their systems, including a large minority of ARPANET sites.

There are characters that are represented in EBCDIC (like the “¢” symbol) that have no equivalent in 128-bit ASCII, and vice versa. These conceptual overlaps and mismatches were already discussed in detail in my RFC-110 post since it was about getting an IBM terminal to speak correctly to ASCII systems.

The author provides three different methods of substituting characters that can be used when one type of system is corresponding with the other type, and there is an attached questionnaire asking readers to reply with their favorite of the conversions. The idea is to eventually standardize this.

Analysis

The first set of character correspondences is one recommended by IBM, and it's frankly weird to me! For example, it recommends that the ASCII symbol for ! (exclamation mark) be used as a stand-in for the EBCDIC ¡ (the upside-down exclamation mark). But the author notes that this means that “another code must be used to represent” the exclamation mark. Uhhh okay??

Anyway I haven't looked ahead but I hope that the IBM-style correspondence doesn't win the survey...

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.

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

Compilations

RFC-182 is titled “Compilation of List of Relevant Site Reports”. It's authored by Jeanne North of the SRI Network Information Center and dated June 25th, 1971.

The technical content

The Network Information Center (NIC) would like to collect any reports from ARPANET sites that may be of interest to any other ARPANET sites. Things like planning reports, hardware inventories, software manuals, and so on.

The NIC's first-pass attempt involved talking to the Station Agents, who are individuals at each ARPANET site who act as kind of the local librarian, collecting all documentation for the site.

NIC expects the demand for this material is only going to increase. They ask all sites for any relevant bibliographies they might have, and also ask to be placed on the distribution lists for future reports.

Further reading

According to Elizabeth “Jake” Feinler, who would be the Director of the NIC for many years, in 1972 the NIC was sending out tens of thousands of documents each year. Eventually that number waned as electronic transfer overtook paper mailing. According to this interview with Feinler:

We were distributing, in those days, a lot of them in hardcopy, because the sites weren’t up and running yet; or if they were, they were real flaky. There wasn’t any email; there wasn’t any FTP; it was very basic.

According to this summary of the 1972 NIC operating year by Doug Englebart, the NIC had 132 addressees to whom they send “about five items a week”. This works out to about 34,000 documents a year. This doesn't include memos sent to special interest groups. From Englebart:

We maintain relatively comprehensive “ident” data for a total of 366 registered individuals, affiliation organizations, and working groups, and somehow have a telephone directory with 530 phone numbers. All of these data are accessible via DNLS and TNLS, and much of it with the very easily used QUERY subsystem. Updating these data is a religiously maintained activity. [...] Each Station Agent requires special introductory help; only a few have been sent to SRI to learn — most of them have a lot of telephone talk at first, and we try to call them regularly to check up on things.

DNLS and TNLS above refer to NLS, which is SRI's famous oN-Line System. “DNLS” refers to a display terminal connected to NLS, and “TNLS” refers to a teletype connected to the same (reference here).

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.

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

Fractional displacements

RFC-181 is titled “Modifications to RFC #177”. It's authored by John McConnell of NASA Ames Research Center and dated June 27th, 1971.

The technical content

This RFC fixes a problem with the graphics display specification in RFC-177. The problem is that the specification was supposed to make it impossible to draw outside of the border of the screen, but it turns out there are some ways to send coordinates that draw outside the border. So coordinates will now be “fractional displacements” from an origin.

There are also some tweaks made to make it easier to transform a graphics display list (aka a list of drawing commands) from one coordinate system to another.

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.

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

Tell us about your file system

RFC-180 is titled “File System Questionnaire”. It's authored by Alex McKenzie of BBN and dated June 25th 1971.

The technical content

The subcommittee working on file transfer and data transfer has decided that while they are standardizing the actual transfer of data, they are not going to standardize how file naming, path naming, and access control work. This is probably in part because there are many extremely different operating systems connected to the ARPANET. But this means that a user doing a file transfer should have access to some kind of document that explains “when you connect to a Multics host to transfer a file, this is the kind of file naming you should use.”

This RFC contains the questionnaire so that the subcommittee can compile and eventually publish all of this information from anyone planning to run a file transfer server.

They want to know things about different servers/hosts like:

  • what comprises a pathname
  • how access control works (some systems use passwords, some have separate read/write access, some require group-level access before user-level, etc)
  • basic functions of the local file system
  • how files are represented on disk (what encoding, how many bits is a word, and so on)

Responses are to be sent to Alex McKenzie, and he'll get on the phone with you if you're confused about any of this. He promises to publish the results as a future 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 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.

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

RFC-179 is titled “Link Number Assignments”, and authored by Alex McKenzie of BBn. It's dated June 22nd, 1971.

The technical content

This document updates what link numbers on ARAPNET are used for. Recall that links are, basically, physical channels.

These are the old link assignments in RFC-107:

   0          control link
   1          old protocol's control link - to be phased out
   2 - 31     links for connections
   32 - 190   reserved -- not for current use
   191        to be used only for measurement work under direction
               of the network measurement center (UCLA)
   192 - 255  available for any private experimental use.

As of this RFC, the new link assignments are:

     0                   Control link
     2-71                Available for connections
     1, 72-190           Reserved-not for current use
     191                 To be used only for measurement
                         work under the direction of the
                         Network Measurement Center at UCLA
     192-255             Available for private experimental use

So the big changes are: link 1 has now been phased out because nobody is supposed to use the old Host-Host Protocol anymore.

Links 2 to 71 are now available for general connection (2 to 31 were already open but now 32 to 71 are now available).

That's it!

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.

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

Interactive graphics

RFC-178 is titled “NETWORK GRAPHIC ATTENTION HANDLING”. It's by first-time RFC author Ira W. Cotton of MITRE, dated June 27th, 1971.

The technical content

This RFC describes ideas for “attention-handling”, aka interactive graphics, over the network. This was under-defined in RFC-177 so I'm glad to have it better defined here.

Cotton defines an attention event as “a stimulus to the graphic system, such as that resulting from a keystroke or light pen usage, which presents information to the system”. Information from the input is interpreted via hardware and software and then an immediate (emphasis Cotton's) action is taken: either the information is passed to another process, or the graphical display or its underlying data are updated somehow. This is separate from the program logic itself — basically it's the part of the program that governs immediate response to a user input, rather than any application logic of the software. It's the kind of software plumbing that powers something like an onKeyDown event in a modern scripting language.

The concept applies equally to simple input devices like keyboards, and also complex input devices that are computers in their own right.

The paper is laying out the case for a standard attention-handling system to go along with a standard graphical display system. The idea is to make things more modular. Without these standards, if you wanted to make your computer program compatible with some new light pen model, you'd need to rewrite a signifcant chunk of your program. But if the manufacturer could provide a kind of input processor program that translates from its input device to the standard attention-handling system, then you could in theory plug in a new device “for free”.

On top of that, if a user program could connect to ARPANET and send the standard attention-handling events and receive the standard graphical display primitives then that would mean you could connect easily connect your program to a beefy remote graphical processing system, send it your live interactive inputs, have it respond appropriately with the standard graphical primitives, and then render it locally on a graphical display.

The document then discusses different “graphical input devices”, including:

  • pushbuttons
    • basically keyboards
  • analog devices
    • something that turns continuous input into a numerical value, like a mouse or a trackball
    • good to use as a “pointing device”
  • tablets
    • something that converts a tap of a stylus on a 2D surface to a digital (x,y) coordinate
  • light pens
    • a pen that interacts directly with a screen, similar to a touchscreen today, though you need to use the special pen to make it work
  • internal attentions
    • these are “inputs” from inside the system itself, but intrinsic to the hardware rather than the software, like a hardware interrupt saying “you are trying to draw to a coordinate that is outside the bounds of the screen”
  • logical attentions
    • this is like an “internal attention” but based on a software rule rather than something baked into the hardware

The document then discusses what an “intelligent terminal” is, though the author doesn't seem to be able to settle on something concrete.

The last, very brief, section of the RFC is an attempt to suggest a protocol for the different kinds of attention, though the intent is not "to formally propose such a protocol down to the level of 'this bit means that'". The authors propose that any protocol will need to be able to identify the type of device, identify the related data for the event being communicated, and then carry the data itself.

Analysis

In the transcribed official versions of RFC-178, we see this text:

   Figure 3 Network Configuration (Omitted due to complexity)

   Figure 4 Network Configuration with Intelligent Terminal (Omitted due to complexity)

As far as I'm aware, these figures are not available anywhere online. I found the original diagrams at the Computer History Museum archives and took some photographs. Here they are!

A "Network Configuration" diagram that shows a serving host's "graphic application program" talking via a "network standard" to the ARPANET infrastructure, with a using host processing I/O from that program via a "Network Standard Display List" and a "Network Standard Attention" protocol.

Similar to the above diagram but with the "using host" broken out into the host itself and then an "intelligent terminal" on the backend.

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.

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

Another crack at a graphics interface

RFC-177 is titled “A Device Independent Graphical Display Description”. It's authored by John McConnell of NASA Ames Research Center, and dated June 15th, 1971.

The technical content

This is an update of RFC-86, which is a proposal for a network graphics language that is similar in a lot of ways to modern 2D HTML canvas API. This update takes into account some of McConnell's critique of RFC-86 as laid out by him in RFC-125.

The author specifies a text-rendering mode that respects carriage return, line feed, backspace, and other position-control type characters, as he suggested in RFC-125. There is robust support for, essentially, grouping drawing commands as lists and executing them in groups. The idea being maybe you want to draw a vector house and label it “house” and then repeat that multiple times on the screen. Lists can be scaled and rotated as well as translated.

The system operates in two modes: vector mode (for drawing lines) and character mode (for rendering text). The data primitive for both modes is two 8-bit bytes. The first byte is the same in both modes and contains a true/false “blink” bit, 4 bits for a brightness level, and 3 bits for color (”One bit for each primary”.) For the vector mode, the second byte contains 2 bits to specify one of four “textures” (solid, dashed, dotted, dot-dash) for the lines, and for character mode the second byte contains 2 bits for text orientation (which of four 90° angles to render text along) and 3 bits for text size.

The RFC concludes with some ideas for how the system might work in an interactive (rather than static display) scenario, interacting with a light pen or that kind of thing. In particular, the author describes synchronous and asynchronous devices, with the latter proving more difficult to account for. Unfortunately I find his description of what these are lacking so I can't really comment on them.

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.

Enter your email to subscribe to updates.