365 RFCs

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

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

Network status

RFC-319 is titled “Network host status”. It's authored by Ellen Westheimer of BBN and dated March 21, 1972.

The technical content

This is another report from BBN on the status of various ARPANET hosts in the same series as RFC-315, RFC-306, RFC-298, RFC-288, RFC-287, RFC-267, RFC-266, RFC-255, RFC-252, RFC-235, and RFC-240.

The numbers, from February 28 to March 10:

  • 77 dead
  • 85 open
  • 12 half open
  • 6 timed out

We are at about 57% online status for the longest-running ARPANET servers, and 47% online overall. Slow and steady improvements for the last few such reports.

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

Neither clear nor succinct

RFC-318 is titled “Telnet Protocol”. It's authored by Jon Postel and dated April 3, 1972.

The technical content

This is Postel's attempt to summarize the Telnet protocol as it exists on the ARPANET at the moment. He is not happy with the protocol as it exists and in addition to providing a summary, also presents some suggestions for improvement (on behalf of others who have made the suggestions).

The first thing that needs to be defined is the Network Virtual Terminal (NVT). This is a piece of software (hence “virtual”) that emulates a physical teletypewriter terminal. The NVT consists of a “printer”, which is the input data stream, and a “keyboard”, which is the output data stream. The keyboard can output any ASCII value from 0 to 127. The printer can output the printable characters (values 32 to 126), and also a handful of control characters like BELL, back space, line feed, carriage return. “End of line” is defined as carriage return followed by line feed: CR, LF. (More on that here.) The point of the NVT is to provide a standardized terminal “to eliminate the need for using and serving sites to keep information about characteristics of each other's terminals”. That is, if you can all agree on a standard subset of terminal functionality then as long as you get your own actual (non-virtual) terminal speaking that standard, you're good to go.

Telnet uses the Initital Connection Protocol to establsih a connection with a remote host, and then the main interface for writing and reading data back and forth is the NVT, and then the Telnet control signals are what controls the flow of that data under the hood.

The telnet signals consist of 8-bit values 128 and above, so as not to interfere with the values 0 through 127 that are for the NVT as described earlier.

There are codes for things like interrupts, for hiding input (like when a user is typing in a password, you don't want to display it), and for marking where data blocks begin and end.

Postel provides recipes for both a minimal implementation of Telnet (on both client and server) and a “standard” implementation of Telnet.

Of course, there are problems. For starters, if you send the character “a” to a remote terminal that only supports upper case letters... well, you've successfully sent “a” from your NVT to their NVT, but now they need to translate that letter into something that they can show. Presumably they'll translate it to upper case “A”, but you don't actually know for sure unless you ask someone over there what it looks like! One suggestion is to allow users to specify that translation themselves... but now you've more or less rendered the NVT useless.

There are also concerns about extending Telnet to be able to represent graphics and so on.

Things get weirder where the codes for more abstract control commands come in. When you send a “CR;LF” newline across the network, the receiving host might not actually have CR and LF available locally! Instead it could interpret it and then translate it to an internal, non-ASCII “new line” command before sending it to the main computer's processes. The state of CR;LF in computing on the ARPANET is summarized by Postel as follows:

Telnet defines the end of a line to be indicated by the ASCII character pair CR LF.  Several of the real devices in the world have only a single new line (NL) function.  Several of the computer systems have in some programs used the CR and LF functions to have semantic meaning larger than the format effect they provide. Further, several computer systems allow the CR and LF functions to be used separately (e.g., such that a line may be overprinted).

One solution that could work is to follow any CR that is not going to be followed with an LF with a NUL instead. This lets the recipient know that the CR can be interpreted as semantically distinct from a newline command.

Postel also points out some inconsistencies with echoing and the hide-your-input functionality (do you print X's instead of letters? nothing? etc). Similarly the interrupt signal has different semantic meanings on different computers and as such isn't so simple to interpret. He suggests using the BREAK (interrupt) signal in conjuction with the DATA MARK signal in order to communicate more detail about the type of interrupt that is being sent.

There are some changes to Telnet proposed by others—the big one to my eye being the proposal that all data types be scrubbed from the protocol in favor of pure ASCII.

Analysis

Of all the people in the history of the APRANET and early Internet, Jon Postel (1943-1998) is spoken of in glowing terms. He was largely beloved, and remains so to this day. Yes he was instrumental to the network and essentially ran huge chunks of the internet by hand for years, but also everyone just liked him so much. I think that the opening paragraph of this RFC is an example of his signature “poetic and whimsical” style:

   At the October 1971 Network Working Group Meeting, I promised to promptly produce a document which clearly and succinctly specified and explained the Official Telnet Protocol.  This document fails to meet any part of that promise.  This document was not produced promptly.  This document is neither clear nor succinct.  There is NO Official Telnet Protocol.

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

RFC-317 is titled “Official Host-Host Protocol Modification: Assigned Link Numbers”. It's authored by Jon Postel and dated March 20, 1972.

The technical content

Recall that links are the term used for each of the 256 “channels” that you can communicate over the network on. So for example, you can connect from one computer to another by reserving link number 38, and while you are using that link, nobody else can use it.

The last official documentation of link numbers was in RFC-179 in June 1971. In that RFC, link assigments were listed as:

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

In this new RFC, links 159 through 190 have been opened up for network measurement by the Network Measurement Center.

Links 192-195 are being used for the “Message Switching Protocol experiment”. More on this to come in RFC-333. The new assignment table is:

0                      Control Link
2-71                   Available for Connection
1, 72-158              Reserved--not for current use
159-191                To be used only for measurement work
                       under the direction of the Network
                       Measurement Center at UCLA
192-195                To be used for the Message Switching
                       Protocol experiment
196-255                Available for private experimental use

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

Data management applications

RFC-316 is titled “ARPA Network Data Management Working Group”. It's authored by Doug B. McKay and one A. P. Mulleray, who I can't find any information on. It's dated February 24, 1972.

The technical content

This RFC is a summary of the Data Management Working Group meeting.

Since the RFC itself is a summary, I'll give a brief summary of the summary.

The meeting took place in two phases. In the first phase people presented how they were using data sharing on networks in the workplace, or developing for data sharing applications. These included:

  • teaching and testing physicians using material stored on the network
  • the MEDLINE system that provides access to information from medical journals over the network
  • the network components of the World Wide Military Command and Control System, which required fast querying of databases, daily synchronization of data across the network, and reporting capability on a weekly/monthly/etc basis—this is one of the first times the need for data security is highlighted in an RFC
  • the topography of the network at General Motors Research Laboratory, where designers would create designs (presumably for different car parts) and then upload them to servers that would run physical stress simulations on them
  • running meta-experiments to determine whether certain data management functions should be centralized or distributed

Phase 2 was to organize the committee and set up an interest group for data management.

Further reading

MEDLINE still exists today as the NIH's MedlinePlus.

The World Wide Military Command and Control System (WWMCCS) was an attempt to coordinate United States military forces across the world. The idea was for commanders to be able to issue orders within minutes to soldiers on the other side of the earth, and for the commanders to have access to aggregated intelligence data to help them make decisions from half a world away. It was under new management as of 1971, and put under the auspices of the Assistant Secretary of Defense for Telecommunications. I imagine their attendance at this meeting is tied in with that.

Aside: “Command and control”, also known as C2, is a military term that I've seen used as early as the 1950s in relation to the Lincoln-Lab-helmed Semi-Automatic Ground Environment, aka SAGE. This entry from The Oxford Companion to American Military History provides a ton of background on the concept in general, and while the need to coordinate across different branches of the US military is a problem as old as the United States, the author cites the 1947 unification of all the military branches under a single Department as the main impetus for command and control. If we look at the frequency of the phrase in books scanned by google, the phrase starts to take off right around 1948, so that claim seems to hold up.

In the Phase 2 section, one of the attendee names jumped out at me: Elizabeth Fong.

I looked her up and she spent her whole career at the National Institute for Standards and Technology, which at the time of this RFC was still the National Bureau of Standards. She was heavily involved in the effort to standardize SQL in the 1980s. Here's a 2014 interview with her, and here's a brief autobiographical sketch on being awarded for 48 years of service at NIST.

Other women in attendance are Dorothy Hopkin, who I've written about on this blog, and Suzanne Taylor and Erika Perez of MITRE, who I'm unfortunately unable to find more information on.

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

Network status

RFC-315 is titled “Network host status”. It's authored by Ellen Westheimer of BBN and dated March 8, 1972.

The technical content

This is another report from BBN on the status of various ARPANET hosts in the same series as RFC-306, RFC-298, RFC-288, RFC-287, RFC-267, RFC-266, RFC-255, RFC-252, RFC-235, and RFC-240.

The numbers, from February 14 to February 25:

  • 77 dead
  • 61 open
  • 15 half open
  • 9 timed out

We are at about 45% online status for the longest-running ARPANET servers, and 37% online overall.

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

Network graphics and cherry blossoms

RFC-314 is titled “Network Graphics Working Group Meeting”, by Ira Cotton of Mitre, dated March 14, 1972.

The technical content

The graphics working group will have a meeting in one month at The Mitre Corporation in McLean, Virginia. Mitre is close to Tysons Corner, and the RFC mentions an attached map. No such map is in the canonical online version, but I took this photo of the map at the Computer History Museum:

A map of Northern Virginia with Mitre and the Holiday Inn highlighted.

Cotton notes that the tidal basin cherry trees will be in bloom in Washington during the meeting!

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

Computer based instruction

RFC-313 is titled “Computer Based Instruction”. It's authored by Tom O'Sullivan of Raytheon, dated March 6, 1972.

The technical content

So here's an RFC that reminds me of RFC-286, in the sense that it touches on an enormous field of study that I am even more out of my depth in than usual.

Computer Based Instruction (CBI) is a general term for any instructional/educational activity involving computer use as a main piece of the instructional process. It's what you'd colloquially call “educational software”. It is an enormous field of development that is as old as computing itself. Perhaps the most famous mid-century CBI system was PLATO, though lots of famous early computing systems could be categorized as CBI, including the computerized simulation devices made for the military in the aftermath of World War II.

The RFC mentions Computer Aided Instruction, which is when the computer is a direct part of the instructional process, and Computer Managed Instruction, which is kind of like today's learning management systems, managing enrollment, course selection, evaluation, etc.

The author identifies four areas where the ARPANET could be helpful to CBI:

  1. The network itself. Users could log into CBI systems at different institutions, evaluate them, and determine which they like best and want to use at their own institutions. Users could pay to occasionally use the service rather than have to maintain their own system (so kind of an early software-as-a-service model). People managing CBI systems could check out what lessons already exist on other systems to avoid duplicating effort.
  2. Centralized data storage. This portion talks about taking advantage of economies of scale to reduce storage costs. For example, if lessons for a CBI at multiple sites were stored in a central location and accessed over the network, you wouldn't have to pay for storage at every site. Further more, for CMI, centralized databases could allow analysis of educational management data across different institutions.
  3. Language processors. I am unclear on the argument the author is making here but I think it's that you could build out a course or similar for your CBI and then use something like the Datacomputer to cross-compile it to another format that a different CBI could use.
  4. Dialogue support systems. This is what we could call “forum software” today. The author stresses the interdisciplinary nature of the CBI field and that it's very important that “theoreticians, developers, and users” be able to talk to one 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, November 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.

Better Host-IMP error messages

RFC-312 is titled “Proposed Change in IMP-to-Host Protocol”. It's by Alex McKenzie of BBN and dated March 22, 1972.

The technical content

BBN wants to change around some of the existing error messages in the interface between the Host (Network Control Program) and the IMP, including adding some new error messages.

There is a kind of general “things are clogged up for an unspecified reason” error state that was mentioned in RFC-270. The author says that BBn would like to provide new error messages when this happens. Right now there's no error message during the state, just a bunch of NOPs (no-operation commands, basically filler commands that do nothing) that are sent to signal the error state.

They also propose specific error messages when messages are too short, too long, or an illegal message type.

Analysis

Making more descriptive and varried error messages and types is, to my mind, always a good thing.

But this would require NCPs to be rewritten, which I imagine people won't be very happy about. It seems like the kind of thing people would propose wait until the next “major version” of a host-host protocol comes out and everyone has to rewrite their NCP anyway.

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

Graphics terminals

RFC-311 is titled “New Console Attachments to the UCSB Host”. It's authored by Roland F. Bryan of UCSB Computer Research Laboratory and dated Februrary 29th, 1972.

The technical content

UCSB has a new system in place that allows their IBM 360-75 computer to connect to peripherals that are not strictly IBM standard. These include a Tektronix 4002 Graphic Computer Terminal and a mysterious device calle dthe General Purpose Graphics Terminal, reportedly developed by the University of Iowa for the National Institutes of Health.

Further reading

The VintageTek Museum (my favorite Portland-area tourist destination!) has a lot of material on the 4002 Graphic Computer Terminal series. This news/PR item (PDF) discusses the new graphics terminal, and they host a twelve page introductory brochure for the 4002 from 1970. A nerdy detail: the 4002A differed from the 4002 by replacing internal diode matrix memory with a ROM. There are lots of photos of the 4002 series at the Terminals Wiki.

Meanwhile, I can find very very little on the General Purpose Graphics Terminal except for some references in related documents, like the 1972 annual report of the NIH Biotechnology Resources Branch (PDF) and the 1973 annual report of the same (PDF). My guess is that this was a highly specialized terminal that was never available to the consumer market, which would make sense if it were NIH-branded and built “for use in Bio-Medical applications” as this RFC suggests. I cannot find anything linking the University of Iowa with this device, but multiple University of Minnesota documents mention the GPGT so maybe the author got the wrong university when he was giving credit for its invention.

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

Reconsidering FTP

RFC-310 is titled “Another Look at Data And File Transfer Protocols”. It's by Abhay Bhushan of MIT and dated April 3, 1972.

The technical content

This document is published in advance of the file transfer workshop announced in RFC-309. The idea is for Network Working Group members to discuss the contents of the RFC at said workshop. The author is the organizer of that workshop and also the original author of the FTP specification in RFC-114.

The documents opens by talking about some prior art: a program called CPYNET available on BBN's TENEX operating system. (I imagine the name stands for “CoPY-over-NETwork”.) This is not a true FTP-style thing because FTP is supposed to work across all computers and operating systems and file systems. CPYNET only works if you're copying files from one TENEX-based machine to another.

Because it's optimized to work with a small number of computers, CPYNET is efficient. Because TENEX is a PDP-10 operating system; you're dealing with the same operating system and the same hardware so you know that it's a 36-bit byte length. Thus no translation or partitioning of data is required.

Another method of file transfer that's been used on the network is a weird and interesting hack. TELNET itself has been modified at some sites to send ASCII files from one host to another. The way you do this is by logging in to a remote computer from yours via TELNET. Let's say that you want to send a file to the remote computer. What you do is tell TELNET to literally type out the contents of the local file on your computer into an empty file on the remote computer! This is not very efficient and ends up being about 10x slower than a more direct network transfer.

There's a problem where the Terminal IMP (TIP) can't support the Data Transfer Protocol (the foundation of the current formulation of FTP). Recall that the TIP is a kind of low-power terminal where a user's terminal is connected directly to an IMP instead of via a (big, expensive) computer in the middle. As Bhushan notes in this RFC,

The TIP philosophy is that "the computational load and storage should be in the hosts or in the terminals and not in the terminal processor."

Anyway, because TIPs won't support DTP, Bhushan recommends removing the transfer mode that was included specifically for TIPs, since they won't be using it anyway.

Computer Corporation of America is requesting some changes to the FTP specifcation in order to help out with their Datacomputer project. Among other changes, they would like FTP commands to be printable ASCII strings, so that FTP commands can be natively a part of their “Datalanguage”, which presumably could not handle integers as tokens for commands. Later, Bhushan notes that wide adoption of FTP

would be possible if a user could use an FTP-server directly without the help of a mediating DTP/FTP-User process.  This would require that commands be ASCII strings instead of numeric codes, and that ASCII characters be an acceptable input.  Such a change in FTP would greatly increase its acceptance at the cost of making the server-implementation more complex.

Bhushan also would like to modify DTP and FTP to better support remote job systems. In particular, there is talk of merging NETRJS and NETRJT into a single thing, and Bhushan would like DTP to provide some of the backbone for this new system. There would need to be new features like error recovery if this is to be the case, though.

Bhushan provides no answers in this paper but that's by design; the idea is that he is highlighting questions that will be addressed at the workshop next month.

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.