RFC-205
by Darius Kazemi, July 24 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 for text editors
RFC-205 is titled “NETCRT – A Character Display Protocol”. It's authored by Bob Braden of UCLA and dated August 6, 1971.
The technical content
We learn of a system that hasn't been mentioned in an RFC before: URSA, which is a “conversational remote job entry” system at UCLA. It's a more interactive RJE system than the ones we have previously heard about. In particular, URSA is designed with a full-screen text editor, the kind of thing that you probably use every day: an entire page of the document is shown on a screen at once, and you can move a cursor around and edit whole paragraphs at a time. While this is normal today, many text editors in 1971 are what are called “line editors”, and are designed for teletypes, which you may remember are souped-up typewriters that support input and output. A typewriter only lets you edit one line of a document at a time, and that is what a line editor is optimized for. (I mentioned this in my RFC-46 post, but there is a great article about the history of the line editor called Where Vim Came From that is absolutely worth a read.)
Because TELNET is designed for teletypes, and hence line editors, it is not suitable for full-screen text editors like the one running on URSA. So this RFC introduces a new protocol called NETCRT to remedy the problem.
At the moment of publication of this RFC, NETCRT has not yet been implemented, and UCLA only plans to implement it if there is interest from a number of other ARPANET sites in accessing their URSA system.
Like the latest incarnation of TELNET, NETCRT is organized around the concept of a virtual display terminal simulated in the user host. The virtual terminal has a display capable of showing N lines of M characters in its display, and also an N x M memory buffer that you write to. Updating a character in the memory buffer will update it on the screen. Writing to the memory buffer is controlled by a “cursor register” which addresses locations in the buffer. The virtual terminal also has a special communications channel through which it receives control commands from the server.
The cursor register's current location is indicated by an underscore or other suitable effect on the screen. When a user issues a “transmit” command, the keyboard is locked and a portion of the data on the screen is sent to the server, which then responds with some kind of new information drawn to the screen and then unlocks the keyboard. There are also up-down-left-right commands to move the cursor location on the screen, a clear screen command, and a way to send an interrupt message to the server.
Braden complains about “squishiness” built into the Network Control Programs at various ARPANET sites. I'm assuming this refers to inconsistent response times that make interactive applications frustrating to 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.