365 RFCs

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

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.

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

Settling file transfer

RFC-309 is titled “Data and File Transfer Workshop Announcement”. It's authored by Abhay Bhushan of MIT and dated March 17th, 1972.

The technical content

This RFC announces a mid-April invite-only workshop on Data and File Transfer. The workshop will be convened with the explicit goal of codifying file transfer on the ARPANET once and and for all, and will consider all kinds of users including terminal IMP users that are normally left out of protocol and service design.

As usual, “participants are encouraged to have written position papers” before the meting.

The workshop features talks from people representing all the major players in file transfer on the network: generic network users, the datacomputer, terminal IMP users, and remote job entry.

Of the twelve items of suggested reading, eleven are previous RFCs. The one non-RFC document is a publication called “Data Language” by Computer Corporation of America, but I can't find something with that exact name online to link. Update: thanks to Retrocomputing Stack Exchange user snips-n-snails for finding this document, a 1971 CCA working paper called “Datalanguage”. Also thanks to reader wizzwizz4 for posting the question.

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

ARPANET Online

RFC-308 is titled “ARPANET Host Availability Data”. It's dated March 13th, 1972 and authored by first-time RFC author Marc Seriff, who is personnel working on the MIT Project MAC Dynamic Modeling Computer Graphics PDP-10.

The technical content

MIT has implemented an automated survey of uptime for ARPANET hosts. Their definition of whether a host is online is whether it is accepting connections on the Initial Connection Protocol. This is a limited definition of “online” but they don't want to unnecessarily flood the network and tie up resources on the various hosts. The survey pings all known hosts once every fifteen minutes, at least while MIT's host is online.

One very cool thing is that you can access the results of the survey program yourself by logging into MIT-DMCG and issuing commands to look at some of the survey statistics. This includes a BEST.SURVEY command that “lists the best of the recent surveys”, which I don't know what it means but it sounds great.

Analysis

The author is very forthcoming about the limitations of the data that they are collecting. I won't even summarize the data here because frankly the methodology is really suspect (the survey is essentially “how often are remote hosts online while MIT's host is online”). But again, kudos to the author for acknolwedging this in the RFC itself.

To me the important part about this is that they offer the statistics as an ongoing service to anyone who wants to see them. Compare this to the compiled statistics sent out as RFCs every two weeks by BBN. Hopefully BBN will soon move to a system like this.

Further reading

See RFC-186 for more about the Dynamic Modeling Computer Graphics computer.

The author of this RFC, Marc Seriff, would go on to co-found the company that would eventually be known as America Online.

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

A remote job frontend

RFC-307 is titled “Using Network Remote Job Entry”. It's authored by Eric Harslem of RAND and dated February 24, 1972.

The technical content

RAND has been a heavy user (perhaps the heaviest user, at least implied by previous RFCs) of the remote job entry services offered by both UCSB and UCLA for over a year. As I explained in my blog post for RFC-88, remote job entry

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.

In other words, remote job entry is a way to get a remote computer to run an arbitrary program for you and give you the output.

Rand finally has a host PDP-10 online—previously they were a using site but not a host site. Their host PDP-10 now has an RJS Access Program (RJSAP) which acts as an intermediary to RJS. This was presumably created for internal use at RAND, but now that they are a host site, other sites can use their RJSAP to access the Remote Job Service (RJS) at UCLA.

There is a lot of human coordination required to use this service! You have to contact Ron Frederikson at RAND to get an account on their PDP-10, and then you have to contact Bob Braden at UCLA to get an account on their IBM 360/91, and Braden also has to give your account special access to RJS.

The basic workflow is:

  • you log into the RAND computer
  • you type your program you want to run into a special file format
  • that file is saved on the RAND computer
  • you open RJSAP
  • you connect to UCLA's computer
  • you point RJSAP to your file and it sends the program to UCLA's computer
  • at this point you can either:
    • wait
    • log off and do something else, then log back in
  • either way, you can issue a command to ask RJSAP if the job is done
  • RJSAP queries UCLA and lets you know if it's done. If it's done then the output is in a file on the local computer
  • you can close RJSAP and then access the output on the file system

There's a full session transcript at the original RFC that is worth reading, including a “BYE, BYE BANANA” message when you quit.

Analysis

RJSAP is a frontend service for another service on the network, one of the first of its kind, at least of those services documented in RFCs. This is how almost every “web application” behaves today: there's a piece of software (the website) that makes it easier for you to access another piece of software (some kind of server or service like an email server). Of course this is all 20+ years before the web, but the pattern here is similar.

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

Network status

RFC-306 is titled “Network host status”. It's authored by Ellen Westheimer of BBN and dated February 15, 1972.

The technical content

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

The numbers, from January 31 to February 11:

  • 83 dead
  • 55 open
  • 18 half open
  • 13 timed out
  • 1 refused

We are still at about 50% online status for the longest-running ARPANET servers, and 32% 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.

Enter your email to subscribe to updates.