365 RFCs

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

Mail box

RFC-196 is titled “A Mail Box Protocol”. It's authored by Richard W. Watson of SRI-ARC and dated July 20, 1971.

The technical content

Let's get it out of the way: this is not the invention of the modern protocol for email. It's a proposal for something that acts a hell of a lot like email, though.

This “Mail Box Protocol” is a way for a Host computer to have a file that gets continously appended with the content of inbound files sent to a “mail box”. Each file sent to the mailbox has a unique identifier to denote its boundary, so you could use a program to browse one sub-file after another. If these were text files, you would in fact have something that looks a lot like email.

This is being proposed because the NIC would like to send documents and messages to remote sites, and to receive them as well, “without having to know the details of path name conventions and file system commands at each site”.

In Watson's words,

A mail box, as we see it, is simply a sequential file to which
messages and documents are appended, separated by an appropriate
site dependent code.

The Mail Box protocol uses the Network Control Program, the Initial Connection Protocol, and the Data Transfer Protocol. So they are not reinventing the wheel here. Files are to be 7-bit ASCII, which to me implies that they really want this for the transmission of text documents like RFCs, rather than more complex data types.

The idea is that incoming messages can be held on disk storage for later printing, or simply read on a screen. But it's kind of amazing that they do suggest having a printer set up to just automatically print out all incoming mail!

They recommend that all messages sent to the NIC (which would be given mail box number 0) contain a header with the sender's name and address (presumably postal address?), and the receiver's name and address “formatted in some reasonable, easy-to-read form for a clerk to read and distribute”.

The author also recommends that socket number 5 be reserved for incoming Mail Box connections.

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 14 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.

Assumptions and their consequences

RFC-195 is titled “Data Computers — Data Descriptions and Access Language”. It's authored by George Mealy of Harvard and dated July 16, 1971.

The technical content

The author is writing in response to the minutes of the NWG meeting at SJCC as reported in RFC-164. In particular, Mealy has learned from that RFC that there's a concerted effort to work on issues of data management (data storage and data translation services) on the ARPANET, and he wants to add his ideas to the mix since he was unable to attend the SJCC meeting.

We immediately get some more of that collegial Mealy style that I highlighted in my post about RFC-91:

My main remarks are predicated on a few assumptions and their consequences.  Since some or all may turn out to be wrong, it seems appropriate to state them explicitly.

He says that the real problem facing data management is not figuring out backups, naming, etc, but rather "in reaching agreement on specifics while leaving sufficient ratholes for future expansion". In other words, the hard part is agreeing on flexible protocols and specifcations that won't screw everyone over five, ten, or twenty years down the line.

He proposes an assumption that in hindsight is very accurate: that most file access will be to parts of files, rather than entire files. That even transmission of a full file will happen piecemeal and nonsequentially.

He also proposes that they look at EL1, a language invented and implemented by Ben Wegbreit for his Harvard Ph.D. thesis (Mealy is Harvard faculty). The fact that EL1 is an extensible and strongly typed language means that complex data structures and types can be built from primitives, so you could have multiple definitions of “INT” (integer) and translate freely between them. This would be convenient for a data reconfiguration service whose job is to translate between data types. This would also allow the data computer to take “maximum advantage of the data descriptions at compile time rather than using a strictly interpretative mode of operation”.

He then discusses an “access language” for requesting ranges of data from remote files, favoring a model that abstracts away the hardware and storage specifics in favor of logical operations that let the programmer define features of a file that might help it be efficiently moved from one computer to another.

Analysis

I was really taken with Mealy's humanistic approach in both writing and in problem-solving back in RFC-91, and this RFC is no different.

Further reading

Mealy cites this paper: “The Treatment of Data Types in EL1”, by Ben Wegbreit. EL1 is a strongly typed language, and also somewhat Lisp-like in nature.

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 13 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.

Stack machine

RFC-194 is titled “The Data Reconfiguration Service — Compiler/Interpreter Implementation Notes”. It's by Cerf, Harslem, Heafner, Metcalfe, and White, and undated but presumably was published in July 1971.

The technical content

This is more output from a subcommittee. This lays out technical changes to the Data Reconfiguration Service language/service, previously detailed in RFC-83 and RFC-138. Among these is a new assignment operator, .<=., which is essentially a “deep assignment” that fully assigns the attributes of one identifier to another. There's a concatenation operator, and some new data types for base 10 representation of EBCDIC and ASCII codes.

I love their description of the CPU as "a box full of miscellaneous parts, the most important being the Arithmetic Logic Unit and the instruction decoding unit". They provide a really nice box diagram of a generic CPU in Figure 2. The CPU for the DRS uses a reverse Polish notation instruction set, though they use the less common in 2019 terminology “Polish postfix”.

The CPU is a stack machine, which I had not heard of before looking it up just now. It's a computer that uses a stack (last-in, first-out) instead of a series of registers to store critical memory. So if you want to add two numbers, instead of putting one in register A and one in register B and then asking the ALU to do an “add”, you instead just tell the ALU “add” and it pops the two most recent values off the stack and adds them together.

There's a lot of detailed information in the document. The instruction format uses 16-bit instructions comprised of a 4-bit opcode and 12 bits for a literal or identifier reference, which is necessary because the architects expect more than 256 literals and identifiers combined. What's interesting to me is that the instruction has the 4-bit opcode, but one of the opcodes is the opcode for “operator”, at which point the 12 bits contain an identifier further specifying another opcode. The other “opcodes” are more like data type tags: this instruction contains an address, this contains a literal reference, this contains an integer constant, etc.

There's a lot of extremely detailed reference to how the stack machine works, and liberal usage of the acronym “TOS”, meaning “top of stack”. There's enough information here that someone could probably write a full emulator for the Data Reconfiguration Service as it existed in July 1971!

Analysis

Broadly, this RFC is a great read if you are a nerd, and also I really, really want someone to write an emulator.

When I was checking the online records versus the paper originals, I noticed a transcription error in Figure 1, “Form Interpreter.” The arrows connecting “inputstream” and “outputstream” to “CPU” are in reverse direction. Here's the original and the online version.

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 12 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.

Checking the boxes

RFC-193 is titled “Network Checkout”. It's authored by Harslem and Heafner of RAND, and dated July 14, 1971.

The technical content

The RAND site is in charge of maintaining up-to-date knowledge of compatibility with network services at different host sites. This RFC is their update to the Network Working Group, in the form of a feature grid.

Worth noting is that the RFC-107 version of the Network Control Program is fully implemented at 7 out of 10 sites, compared to the RFC-1 version that was only ever implemented at 5 of these. The site with the most software capability is the Sigma 7 at UCLA, which makes sense as this was one of the first computers to be part of the ARPANET project. In fact, it may look on the chart like it's missing one piece of capability, a “telnet-like protocol”, but that's actually a stopgap protocol that is unofficial, but included since it's used at 3 sites.

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 11 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: the big picture

RFC-192 is titled “Some Factors which a Network Graphics Protocol must Consider”. It's authored by Richard Watson of SRI-ARC and dated July 12, 1971.

The technical content

This is a philosophical RFC that is a response to the (many, many, too many in my opinion) RFCs that have been published to date on network graphics protocols. The author believes that the published protocols to date are not complete enough to cover all use cases for interactive graphics.

The author argues for the utility of a generic graphics terminal, similar to the virtual terminal concept in the latest NETRJS RFC. He estimates that about 75% of use cases for remote graphics timesharing use simple graphics terminals that display graphics but can't animate (storage tubes, more on this later), about 20% would require displays that refresh quickly, and maybe 5% require maximum cutting-edge graphical power. The author is concerned with the 95% of cases rather than the 5%.

He lists a bunch of requirements for the systems design of a network graphics protocol. Most of them are pretty straightforward and have been addressed by previous proposals, but the one that stands out to me is:

      3) The software support should allow technicians, engineers, scientist, and business analysts as well as professional programmers to easily create applications using a graphic terminal.

He goes on to address this exact issue in the next section:

If one wants to create as system which is easy to use by inexperienced programmers and ultimately non-programmers, one needs to provide powerful problem-oriented aids to program writing.  One has to start with the primitive machine language used to command the graphics system hardware and build upward.  The philosophy of design chosen is the one becoming more common in the computer industry, which is to design increasingly more powerful levels of programming support, each of which interfaces to its surrounding levels and builds on the lower levels.  It is important to try to design these levels more or less at the same time so that the experience with each will feed back on the designs of the others before they are frozen and difficult to change.

He sketches out five “levels” that need to be considered when designing for non-programmers.

1. System calls
2. A given programming language's interface to the system calls
3. The actual picture drawing/editing/storage system
4. Data structures for picture data
5. The end-user application itself

He then looks at popular display hardware in 1971, which he breaks into two categories: storage tube displays, and refreshed displays.

A refreshed display is what all displays are today: something that updates the whole screen N times per second, and thus lets you change what is on the screen at a decent frame rate, displaying fluid animations. These cost anywhere from $10,000 to “several hundred thousand dollars” in 1971.

A storage tube display is meant to show static images. The graphics on the screen can be redrawn but very, very slowly. I've seen some of these in action at the VintageTEK museum and a complicated picture of, say, a circuit board diagram, can take something like 20 seconds to draw, though the resulting picture is beautiful, crisp, and incredibly high-resolution. (Imagine a robot very quickly and efficiently using an etch-a-sketch and you'll have the right idea.) These displays are much cheaper than refreshed displays, about $20,000 at the high end, many significantly cheaper than that.

He also gives an overview of various input devices, which we covered in RFC-178.

His requirements for user software are really interesting and are worth reading in full, but the gist is:

• pictures should be represented by graphical primitives and these primitives should be able to be grouped into logical picture parts
• picture parts should be selectable, and picture parts should be able to have metadata associated with them (so click on the window of a house in a CAD type drawing and there might be data about what model of window that is)
• "user should be able to do some graphic programming by drawing directly at the console"

Then he describes data structures. "A line is much more than just a line when it represents a boundary or a part of some more complex unit". He talks about how a data structure for an entire image could contain useful information about parent-child relationships, and important metadata for each individual picture part. He seems to be describing a scene graph (see below for some missing figures). One case that he is concerned with is: if you click on a piece of a house, are you clicking on the whole house, or just the piece? How do you determine user intent?

There is a lot of good stuff in this RFC, and I'd recommend that anyone with an interest in computer graphics give it a read. There's a whole section about “light buttons”, namely, rectangles that have labels on them that when pressed with a light pen, issue a command related to the text on the rectangle. There's also a very in-depth discussion of what a back button (or “back pointer” in this case) actually is and does.

Analysis

There are two figures reference in the official version of this RFC, but the figures are not included anywhere online. I found them in the original documents at the Computer History Museum's archive, so here are my low-quality photos.

The scene graph stuff (though he doesn't use that term) seems to be pretty cutting edge for the time! I'm trying to dig up prior art on the concept of scene graphs as I'm curious as to exactly how cutting edge this is.

There is also a figure 3 that is pseudocode for parsing the scene graph that is entirely missing from the canonical RFC as well:

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 10 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.

Split screens

RFC-191 is titled “Graphics Implementation and Conceptualization at ARC” and authored by Charles Irby of SRI Augmentation Research Center (ARC). It's dated July 13th, 1971.

The technical content

This is a conceptual overview to supplement the technical information in RFC-190. There is some stuff of interest in here, for example the author describes the display area that a program writes to as "much like [...] a file which it has opened with write access". Strings written to the display are given unique identifiers, so that those strings can be manipulated (moved, deleted, replaced, changed) in-place.

A display can be subdivided into multiple display areas, so for example you could have a split screen view of text from different files at one time. Commands include things like “hortizontal split”, “vertical split” and “jump focus to display area”, which modern programmers who use programs like GNU Screen or tmux might be familiar with.

Further reading

Check out these very 1970s photos of Charles Irby.

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 9 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.

Even more graphics description

RFC-190 is titled “DEC PDP-10-IMLAC Communication System”, authored by L Peter Deutsch of Xerox PARC and dated July 13, 1971.

The technical content

This RFC describes how a DEC PDP-10 is connected to a remote IMLAC PDS-1 vector display. It's a display system that operates in a few modes: it can support the display of text strings at any position on the screen, it can simuate a teletype by doing line feeds and carriage return type layout (like a terminal screen), and it can move back and forth between these modes.

The system uses a mouse for control. The computer mouse is still pretty rare at this point (light pens and tablets are more common at ARPANET host sites) but if anyone is going to have a mouse, it's Xerox PARC, as they were a relatively early and enthusiastic adopter of the device. (Their Xerox Alto would go on to be the first personal computer designed around mouse input.)

The various system calls are documented in a really interesting prosaic format. For instance:

If first byte pointer is zero then

   if a new string is being written then

      an error code illstr is returned.

   Otherwise, the string already exists so

      delete the string from the display area.

If the first byte pointer is -1 then

   if a new string is being written then

      an error code illstr is returned.

   Otherwise, use the old string.

If the first character of the string is a zero character,
the string to be displayed is null, but the string is not
deleted.

I love that each system call not only has its basic functionality described, but use cases and notes for each system call are also listed.

The system calls are somewhat similar to previous graphical display languages we've seen, wherein display areas are defined, cursors are positioned, etc.

Further reading

L Peter Deutsch had a long programming career and among other things is the primary author of GhostScript, but is now primarily a composer. He's interviewed in the popular book Coders at Work by Peter Seibel.

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 8 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.

Some compliance with standards

RFC-189 is titled “Interim NETRJS Specifications” and authored by Robert T. Braden of UCLA's Campus Computing Network. It's dated July 15, 1971.

The technical content

This RFC is an update to RFC-88, which first introduced NETRJS, the NETwork Remote Job Service. As of July 1971, RAND and UCLA are connected to one another and using NETRJS to run programs on each other's computing systems.

I'll quote myself from my RFC-88 blog, where I say that NETRJS

lets you, for example, enter a batch of Fortran commands on a punch card system and then send them over the network to a computer to process as a “job”. You can also log in to the remote computer and ask it for the status of your job. You can submit a “stack of consecutive jobs” as well.

One difference between this version of NETRJS and the RFC-88 version is the introduction of a “virtual remote batch terminal”—when a NETRJS client connects to a NETRJS server, the server sees the abstracted virtual terminal on the other end. This virtual terminal can provide “virtual card readers, printers, and punches.” Card images can be transferred and spooled into the IBM 360 system running at UCLA. Since it's an IBM 360 system, the UCLA system uses EBCDIC instead of ASCII, so the NETRJS server handles all conversion from any incoming ASCII terminals to EBCDIC and then back to ASCII for return to the client. ASCII terminals are meant to connect via the Initial Connection Protocol to socket 13 at host 1, and EBCDIC terminals are meant to connect to socket 11 at host 1. Providing different sockets for different character encodings makes things much simpler for the NETRJS server; no complex dance has to happen to figure out what kind of system you're getting a message from.

The RFC-88 version of this protocol simply asked that people convert ASCII to EBCDIC themselves in order to use the service. I think it's pretty clear at this point that ASCII is no longer an ignorable character encoding.

This version also uses TELNET over ASCII as a mediating protocol for the actual control portion of the connection. While EBCDIC data may be transferred during a connection, the actual operation and commands sent are done over ASCII, and via TELNET at that. They specifically use the EBCDIC-to-ASCII character mappings defined in the RFC-158 TELNET protocol. Yet another example of an early protocol changing to suit the new norms of the ARPANET.

There is an immediate future plan to make NETRJS conform with the Data Transfer Protocol described in RFC-171, though these are going to be minor changes overall. This would mean that operations happen over DTP, and data transfer itself happens over DTP, which would make NETRJS fully compliant with existing protocols for anything happening over the wire! This could mean that if users at a computer system running some arcane operating system would like to join ARPANET and use NETRJS, most of the work that they'd do writing a NETRJS client would in theory be reusable for other applications.

Further reading

Bob Braden died in April 2018. For more on Braden:

• a long, fascinating interview with him at the Charles Babbage Institute
• an audio interview with him from 1993 that I have yet to listen to
• the IETF blog post written on news of his passing

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 7 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.

Data management meeting

RFC-188 is titled “Data Management Meeting Announcement” and authored by Peggy Karp of MITRE and Douglas B. McKay of IBM. It's dated January 28, 1971.

The technical content

This RFC announces the first Network Data Management meeting. This meeting was already announced in RFC-173, but this is the formal announcement.

Analysis

The RFC is dated January 28, 1971. I don't believe this date. It doesn't match with RFCs of a similar number (late July 1971), and also the idea that a committee meeting would be planned six months in advance seems very un-ARPANET. Also, according to RFC-173 this meeting was planned as a result of the discussions at NWG meeting at the Spring Joint Computer Conference. Furthermore, all the RFCs referenced in this document were written between April and July 1971.

My guess is that whoever transcribed this in the late 1990s had a brain fart and kept writing “July” as “January”.

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 6 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.

An experimental network

RFC-187 is titled “A Network/440 Protocol Concept”. It's authored by Douglas B. McKay and Donald P. Karp of the IBM Thomas J. Watson Research Center. It's not dated but we can assume it's from late July 1971.

The technical content

This document opens with a note heretofore unseen on an RFC:

This RFC is being circulated as an information RFC. Its intent is to convey some of the thinking and philosophy that went into IBM's network protocol and overall network design.

So right at the start we understand that this is not a proposal but rather an informational document for the edification of RFC readers.

Network/440 is an IBM Research project where they built an internal network at IBM in order to learn about computer networks as a concept and figure out where IBM could provide solutions for a market that was yet to exist.

Their primary approach is "to treat all systems involved in the network as a part of a single (large) multiprocessor system". So, essentially, in the view of the Network/440 team, the network is simply a very distributed supercomputer.

IBM also says that they have two major operational networks. One of these is in a "distributed configuration", and the other is in a "star configuration". By the latter they mean a network with a central hub that all computers are connected to (in the last section of the document they describe what sounds like a basic timesharing system with terminals connected to a single central computer).

(Their system is completely different from the ARPANET and does not use IMPs or the Host-Host protocol. I'm not going to be able to learn all of this from just one paper, so I'm going to do my best to summarize what's in here given my incomplete understanding.)

They begin by breaking the network up conceptually. The ARPANET team did this with their “levels” model. IBM's model breaks things at the abstract into two big pieces: “net control” functionality, which manages job execution over the network, and “communication control” functionality, which manages the efficient movement of packets across the network. By breaking things up this way, they can say things like: a switch is something with communication control but no net control, and an end user terminal is something with net control but no communication control. And there are nodes that have both as well, for example in a centralized network where a monitoring process might examine all network traffic and then reassign jobs based on some sort of centralized algorithm.

The definition of a logical message on this network is that it's a header followed by text. An “action code” in the header tells network nodes whether they should shunt this message over to a net control, or just pass it on to the communication control system for forwarding. Each message, as it passes through nodes, is modified by the node to insert the node's station number, in order to provide a kind of paper trail for where the message has been. (I'm unsure if this number is appended, or overwritten: the verb used in the document is “overlaying”, which is unclear to me.) Messages also contain a job identifier and some state information about the job. They also contain information about the originating node and user in the network, a transmission priority value, information about the intended destination node, and of course identifying information about the payload of the message including its length and also any metadata required to connect it to other message payloads. The reason for the last one is that payloads can be split across multiple messages, so a receiving computer needs to have enough information to be able to reconstruct the full payload from multiple messages.

The document describes a File Transmission Protocol on this network. The protocol is similar to ARPANET's FTP in many ways, including the ability to execute files on a remote system.

Analysis

We can see by looking at the IETF Datatracker references that this RFC was essentially never cited by future RFCs, so this entire document is kind of an informational “aside” in the history of ARPANET.

The transcription of this RFC in 1997, perhaps aided by optical character recognition technology, means that the canonical document is full of references to "Network/44O", that is, with a letter “O” instead of a number “0”.

I also love that they use the term “computer netting” instead of “computer networking”.

Further reading

Network/440 remains fairly obscure. Aside from this RFC, there's a lot of information in MITRE's Survey of Computer Networks from September 1971, beginning on page 38 of that PDF. This document contains more technical details about the hardware and software. The document says that IBM's system uses homogenous computers, meaning every computer on the network is running the same operating system, the same software, and extremely similar hardware (all variations on the IBM 360).

That document, by the way, is a great overview of the various networks in operation in 1971. ARPANET was not the only operational network at this point in time. For example, CYBERNET is a “nationwide commercial network offering computing services to the general public” by the Control Data Corporation, that provided timesharing services over telephone lines. And we've heard about MERIT, which at this point connects a bunch of computer systems at different Michigan-based universities.

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.