RFC-189
by Darius Kazemi, July 8 2019
In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.
Some compliance with standards
RFC-189 is titled “Interim NETRJS Specifications” and authored by Robert T. Braden of UCLA's Campus Computing Network. It's dated July 15, 1971.
The technical content
This RFC is an update to RFC-88, which first introduced NETRJS, the NETwork Remote Job Service. As of July 1971, RAND and UCLA are connected to one another and using NETRJS to run programs on each other's computing systems.
I'll quote myself from my RFC-88 blog, where I say that NETRJS
lets you, for example, enter a batch of Fortran commands on a punch card system and then send them over the network to a computer to process as a “job”. You can also log in to the remote computer and ask it for the status of your job. You can submit a “stack of consecutive jobs” as well.
One difference between this version of NETRJS and the RFC-88 version is the introduction of a “virtual remote batch terminal”—when a NETRJS client connects to a NETRJS server, the server sees the abstracted virtual terminal on the other end. This virtual terminal can provide “virtual card readers, printers, and punches.” Card images can be transferred and spooled into the IBM 360 system running at UCLA. Since it's an IBM 360 system, the UCLA system uses EBCDIC instead of ASCII, so the NETRJS server handles all conversion from any incoming ASCII terminals to EBCDIC and then back to ASCII for return to the client. ASCII terminals are meant to connect via the Initial Connection Protocol to socket 13 at host 1, and EBCDIC terminals are meant to connect to socket 11 at host 1. Providing different sockets for different character encodings makes things much simpler for the NETRJS server; no complex dance has to happen to figure out what kind of system you're getting a message from.
The RFC-88 version of this protocol simply asked that people convert ASCII to EBCDIC themselves in order to use the service. I think it's pretty clear at this point that ASCII is no longer an ignorable character encoding.
This version also uses TELNET over ASCII as a mediating protocol for the actual control portion of the connection. While EBCDIC data may be transferred during a connection, the actual operation and commands sent are done over ASCII, and via TELNET at that. They specifically use the EBCDIC-to-ASCII character mappings defined in the RFC-158 TELNET protocol. Yet another example of an early protocol changing to suit the new norms of the ARPANET.
There is an immediate future plan to make NETRJS conform with the Data Transfer Protocol described in RFC-171, though these are going to be minor changes overall. This would mean that operations happen over DTP, and data transfer itself happens over DTP, which would make NETRJS fully compliant with existing protocols for anything happening over the wire! This could mean that if users at a computer system running some arcane operating system would like to join ARPANET and use NETRJS, most of the work that they'd do writing a NETRJS client would in theory be reusable for other applications.
Further reading
Bob Braden died in April 2018. For more on Braden:
- a long, fascinating interview with him at the Charles Babbage Institute
- an audio interview with him from 1993 that I have yet to listen to
- the IETF blog post written on news of his passing
How to follow this blog
You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.
About me
I'm Darius Kazemi. I'm an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.