365 RFCs

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

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

Let's share the cost

RFC-345 is titled “Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN)”. It's authored by Karl C. Kelley of the University of Illinois and dated May 26, 1972.

The technical content

This RFC lets people know that the University of Illinois is considering purchasing IBM's Mathematical Programming System Extended (MSPX). The author wants to know if other people on the network would like this to be a shared network resource, in which case they could share the cost of the computer that they will be renting from IBM. The rental costs $130/month, which is $800/month in 2019 dollars.

Further reading

I'm not going to pretend to understand the intricacies of mixed-integer linear programming, or even plain old integer linear programming. Generally speaking this technique lets you put in a whole bunch of equations that describe constraints in a system and then it figures out optimizations for that system of equations. This lets you do things like come up with the most efficient possible schedule for dispatching police patrol cars in a big city, though when you're modeling human behavior like that you often miss important variables and your model doesn't actually reflect reality.

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, December 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 status

RFC-344 is titled “Network Host Status”. It's authored by Ellen Westheimer of BBN and dated May 22, 1972.

The technical content

This is another report from BBN on the status of various ARPANET hosts in the same series as RFC-342, RFC-332, RFC-330, RFC-326, RFC-319, 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 May 8 to May 19:

  • 58 dead
  • 83 open
  • 18 half open
  • 17 timed out
  • 1 refused
  • 3 full/busy

While our proportion of fully-online hosts is the same as in the previous period, we now have far fewer “dead” connections. These connections are now replaced with “half-open” connections, where the Host opened a connection but then nothing happened. This is entirely due to the PDP-10 at the MIT Artificial Intelligence group coming (half) online on May 9. Apparently the PDP-10 at Stanford also came online but it still seemed to be mostly dead according to this 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, December 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.

No network on Tuesdays

RFC-343 is titled “IMP System Change Notification”. It's authored by Alex McKenzie of BBN and dated May 19, 1972.

The technical content

BBN's attempt to upgrade the IMP system software, as announced in RFC-331, was a failure. The failure was one of project management rather than programming. There are now too many ARPANET sites for BBN to coordinate a simultaneous switchover of software, and the gradual rollout strategy surfaced unforeseen emergent incompatibilities between IMPs running the old and the new software.

They are going to try again with new software. This time they are reserving every single Tuesday until they manage to get it right. So this RFC says: expect the ARPANET to not work super well on Tuesdays until we let you know that we are done with our software deployment.

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

Network status

RFC-342 is titled “Network Host Status”. It's authored by Ellen Westheimer of BBN and dated May 15, 1972.

The technical content

This is another report from BBN on the status of various ARPANET hosts in the same series as RFC-332, RFC-330, RFC-326, RFC-319, 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 April 24 to May 5:

  • 76 dead
  • 87 open
  • 4 half open
  • 18 timed out
  • 1 refused
  • 4 full/busy

We are at about 52% online status for the longest-running ARPANET servers, and 44% online overall. These numbers are pretty close to what was reported in RFC-332 the prior two-week period.

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

Not issued

RFC-341 was never issued.

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

Telnet changes

RFC-340 is titled “Proposed Telnet Changes”. It's authored by Tom O'Sullivan of Raytheon and dated May 15, 1972.

The technical content

This is a reply to Jon Postel's RFC-328, which proposed three changes to Telnet. The author agrees with Postel's first suggestion, which is to get rid of the minimum Telnet implementation.

He disagrees with Postel's two other proposals: that Data Types and Hide Your Input be dropped.

His objection to the removal of Data Types is based on the need to switch to binary data stream representations for certain applications via Telnet, and that contrary to Postel's claim that there is no way to switch back to Telnet ASCII, you could simply switch back using a code that is not present in the Telnet spec and that would be okay.

His objection to the removal of Hide Your Input is that just because something is difficult to implement doesn't mean it should not be implemented. In particular, protecting passwords is important and is worth the difficulty in navigating solutions.

Analysis

This comes in just under the wire, on the literal due date of May 15 that Postel set for accepting feedback before assuming it would pass consensus by default.

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

Multiplexed Telnet

RFC-339 is titled “MLTNET: A 'Multi Telnet' Subsystem for Tenex”. It's authored by Robert Thomas of BBN and dated May 5, 1972.

The technical content

MLTNET lets a user log in to multiple ARPANET Hosts at one time. It's useful if you need to coordinate behavior between Hosts: you need the program on Host A to do this, and then you need the program on Host B to do that.

Basically, you start off in Local Mode and open your connections to various remote sites. Here you can associate helpful names for these sites as shortcuts and query the remote site to make sure that it's still online. Then you enter a command TALK <sitename> and it switches to Remote Mode, where you're connected to that site in a Telnet-like way. You issue your commands, and then back out of Remote Mode into Local Mode, where you connect to another remote Host of your choosing.

Analysis

It makes sense that someone at BBN would need to coordinate jobs running on different ARPANET nodes. Presumably this use case came up while BBN was running tests across the network as a whole.

Further reading

Bob Thomas is probably best known for writing Creeper, which was arguably the first computer “worm” to spread across a network. It was not a malicious program per se. It would simply display the text “I'm the creeper: catch me if you can” to a user's terminal.

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

The real world of users and servers

RFC-338 is titled “EBCDIC/ASCII Mapping for Network RJE”. It's authored by Bob Braden of the UCLA Campus Computing Network and dated May 17, 1972.

The technical content

Okay so now we are back to some bread-and-butter ARPANET stuff: character encoding. In RFC-112, a survey of ARPANET sites conducted by Raytheon, we learned that as of April 1971, a sizable minority of ARPANET computers internally used EBCDIC as their character encoding, rather than using ASCII or something else. EBCDIC was essentially the in-house choice of IBM mainframes at the time, including the popular IBM 360 series.

The author of this RFC points out that in RFC-183, Joel Winett “sounded a clarion call for all EBCDIC sites to join in defining a Network standards mapping.” UCSB has had reports from users of its Remote Job Entry system who have been experiencing bugs related to EBCDIC/ASCII conversion.

To get a sense of how maddening the (non) overlap of different standards was, check out this Venn diagram drawn by Braden for the RFC.

A hand drawn diagram of five overlapping rectangles showing what characters are supported by: Basic EBCDIC, 33/35, full ASCII, AT&T TWX (Mod 33/35 tty), and PL1 Set.

Braden has decided to incorporate into NETRJS (the program for RJE operation) the second and third character mappings laid out in RFC-183. This warms my heart because when I was reading RFC-183 I noted that the first character mapping, the one suggested by IBM, is “frankly weird”. I'm heartened that Braden-in-1972 agrees with my low assessment of IBM's mappings.

Braden talks about an error they made originally: they assumed that people executing IBM 360 programs would not be providing ASCII characters that not supported by EBCDIC in the first place. These characters ( [, ], {, }, ^, \` ) are transcoded to EBCDIC question marks. The problem here is that some of these IBM 360 programs were designed to manipulate ASCII text from the ARPANET! So they absolutely did need to be able to encode every available ASCII character in that case.

There are even more problems with Model 33/35 Teletype users, as you might be able to infer from the above diagram. Braden offers a third mapping that he declares “is ugly, but it is probably the best we can do.

Braden concludes with an observation that ARPANET discussions tend to put all the burden on user sites to map things into formats that are network-compatible, but he says that “in the real world of users and servers, the server will have to do the adapting”. By my estimate, in 1972 Bob Braden was probably the single most experienced human being when it came to providing and maintaining heavily used remote services over the ARPANET, so this is extremely hard-earned and novel wisdom for the time.

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

Not issued

RFC-337 was never issued.

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

Level 0 graphics input

RFC-336 is titled “Level 0 Graphic Input Protocol”. It's authored by Ira Cotton of MITRE and dated May 5, 1972.

The technical content

This document describes a “level 0” graphics input protocol, which was defined in RFC-282 at a November 1971 Network Graphics Working Group Meeting as the simplest possible useful implementation of graphics features: mainly, simple picture drawing. The group did not define what level 0 means for graphics input, but the Graphics Group is taking a crack at it. This RFC summarizes their consensus following an April 1972 meeting of the Graphics Group, offering up text and simple position as the two types of input data.

Text input will be network ASCII encoded. Position will be encoded as twos-complement signed fractions of the virtual screen, as I previously described in my post on RFC-292 and as defined in RFC-282.

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.