by Darius Kazemi, June 15 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-166 is titled “Data Reconfiguration Service — an Implementation Specification”. It's authored by the Data Reconfiguration Committee, consisting of R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood, and dated May 25th, 1971, one week after SJCC.

The technical content

This RFC is a spec for the Data Reconfiguration Service (see RFC-83 and RFC-138 for background). In brief, it's a service that anyone on the ARPANET can access that lets you specify in a custom language a list of rules you want it to enact on a data stream. For example you could put in rules that say “translate the first 50 bytes of a message to ASCII and insert the letter 'e' in between each letter of the message”. The idea is you could easily translate from one data format to another as needed but you wouldn't need to know a specific programming language to do it, and by using the network you wouldn't even need to have the software installed yourself. It is, as I mention in my article on RFC-138, basically what we know as a web service or a web API today.

The way the DRS works is: the user connects to it through a “control connection”. This is where the user specifies the rules for transforming data that the user would like to run on a data stream. Then the user hooks the program that needs data translation services into the “user connecton”. And lastly, there is a “server connection” that connects the DRS to its own host server.

+------------+              +------+          +---------+
| ORIGINATING|     CC       | DRS  |    SC    | SERVER  |
| USER       |--------------|      |----------| PROCESS |
+------------+     ^        +------+     ^    +---------+
                |           /         |
                |        UC/ <-----\  |
                |         /         \ |
                |   +-----------+    \|
TELNET ---------+   | USER      |     +-- Simplex or Duplex
Protocol            | PROCESS   |         Connections
Connection          +-----------+

       Figure 1.  DRS Network Connections

The control connection uses the TELNET protocol for communication, so the idea is you TELNET from your local terminal directly to the DRS, which is always listening on a well-known socket number at its site. You then give a six-character user ID, and then there are some simple commands for entering a form in the Form Machine Language (yes, FML) and then specifying which sockets you'd like to connect to from your actual program that you plan to hook up to it.

In addition to the above situation where a user wants to connect a process they are running to the DRS for its services, there is also a more “interactive” REPL-style mode. This is where you pretty much just log in via the control connection and hook your user connection back up to your own Telnet process!

The remainder of the document is about the Form Machine Language itself and also discusses the mechanics of input/output streams (via input and output pointers). The language supports arithmetic, translation between different literal types (binary, octal, hex, EBCDIC, ASCII), truncation, deletion, paddding, insertion of fields, parsing of variable length records, string length computation, and more. It is very similar in its core capabilities and purpose to something like sed, a UNIX “stream editor” which was developed just a few years later, though Form Machine Lanugage doesn't support regular expressions.


Moreso than other RFC specs, this one seems really well-written. I could imagine implementing my own DRS service in a language of my choice using this spec.

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.