365 RFCs

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

by Darius Kazemi, April 16 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 questionnaire

RFC-106 is titled “User/Server Site Protocol Network Host Questionnaire”. It's authored by Thomas O'Sullivan of RDS. This stands for Raytheon Data Systems, which was founded in 1971 by consolidating a few of Raytheon's computing departments.

The technical content

This RFC is a questionnaire for ARPANET site users to fill out. It's intended to gather information about the various computing configurations at the different sites, so that a formal TELNET specification could meet everyone's needs. Recall that TELNET was originally proposed way back in RFC-15, but it was merely a proposal and not a robust specification.

The form asks ten questions, five of which are long-standing ARPANET issues:

Analysis

The form is meant to be filled out and then sites will be contacted by telephone to give their answers. I'm unsure as to how they could provide satisfactory answers to some of these questions without diagrams or formulas, though.

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

Remote jobs

RFC-105 is titled “Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB”. It's authored by James (Jim) E. White of UC Santa Barbara, dated March 1971 with no specific date.

A business note: my ten-month Mozilla Fellowship has supported this project up until now, but that has ended. If you like what I'm doing here, please consider supporting me via my Patreon.

The technical content

This RFC discusses UCSB's implementation of Remote Job Entry (RJE), an idea first proposed in RFC-88 by Braden and Wolfe of UCLA. As I explained in that blog post, RJE lets you

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.

Specifically, this document explains to any ARPANET user how they can connect to the UCSB Computer Center and submit jobs for the computer there to run.

They reserve a specific socket for incoming remote job submissions. This socket number is denoted x'200', which is FORTRAN hexadecimal notation, which means that's a decimal (base 10) vaue of 512. You have to register for an account with the Computer Center before accessing remote job services.

The Computer Center already has a job control language system; this document assumes you already know how to use that. The RJE is specifically a way to talk to their job control language from a remote site, and this document talks about how you would do that.

Like the RJE in RFC-88, this is a third-level protocol and routes through the network control program (NCP). RJE only accepts one user at a time, queueing any requests it gets if it's currently serving a user. To prevent someone from just sitting on the RJE and preventing everyone else from using it, the RJE kicks off a user if they aren't processing recordings at a certain rate. (In a sense this is the opposite of a “rate limited” API — you get kicked off for NOT using the service!)

RJE accepts multiple data formats, including a stream-based option (not fixed length) where the user needs to specify a break character in the header.

Getting the output

RJE is about submitting jobs to the computer to process; this RFC has a second section about the Remote Job Output Retrieval (RJOR) system. This is about obtaining the results of your calculations from a remote site (it wouldn't be very useful if you had to print your output at a school 1,000 miles away and have to ask them to mail it to you).

RJOR listens on socket x'300' and allows one user at a time with a similar queuing system to the one in RJE described above. When you connect to RJOR you send it commands for the kind of output you want, and then it will open socket x'301' and attempt to connect to a socket at your own Host site numbered one less than the socket from which you initiated your connection. (This adjacent-socket approach is a pretty common pattern in ARPANET applications at this time.) It will then send your output (or some kind of status info) back to you over this new connection.

Analysis

The document opens with a note:

     In the discussions that follow, 'byte' means 8 bits, with those eight bits numbered 0-7 from left to right.

It's important to note that the number of bits in a byte was not standardized (even informally!) until very recently in computing history. Here's a quote from Wikipedia's page on “byte”:

The size of the byte has historically been hardware dependent and no definitive standards existed that mandated the size – byte-sizes from 1 to 48 bits are known to have been used in the past. Early character encoding systems often used six bits, and machines using six-bit and nine-bit bytes were common into the 1960s.

I like that this document specifies that its NCP “operates under the Host-Host protocol of 3 August 1970”. Because the protocol is always changing, that's a level of necessary specificity that some other RFCs don't provide.

Further reading

Their computer runs a variant of OS/360 called MVT or Multiprogramming with a Variable number of Tasks, which by 1971 supported time sharing and batch jobs. It also runs something called HASP, the Houston Automatic Spooling Priority system, which is a complex I/O manager for remote job control and printing, among other things. Basically this machine seems perfectly configured for remote job processing!

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

RFC-104 is titled “Link 191”. It's authored by Jon Postel and Steve Crocker, dated Feburary 25th, 1971.

A business note: my ten-month Mozilla Fellowship has supported this project up until now, but that has ended. If you like what I'm doing here, please consider supporting me via my Patreon.

The technical content

This is a very short RFC. Postel and Crocker are letting everyone know that link 191 will henceforth be used for measuring network traffic. Anyone who wants to use that physical link will need to get permission from the Network Measurement Center..

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

Interrupting interrupts

RFC-103 is titled “Implementation of Interrupt Keys”. It's authored by Richard Kalin of MIT Lincoln Laboratory on February 24, 1971.

A business note: my ten-month Mozilla Fellowship has supported this project up until now, but that has ended. If you like what I'm doing here, please consider supporting me via my Patreon.

The technical content

The author wishes to share his concerns about the interrupt function in the Host/Host protocol. He breaks his document into three sections: The Problem, A Solution, and Commentary. I'll borrow this nomenclature.

The problem

The problem as he states it is that the interrupt key or break key (or “help request button”!) does two things:

  • it halts the user process
  • it switches the keyboard input stream, but anything before that point in time is still sent to the halted process; anything after is for the “supervisory” process, in most cases I'd guess the operating system shell

Kalin's problem is that the interrupt function of the NCP communicates information about halting a remote process, but it doesn't tell the remote host when to stop accepting keyboard input. Because the interrupt command for the NCP travels on an totally parallel connection (the control link) to the data itself, the receiving host can't guarantee that the “interrupt” will arrive at the exact order relative to all the keystrokes you're receiving that it was sent in. For example a user might send L I S T [INTERRPUT] L O G O U T but the receiving host might read chronologically L I S T L O G O U T [INTERRUPT]. So while the user intended “LIST” for the user process and “LOGOUT” for the operating system, the receiving host would attempt to run “LIST” followed by “LOGOUT” on the user process, and only then break to the operating system.

A solution

He points out that encoding the interrupt as ASCII in the data stream doesn't work for all ARPANET computers (again see RFC-48 for an example why).

He suggests that all character data be sent in 8-bit chunks. Since ASCII characters require the use of 7 bits of data, but the words on the IMP are in 8 bits, he suggests a scheme that uses the high bit to send control characters like interrupt.

He notes that this could still fail if the receiving host is out of memory, so the interrupt on the separate control link should still exist. When a computer gets that interrupt, it needs to scan for the ASCII character and synchronize everything up. But in the case of a failure, perhaps for out of memory reasons, the receiving host still process an interrupt and can at least guess at what to do next.

Commentary

Kalin notes that this only works for 7-bit ASCII! There were literally scores of competing character encodings, many of which used 8 bits, and this would not work for either of them. He also notes that the scanning solution kinda sucks. And there are cases that could cause infinite loops on the remote computer.

In his estimation, the real solution is a significant rewrite of the NCP protocol. His proposal here is merely a patch until the next design revision.

Analysis

Kalin authored RFC-60, which I felt was pretty persuasively written, and once again he delivers with a really well-organized rhetorical argument.

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

The Glitch Cleaning Committee

RFC-102 is titled “Output of the Host/Host Protocol Glitch Cleaning Committee”. Its primary author is Steve Crocker in his role as Chairman of said committee. It's dated February 22-23, 1971.

A business note: my ten-month Mozilla Fellowship has supported this project up until now, but that has ended. If you like what I'm doing here, please consider supporting me via my Patreon.

The technical content

This committee was formed just a week before at the Urbana NWG meeting to tackle different Host-Host protocol issues, including:

  1. Echo
  2. Message type
  3. Interrupts
  4. Marking and/or padding
  5. Half duplex vs. full duplex communication during initial socket connection

I've discussed all of thes topics here before, and message types and marking/padding have had multiple RFCs devoted to them. So they're all pretty contentious issues.

The RFC is mercifully short and is truly focused on “output”, meaning the agreements that everyone came to about these problems.

  • They settle on the bit length of several different commands.
  • They agree to elimintate message data types from the Host/Host protocol, saying that these are more appropriate for higher level protocols.
  • They get rid of ACK (CEASE) which is a message that says “I got your message but I'm out of memory so please stop sending me stuff”
  • They add some commands so that a computer can tell another computer “I messed up, please disregard all your knowledge of what I'm doing because I have fully reset”
  • They agree with RFC-64 and get rid of marking. They also state that the header (“leader” in their terms) of a message should be followed with a number indicating the length of the remaining message in bytes, along with the byte size. (Recall that there are all sorts of byte length computers at this point including 12-bit, 10-bit, 24-bit, and other esoteric numbers.)
  • They want to implement a third-level interrupt code that is independent of the individual interrupt characters for computers. Recalling that some computers even interpret 250 milliseconds of silence as an interrupt command, it seems reasonable to side-step the issue entirely.

Some unresolved issues remain, too.

  • whether to limit the length of control messages
  • where to begin the first byte of data: should there be one message comprised of a header, byte count, and byte size, followed by padding and then the data itself? Or should there be two wholly separate messages, one with the byte count and byte size, and then a second message with the data?
  • whether to change the algorithm for remote memory allocation

Analysis

Okay first of all: Glitch Cleaning Committee! What a cool name.

This meeting has been described (see “Further reading” section below) as the final settlement of the Host/Host protocol, which has been in flux for almost two years at this point, since RFC-1.

Also, this RFC mentions that the interrupt character on the PDP-10 is control+c, which if you're a programmer or just a command line terminal user you've probably encountered and perhaps use on a daily basis. I don't know if the PDP-10 is the originator of control+c to interrupt a program but that's pretty neat anyway.

Further reading

The ARPANET Completion Report describes the meeting of this committee:

At a NWG meeting held in mid-February 1971 at the University of Illinois, a subcommittee was appointed to look at the host-to-host protocol to see what changes were immediately desirable or necessary. This subcommittee went directly from Illinois to Cambridge, Massachusetts, where it met for two days, wrote an interim report, and then reconvened a month later in Los Angeles. It appears that with the efforts of this committee (known as the “host-to-host protocol glitch cleaning committee”) the design of the ARPANET host-to-host protocol was finally coming close to being settled.

So people flew from the Illinois meeting described in RFC-101 straight to Cambridge for this meeting! Anyway, this report is a 200 page document prepared in January 1978 to sum up the whole decade of the ARPANET project. There's lots of good stuff in there.

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

A winter meeting

RFC-101 is titled “Notes on the Network Working Group Meeting”. It's authored by Richard W. Watson of SRI-ARC and dated February 23, 1971.

A business note: my ten-month Mozilla Fellowship has supported this project up until now, but that has ended. If you like what I'm doing here, please consider supporting me via my Patreon.

The technical content

This RFC is a summary of the quarterly NWG meeting held at the University of Illinois on February 17th-19th, 1971. These quarterly meetings were formally announced in RFC-85.

There was discussion of a cool use of the ARPANET. Apparently by the spring of 1970, SRI needed to ditch their XDS 940 computer and replace it with a PDP-10. But it can take a long time to learn a new computer system, so what they did was utilize timesharing via the ARPANET to train their staff on the PDP-10 at the University of Utah! By June 1970 they were using their 940 to generate source code for the PDP-10, which they would then send to Utah over the network. Then they'd remotely run and debug those programs interactively.

At the SRI and Utah ends a control program allowing three users to connect to Utah was written, which ran as a user process and allowed character interaction and files to be transmitted.  The scheme worked well and much useful work was accomplished in the July--December period with some people on 4-5 hours per day.  The voice link was used when something would go wrong in trying to determine where the problem existed and to reset.  At times they would go 2 weeks with no problems.

The “voice link” mentioned there is basically getting the other end of the network on the telephone to work out what was going wrong. It's like in 2019 when a video conference doesn't work and you have to call the cell phone of someone in the video conference to figure out what's going on.

Round trip character delays of 4 seconds were not uncommon, and at certain points delays of 8 or 10 minutes were experienced.  These delays were the result of the implementation used which involved multiple processes at each end, each to be scheduled.  Utah was heavily loaded at 2:00 PM and the SRI people took to running at night and on weekends.

So around 2pm it could take multiple minutes to talk to the computer at Utah from SRI — as a result people started doing the work on nights and weekends.

By December 1970, SRI received their PDP-10 and got to put their six months of remote work to use on an in-person computer. Pretty cool stuff.

There is mention that UCSB has teamed up with Rand Corporation to “experiment in use of the Network for the climate study at RAND”. I imagine that this is related to the work from RFC authors Harslem and Heafner that would be published by the end of 1971, VIEW: Status Report of a Computer Program for Display of Arbitrary Data Bases, which is about a remote data visualization program that according to the paper's abstract is designed “to cope with the mass of data produced by climate dynamics simulations”. More on this in “Further reading” below.

Steve Crocker says he thinks there should be working committees on important topics within the Network Working Group and proposes the following areas:

      1. Graphics

      2. Data Transformation Languages

      3. Host-Host Protocol -- long range study

      4. Host-Host Protocol -- Short term maintenance and modifications

      5. Accounting

      6. Logger Protocol

      7. Typewriter connection protocol

      8. Documentation

      9. Data Management

In this context, “accounting” means “ways to track the time that people use on your computer so you can charge them money for it.” Various such committees are proposed, at least for the first 4 categories.

There is a representative of the Canadian government present at this meeting. Specifically it's C.D. “Terry” Shepard of the Canadian Computer/Communications Task Force. The task force sent a representative because Canada wants their own internet so they won't be fully dependent on foreign sources for computing resources in the future.

There is some discussion of some networking projects internal to IBM, one of which uses a “central machine for control and flow distribution”, which they “are not entirely happy” about and want to be more decentralized like ARPANET.

The meeting adjourns and then continues the following morning.

BBN gives an update on the network of IMPs, and various groups give updates to their progress on their own network control programs (NCPs).

There is also an update to the NWG mailing list procedures. Remember, this is still pre-email and still coordinated through secretaries maintaining manual lists of addresses and sending copies of memos via the postal service!

Subcommittees are formed for the above issues number 6 and 7, the logger protocol and typewriter connection protocol.

In the afternoon the University of Illinois gave a demonstration of PLATO, their famous interactive graphical learning system. (There's a modern PLATO descendant called Cyber1 and you can get a login and download the terminal program to try it out!)

In the evening the Network Information Center at SRI is discussed. As of 1971 the NIC is basically a library of documents that also is involved in network administration like maintaining hot tables. This will eventually become the organization that administers DNS in its early years. Anyway, its function as a kind of library is clear in these notes from the NIC presentation:

If the network is really going to develop the feeling of a community, people need to be aware of what people are doing and thinking at the various sites.  Therefore, people were encouraged to send reports, memos, notes, records of conversations of general interest through the NIC.  Any kind of information can be sent through the NIC from formal reports to informal handwritten notes.

This is followed by considerable discussion of computerized cataloguing systems and remote access to the NIC via ARPANET. This naturally becomes a discussion about file transfer protocols, which we are going to hear a lot more about in the next 100 RFCs. This all cover the “documentation” portion of Crocker's agenda.

The meeting adjourns for the day. The next morning, data management and accounting, the last unaddressed issues in the agenda, are discussed. There are a number of aspects to data management, but basically it comes down to:

  • the “trillion bit store”, which is conceived as a (massive for the time) shared hard drive for the ARPANET (related paper here)
  • the “form machine” for translating between data types (see RFC-83)
  • a file transfer protocol of some kind

And finally they tackle accounting, AKA the process of figuring out how much money to bill users of time shared computers. This seems like everyone's least favorite subject. Bob Kahn says he'll write a paper on the issues of accounting, which I believe ends up being RFC-136.

Lastly, consensus seems to be that for future meetings, papers related to discussion areas should be sent out a month in advance so that attendees can be prepared to have more in-depth discussions than were possible this time.

Analysis

The University of Illinois at Urbana has long been one of the great American computer science powerhouse universities. The RFC opens with Mike Sher telling the group that ILLIAC IV, which according to Wikipedia is “the first massively parallel computer”, would be ready in the summer of 1971. With hindsight we know that his estimate was about a year off.

Apparently U of I has an IMP at the time of this NWG meeting, but it is not connected to their PDP-11. It was initially unclear to me whether this means it's not connected to anything at all though. If we look at BBN Report No. 2103 from January 1971 (one month before this meeting) we see on page 11 that Illinois is reported as connected, BUT that is only a report on their IMP having been installed and connected, and nothing to do with whether it's actually in use.

A page from BBN Report No 2103 showing a graph of all connected IMPs..

This December 1970 ARPANET map shows Illinois is not connected, and a September 1971 ARAPNET map shows that they are. So presumably at the time of the meeting the IMP at Illinois was not in use by the U of I, though according to BBN's reports it was already routing packets to and from Utah and MIT.

Further reading

Since there was mention of Rand Corporation's climate studies, I thought I'd link to a few fascinating ones that you can read the full text of for free.

Studies in Climate Dynamics for Environmental Security by R.C. Alexander, September 1970. This is a paper about responding to adversarial geoengineering and how we might predict the ways that climate change could affect the weather! (Turns out, the call was mostly coming from inside the house.)

A Model of Global Climate and Ecology is a heavily cited paper by Graham and Warshaw, also dated September 1970, that lays out some of the first mathematical models for global climate.

The Statistical Analysis of Simulated Climatic Change by M. Warshaw, September 1973, lays out some ways that you might be able to determine whether changes in global climate are the result of random fluctuation or are the result of some kind of anthropogenic (intentional or unintentional) source.

For more context on the Canadian Computer/Communications Task Force, you can read this really interesting 1994 article by Bernard Ostry that is highly critical of Canada's internet and telecommunications infrastructure. He says of the Task Force that it

reported its findings in 1972 in a two-volume study entitled Branching Out. The Task Force offered 39 recommendations and some suggestions. Action was taken in four cases, and begun in five others which were discontinued. Twenty-four recommendations appear to have been ignored, despite a green paper which followed about a year later commending the importance of the report.

I'd love to find a copy of “Branching Out”, but I can't find any scans online. I may need to head to Ottawa to get my hands on a hard copy...

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 both ActivityPub and the Dat Project. You can support my work via my Patreon.

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

A catalog

RFC-100 is titled “Categorization and Guide to NWG/RFCs”. It's by Peggy M. Karp of MITRE and dated February 26th, 1971.

The technical content

This document lists all RFCs to date, first by category, then in numerical order with cross references to the categories for the documents. It's similar to how card catalog systems used to organize documents at libraries, which if you are of a certain age you'll remember using. (I suspect I'm on the cusp and most people younger than me never used these.)

The document offers a “minimum subset of RFCs”, which are basically the must-read RFCs for anyone who wishes to be caught up to NWG discussions as of February 1971. And further, that the list is short enough that it “should dispel any fear of maintaining stacks of NWG/RFCs for quick reference.”

The subset is as follows (links to my own blog posts and their titles):

As well as this very RFC and the next two, 101 and 102.

The categories listed are, broadly:

  • Administrative
  • Host/IMP Protocol (Level 1)
  • Host/Host Protocol (Level 2)
  • Subsystem Level Protocol (Level 3)
  • Measurement of Network
  • Network Experience
  • Site Documentation
  • Accounting
  • Other

Most categories have sub-categories that you can read in the original document.

This document is slated to become part of a separate, non-RFC series of documents, although I'm not sure if that series ever came to pass (there are many more of these catalogs in the RFC series itself over the years).

Analysis

This document is RFC-100 but the author notes at the beginning that there are already 102 RFCs. And indeed, RFCs 101 and 102 are dated three days before this one. I don't know if they simply wanted RFC-100 to be used for this catalog, or if the RFC numbers were assigned prior to the final RFC being sent to the NWG members.

The list of categories is the first official confirmation of levels 1, 2, and 3.

Further reading

The author notes that

reference to “#33, #66, #83, etc.” is a convenient shorthand (reminiscent of the old corny joke about joke #s) used extensively during meetings.

The joke referred goes something like this: a guy goes to prison. He becomes aware of a weird phenomenon where he'll hear someone yell a number like “71!” and people laugh. His bunk mate explains to him that the jokes here are so stale and repetetive that they've just numbered them all to save time. So the guy yells out a random number. At this point the punchline is either: everyone laughs and says “wow we've never heard that one before”, or nobody laughs and the bunkmate says “wow, some guys just are no good at telling jokes.”

I assume the implication here is that attending a Network Working Group meeting is more or less like being in prison.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

Atlantic City again

RFC-99 is titled “Network Meeting”. It's authored by Peggy M. Karp of MITRE. In November 1970 she was appointed the position of RFC editor.

The technical content

As in the previous year, the Network Working Group will meet at the Spring Joint Computer Conference in Atlantic City. Their meeting will be at the historic (and near bankruptcy by 1971) Dennis Hotel. MITRE, via Karp's secretary, is handling the hotel reservations to ensure everyone stays at the same hotel.

The meeting will span the evening of Sunday May 16th through Thursday May 20th. This is about twice as long as their last Network Meeting.

Further reading

By the way! Americans might know Atlantic City as a place for casino gambling (it was at one point essentially the Las Vegas of the east coast). But casino gambling was not legal there until 1976, well after the timeline of these Joint Computer Conferences. In 1971, Atlantic City was primarily known as a resort destination on the beach with huge hotels and the ability to host large business conventions.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

Logging in

RFC-98 is titled “Logger Protocol Proposal”, authored by Edwin W Meyer, Jr. and Thomas P. Skinner of MIT's Project MAC. It's dated February 11, 1971.

The technical content

The authors state that since the Host-Host protocol is at least somewhat “done”, the next step of ARPANET on a software level should be the development of a “logger protocol”. When a programmer today hears “logger” they might think of a program that writes messages to, for example, an error log, which is a log book that you can audit to see what went wrong with a program. This is not what they mean here.

In this paper, a “logger protocol” is meant to define how “log in” to a remote computer. At the time of this RFC, you had to log in to different systems using different mechanisms. The proposal here is trying to make a single mechanism for login (kind of like various flavors of OAuth try to do on the web).

They suggest tackling this kind of system before attempting a file transfer system because they suspect it's simpler to do, and still necessary, so they might as well get it out of the way first before tackling the big problem.

The authors break the login process into three parts:

  1. “Connection phase”, the establishment of an initial connection
  2. “Dialog phase”, for verification that the user has the right to use the system
  3. “Admission phase”, when the program hands off control from the logger to a system process so the user is no longer just talking to the logger

For the connection phase, the authors endorse the one laid out in RFC-80 from Harslem and Heafner of RAND. But the authors of this RFC also note that disconnection is important: the connections and links need to be cleaned up and freed if this occurs for any reason.

Next is the dialog phase, the actual “logging in” part, where you say “I am user X and I would like access to this computer”. The RFC says that there should be a standard character encoding here and that it should probably be ASCII. Dialog occurs in “transaction blocks” which are sets of ASCII characters preceded by a command code (which is always 0), and then a binary integer indicating the number of characters to be expected in the block (0 to 127; the most significant bit is always 0 so it's a 7-bit number). The character length indicator is to get around some of the character-based vs line-based processing issues we continually encounter.

They don't specify anything for the admission phase, and they note that this is probably going to be trivial in a lot of cases.

They end the document on a note about some edge cases.

First they discuss echoplex (not to be confused with the tape delay effect. Most teletype machines, when you pressed a key like A, would simultaneously move the mechanical print head to print “A” on paper and also send A to the computer. A teletype with echoplex would wait until it got confirmation from the computer that it received A before printing “A” on your roll of paper. Logins should not support this, to reduce complexity.

If someone makes a mistake while logging in, they can use “input editing conventions” to fix it, or just abort their connection and restart the login process.

The logger should only allow an idle connection for “perhaps a minute” until dropping the connection.

Under the current scheme the logger would need to assign a local socket before login was complete; it might be useful in future cases to assign a specific local socket during the admission phase, after the user's identity is determined.

Analysis

In addition to the authors' pragmatic reasoning for wanting a login protocol, they also posit that

agreement on a common [login] protocol would tend to foster a sense of Network “community”, which would tend to be fragmented [without a common protocol.]

I haven't seen an assertion like this before in the RFC series and it's an interesting one. It makes sense that it would come from Multicians, whose extremely strong community exists to this day. Sitting here in 2019 it seems almost obvious that common protocols would foster community, but I think the idea would have been far less obvious in 1971.

When discussing disconnection the authors note that when a user disconnects, their associated processes should also stop. This reminds me of modern Unix systems, where disconnecting from an ssh connection will stop your processes unless you specify that they are to be run continuously in your absence via something like nohup.

The recommendation of ASCII for the dialog phase may explain why lots of computers still balk at the idea of having an accented character in a username. Recall that ASCII doesn't support characters like é.

Further reading

Forgive me but I'm about to digress about typography. I believe this is the first RFC chronologically in the RFC Editor site to have its own HTML rendering. Something about the strictly-justified text formatting causes me to suspect it might have been formatted in RUNOFF, which would certainly make sense given that RUNOFF was developed for Multics, and Project MAC was the home of Multics. (By “justified” I mean the number of spaces between words is varied between one and two in order to make the length of each line exactly 72 characters per line, which makes it a “72 CPL” text document. According to Wikipedia many teletypes could print up to but no more than 72 characters per line.)

Dave Walden once again comes to the rescue here with his paper, “An informal look into the history of digital typography”. In it, he references the CTSS Programmer's Guide, written in December 1966, which in its introduction highlights justification as a key RUNOFF feature.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

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

A Telnet protocol

RFC-97 is called “A First Cut at a Proposed Telnet Protocol”. It is authored by John T. Melvin and Richard W. Watson of SRI-ARC and dated February 15th, 1971.

In addition to the usual text version of the RFC, there is a scanned PDF version you can read at the official RFC Editor site.

The technical content

If you'll recall, the last formal document on Telnet was RFC-15 way back in September 1969. That RFC proposed something called “Telnet” and loosely described what it did, but was not specific enough to be a formal specification for consistent implementation. As a result, Telnet was implemented in more than one site but in different ways. This RFC is the first attempt to formalize Telnet.

One big thing set out here is that an important convention is to have Telnet itself sit in between the NCP of the Host and what we'd today call I/O (input/output) device interfaces. Basically, from the point of view of computer with Telnet installed on it, Telnet is just another piece of hardware. The computer doesn't care if character messages are coming from Telnet via ARPANET or from a teletype machine hooked up directly to the computer. Similarly, writing to Telnet from a computer should be like writing to a teletype for output. Meanwhile, Telnet is what talks to the NCP. This is laid out in Figure 1:

A flow chart: User Terminal to Terminal Control HW/SW to Telnet to NCP to Network to NCP to Terminal Control HW/SW to Server Program

There will be situations where the user might want to talk directly to the NCP so the authors recommend that direct connection to the NCP from user processes should still be allowed.

The authors establish that instead of using the terms “full/half duplex” for different kinds of connections they will instead talk about “echo control” methods. This is because Telnet connections are all actually full duplex. There will be different command modes for the cases described in previous RFCs with character-at-a-time transmission or line-by-line transmission.

Servers will assume that any remote connections will use the default character set that the server is used to. Control characters and two-character sequences pose a problem. (They still do today in all sorts of computing applications.)

Analysis

Section 3E begins,

The carriage return (CR) character can be the source of considerable difficulty.

This character vexes programmers five decades later and is still the source of countless bugs and even security holes.

Further reading

Here's a history of line ending encoding by Luke Maciak that nicely summarizes all the context around CR/LF, including the role that teletype machines played. I learned from this that there's a reason that carriage return almost always precedes line feed, aka why it's CR/LF and not LF/CR. The reason? Carriage return is the movement of the print/type head from the far right to the far left of the paper and takes a while to happen. Line feed is just scrolling the paper a fraction down so the next line can be printed. Since CR takes longer than LF and both could happen at the same time, by sending a CR/LF command you could get a “free” line feed without having to wait for the carriage return to finish! (On slow teletypes this would make no difference.) Here is a timing diagram with some timings I completely made up but it gets the idea across:

A timing diagram that shows an LF command occurring during the entirety of a CR command, assuming some kind of clock latching the inputs.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

Enter your email to subscribe to updates.