RFC 205
NETCRT - a character display protocol
Okay bestie, the title block first 🎀
- Network Working Group 🌸
- Request for Comments: 205 ✨
- NIC: 7172
- Author: R. Braden, UCLA/CCN 💅
- Date: 6 August 1971 🦋
- This header has no category, obsoletes or updates lines.
NETCRT - A CHARACTER DISPLAY PROTOCOL 💖
okay so at the May NWG meeting, CCN passed around dittoed copies of a proposed character-display protocol called NETCRT 📄 since then NETCRT has been revised significantly 🔥 and the current version is finally being published as an RFC, just like they promised last May 🫶
NETCRT exists because a site called RAND asked for Network access to URSA, CCN's display-based crje system 👑 the main thing people do with URSA at UCLA is conversational remote job entry from a display terminal. that means entering and editing program text, submitting programs for batch execution, and checking job output 💻 URSA is not a general-purpose time-sharing system, so don't come for it like it is 🙈
URSA's text editor is built for a fast updating character display and can't be used in any reasonable way from a typewriter-like console 😭 so a simple TELNET protocol isn't enough for using URSA's crje function. ALSO, CCN assumes other ARPA sites will have their own text editors that are well matched to their own terminals and systems 🧚 that's why CCN built NETRJS first (see RFC #189) to handle remote job submission and retrieval services, before it built NETCRT 🌈
URSA has a bunch of other functions too, and some of them would probably be useful to remote users 🍓 the STATus service is a whole vibe: its constantly-updating displays are "windows" into how the machine and operating system are running, so a user can watch their jobs move through the system 👀 URSA also has on-line data set (file) utilities, which are super convenient if you keep files stored at CCN ✨ to get access to all of that, a few sites that use CCN heavily might want to implement NETCRT 💜 CCN's schedule for implementing NETCRT so Network users can reach URSA depends on there being a user site that wants the service and will write a suitable NETCRT user process 🙏 interested sites should contact the CCN Technical Liaison, Bob Braden 📞
the implementation schedule is kind of nebulous, but CCN is publishing the specs now anyway 🦋 reasons: first, they want comments and criticisms 💬 also, NETCRT has some features that might be useful in the protocol(s) being developed now for full graphical displays 🎀
NETCRT PROTOCOL - VERSION 3 🌟
A. INTRODUCTION ✨
the UCLA Campus Computing Network (CCN) node plans to give Network access to its conversational remote job entry system, URSA 💻 URSA is display-oriented and only supports character displays with local buffers (originally IBM 2260 displays, now CCI 301 TV display consoles) 📺 this document defines a third-level protocol called NETCRT, which lets a Network user on a remote Host look like a CCI console to URSA 🧚 NETCRT is defined in terms of a virtual character display ("VCD") terminal, which gets simulated by a process in the user host 🪞
URSA, like a lot of on-line console systems, tries to give a good man/machine interaction by keeping tight control over the state of the terminal 🎯 the Network Working Group, on the other hand, deliberately built some "squishiness" into the standard Network protocols 🫠 CCN believes that squishiness is a conceptual mistake when you're dealing with remote man/machine interaction, and it would support protocol revisions that let processes in different hosts control their effective communication compliance 💅 BUT this NETCRT protocol is trying to cope with the present squishiness, which is apparently built into a number of hosts' NCPs 😤 the good news is a host can improve response time and reduce Network traffic with NETCRT by using the message buffering inherent in his NCP 🌸
B. THE VIRTUAL CHARACTER DISPLAY 🖥️
okay so a VCD is made up of the following virtual hardware (see Figure 1) 🔧
- A rectangular display screen capable of displaying N lines of M characters.
- A local buffer of M x N characters used to refresh the display.
- A cursor register which addresses the characters in the buffer (and hence on the screen). This register controls the writing of text into the local buffer from either the keyboard or the server, and the reading of the local buffer by the server.
- A keyboard containing text keys and control keys. Each text key enters a character into local buffer at the current cursor address and steps the cursor register by 1.
- A communication interface through which the server CPU can send a stream of command segments to the VCD and receive a stream of response segments from the VCD. The command segments include control commands to the VCD and text to be written into the local buffer. Response segments contain status indicators and text read from the buffer. In addition, both VCD and server may send break signals.
the current address in the cursor register, an integer between 0 and M x N-1, shows up as a blitch, underscore, or other visual indication at the matching point on the screen 🫧 that indication is called the cursor. Position 0 is the upper left corner of the screen 📍
the screen is addressed in line ("row") order, and read and write operations by the server overflow automatically from one line to the next 🌊 the cursor register is not assumed to operate modulo M x Nxsy. it IS possible for a server command to set the cursor register to M x N, one position beyond the last screen position 🙃 however, the server should never set the register to an address beyond M x N, and it should not leave the cursor at M x N when the keyboard is unlocked 🚫
the application program or conversational system using the VCD can format each display screen in a bunch of different ways and use a number of styles of interaction 🎨 one result is that the application program might have to look anywhere on the screen (i.e., in the local buffer) to find the input information it needs 👀 there are three alternative mechanisms for sending information from the VCD to the serving CPU 💭
Mechanism 1 Whenever the user presses a "Transmit" control key,
the entire M x N characters in the buffer are
transmitted to the server CPU.
Mechanism 2 When the user presses "Transmit", the string of text
between a "start" control character and the cursor is
transmitted to the server.
Mechanism 3 The server must send a read command segment to the VCD
before the "Transmit" key will have an effect. The
read command segment determines which parts of the
buffer are to be transmitted to the server.Mechanism 1 might be called too costly in transmission time and channel capacity, and Mechanism 2 is too restrictive 😬 the scheme proposed here is based on Mechanism 3, which subsumes the other two ✨
the VCD is assumed to include the following control keys 🎹
Erase Clears the display buffer to all blanks and resets the
cursor to position 0 (the upper left corner of the
screen).
Transmit Locks the keyboard and places the VCD under control of
the server CPU. Typically, the server will read
specified areas of the screen and perhaps write out
new data before unlocking the keyboard again.
Break Has the same effect as _Transmit_, and in addition
sends an interrupt message to the server CPU. The
_Break_ key always sends the interrupt, regardless of
the state of the VCD.
Reset May be used to unlock the VCD keyboard in case the
server CPU fails to respond immediately and the user
wishes to enter new or different information.these may be called pure control keys, since they don't correspond to any text characters 🤷♀️ the following control key does store a character into the display buffer 🧐
Newline Enter a Newline (NL) character into the display buffer
and reset the cursor to the beginning of the next
line. If this character is encountered during a read
or write operation, it is executed (i.e., the cursor
is moved to the beginning of the next line) and the NL
is counted as _one_ character.and finally, there are assumed to be keys for manually positioning the cursor to any address on the screen 🏃♀️ cursor positioning keys may include: cursor right, cursor up, cursor left (BS), cursor down (LF), and cursor return (CR) 💖 a tab (HT) mechanism could also be defined, although none is included here 🎀
C. VCD STATES 🔮
the VCD has two internal states, Local and Control (see Figure 2) 🦋
- Local State: The keyboard is unlocked and all keys are active. The VCD does not accept or recognize any commands from server except (reverse) Break. 🔓
- Control State: The keyboard is locked, and only the Break and Reset keys are active. The VCD accepts and executes command segments from the server, and returns response segments as the result of read commands. 🔒
the VCD changes from Local to Control state if either:
- The user presses the Transmit key; or
- the user presses the Break key; or
- the server sends a reverse Break request.
Transmit's only effect is to enter Control State. Break enters Control State and also sends a break request (INS and X'80') to the server 📨
the VCD returns to Local State when either:
- The user presses the Reset key; or
- the VCD encounters a LOCAL command from the server and is not in the process of synchronizing a reverse break (see section E below).
we should note that CCI and IBM 2260 character display consoles actually have only one control key ("Interrupt" on CCI, "Enter" on 2260) to perform the functions of both Break and Transmit 🤯 this one key in fact has the function of the Break key of the VCD. we included both Break and Transmit keys in the VCD for generality, but the URSA-NETCRT interface will be programmed so a Network user of URSA can either (1) employ the Break key exclusively, or (2) use either Break or Transmit as appropriate 🎯 URSA will do this simply by ignoring those break requests (INS messages) which occur while there are outstanding read commands 🙌
D. VCD COMMANDS 💅
the server sends the VCD a string of command segments 📦 these are of varying length, consisting of an op code and none or more parameters 🧩 the commands recognized by the VCD are as follows:
1. Display & Keyboard Control Commands ✨
okay so first up are the display & keyboard commands 💖 these are the ones that wipe the screen, freeze it, and hand the keyboard over to the user 🎀
Command Parameter(s) Function
------- ------------ -----------------------------------
ERASE none Erase display and reset cursor to 0.
i.e, clear the local buffer.
BLANK none Disable display refresh (i.e., blank
the screen but do not clear the local
buffer).
UNBLANK none Enable display refresh.
LOCAL none Put VCD in _local_ state. The result
is to suspend command interpretation
and unlock the keyboard.
SYNC none Used to synchronize reverse Break
from server. SYNC (X'80) is placed
in stream by server at same time that
it sends an INS. VCD enters Control
State, synchronizes INS with BREAK
command (see next section), and
continues command interpretation.2. Cursor Control Commands ✨
the cursor is basically your little pointer 🦋 these commands move it around, and SAVE and RESTORE let you bookmark a spot and come back to it 🔖
CURSOR 16 bit integer P Set cursor register to P, where
0 <= P <= M x N.
FIND X'0001' followed Move the cursor to point to an
by one character occurrence of the character c.
c Specifically, search backwards
toward lower addresses) from the
current cursor position and take
the first occurrences of c (i.e.,
the one with the largest address).
If no occurrence is found, leave
cursor at position 0.
SAVE none Save a copy of the current cursor
address in local register S.
RESTORE none Replace cursor register contents by
value S.I/O Commands ✨
these are the ones that actually move text in and out 📥📤 the WRITE and READ family are the main characters here 💅
WRITE n,text 16 bit integer Write n bytes of text into display
n, followed by buffer starting at current cursor
n text bytes. position and advancing cursor by 1
for each byte (except NL character
advances to beginning of next line).
Here [sigma] + n <= M x N.
READ n 16 bit integer Read n bytes starting at the cursor
n. [sigma] and advancing cursor by one
for each byte (except NL advances
cursor to beginning of next line).
NL counts as one character. Send the
text to the server as a response
segment. Must have n + [sigma]
<= M x N.
SREAD none Read S - [sigma] bytes starting from
the current cursor position [sigma]
up to (but not including) the cursor
address stored in register S. The
cursor is left in position S as a
result. Send the text to the server
as a response segment.
AWRITE n,text 16 bit integer Same as WRITE n, except characters
n, followed by are not stored in buffer if they
n text bytes. have a lower cursor address than
the value in S.Here are some applications of these commands in URSA, and honestly these are so clever 🧠✨
- One elementary URSA terminal operation reads the screen from position x up to (but not including) the current cursor position. This could be done with the sequence of VCD command segments:
SAVE
CURSOR x
SREAD- Another common operation in URSA is to remember the cursor, update specific information on the screen, and replace the cursor. This can be done by the following 8 + n byte sequence of command segments:
SAVE
CURSOR x
WRITE n, text
RESTORE- In URSA, the area in which a user is to type his response is usually delimited on the left by a "Start Symbol" (graphic '[1]'). This is a historical remnant of the IBM 2260, which has only two hardware read operators: read the full screen, and read from the Start Manual Input Symbol ("SMI") to the cursor. The SMI read operation can be simulated easily on the VCD as follows:
SAVE
FIND '[1]'
SREAD- The _Break_ (or _Transmit_) key on the VCD may serve the function of the INTerrupt key on a CCI console (or ENTer on an IBM 2260). URSA will often attempt to minimize Network traffic by sending a sequence of commands (one message if allocation allows) like the following:
-+
CURSOR m |
WRITE n, text - URSA writes a request
LOCAL |
-+
-+
+- +-+ |_ User types response
| _BREAK_ | |
- -User Presses | _TRANSMIT_ |key - - -+
+- -+ -+
SAVE |
CURSOR p - URSA reads response
SREAD |
-+At other times, URSA might send the sequence:
CURSOR m
WRITE n,TEXT
LOCAL
READ 0and wait for the INS from the user pressing _Break_ (or the response segment triggered by the zero-length read if he presses _Transmit_); then URSA will send the appropriate read command sequence.
F. NETWORK MESSAGE FORMATS
okay now the network side 🌐 the VCD hooks up to the server through ICP and a standard socket, which gives you two connections between the VCD and the server 🔌💜 command segments go server-to-VCD, response segments go VCD-to-server, and both get sent over those connections without caring about physical message boundaries, using byte size 8.
the VCD runs in segment-at-a-time mode (not character-at-a-time) and does local echo, so the server never echoes under NETCRT 🙅♀️ that's the vibe.
URSA often sends a bunch of command segments at once (like in the examples above), and if there's enough allocation they all go in the same message 📦 so response time can get a boost if the user site can buffer ahead on command segments. buffering does cause break synchronization problems though 😭 and here's how they get solved for reverse (server-to-user) break:
The server sends an INS on the control link and also a SYNC command (X'80) on the data link to the VCD. When the VCD gets either one, it enters Control State and then gets the INS and BREAK synchronized. If the INS shows up first, the VCD runs all the commands buffered in its host as normal, except it ignores LOCAL commands until the SYNC appears. once they're synchronized, the VCD goes back to normal command interpretation, no longer ignoring LOCAL commands 🫶
this is how the server can take back control of the VCD to write new info at any time 🎀 for example, when URSA runs under NETCRT, most WRITE or AWRITE sequences will be preceded by a BREAK from the server, because URSA won't know the current state of the VCD. even if URSA left the VCD in Control State, the user might have manually switched the VCD back to Local State by pressing _Reset_ 🙈
After receiving an INS, the VCD executes buffered commands instead of ignoring them, so pending writes don't get lost in case processing on the user side got held up for a bit 💅 the read commands that run after the server sent an INS might be irrelevant to the server, which can ignore the matching response segments. to handle that, the server just keeps matching counts of the read commands it sent and the response segments it received 🧚
Command segments use the following formats:
Form 1 (No parameters):
q:OPCODE(8)
where q = X'80' means SYNC
X'91' " LOCAL
X'92' " ERASE
X'93' " BLANK
X'94' " UNBLANK
X'95' " SAVE
X'96' " RESTORE
X'97' " SREADForm 2 (16 bit integer):
q:OPCODE(8) + n:INTEGER(16)
where q = X'9E' means READ n
q = X'9C' " CURSOR n
In both cases, 0 <= n <= M x NForm 3 (count and text):
q:OPCODE(8) + n:LENGTH(16) + (TEXT(8) = n)
where q = X'9D' means WRITE
q = X'9A' means AWRITE
q = X'9F' and n=1 means FINDA response segment, caused by a READ or SREAD command, has the following format:
RESPONSE <-----X'A1' + CURSOR(16) + n:LENGTH(16) + (TEXT(8) = n)where n > 0 is the number of characters actually read. CURSOR(16) is an integer giving the final cursor position after the corresponding read command. Note that the command READ 0 is permissible and may be used by the server to find the current cursor position, or to find out when the user presses _Transmit_ 🍓
E. SCREEN SIZE
okay so here's the deal with screen size 📐 the cursor is treated as one single integer, because that's simpler and matches URSA 💖 which means the VCD and server have to agree on the number of columns M. it's also nice for the server to know N, too 🌸
the agreement happens through a one-sided negotiation. the server knows which M and N values it can handle, and those get published for user sites ✨ when the VCD first connects to the server, the VCD must send an Open response segment with the values M and N:
Open segment <---- X'B1' + M(8) + N(8) + X'0000'If the VCD fails to send this segment, or the server doesn't like the values, the server closes the connections and the user is considered logged off 👋💀
Endnotes ✨
okay bestie, we're in the endnotes now 🧚 and the first one is all about a little symbol. [1] says the start symbol is a shaded triangle lying on its side ▶ 💖
Next up is Figure 1, the whole VCD setup in one picture 🦋 It shows the DISPLAY sitting on top of a LOCAL BUFFER, with KEYBOARD text and control flowing into VCD CONTROL, a CURSOR ADDRESS REGISTER, an S REGISTER, and a COMM INTERFACE that trades COMMANDS and RESPONSES over the Network Connections 💅
+---------------+
| |
| D I S P L A Y |
+---------------+
^
|
| Refresh
|
+---------------+
| LOCAL | Address
| BUFFER |<------------+
+---------------+ |
^ ^ | |
+-----------+ text | | | |
/ |_______| | | |
| KEYBOARD | |WRITE |READ |
+-------------+ |AWRITE |SREAD |
| | |
control | v |
+---------------+ +---------------+
| VCD | | CURSOR ADDRESS|
| CONTROL |<--->| REGISTER |
+---------------+ +---------------+
^ | ^
| | |
| | |
| | |
| | |
| | v
| | +---------------+
| | | S |
| | | REGISTER |
| | +---------------+
| v
+---------------+
| COMM |
| INTERFACE |
+---------------+
^ |
| |
| v
COMMANDS RESPONSES
Network Connections
FIGURE 1. VIRTUAL CHARACTER DISPLAY
------------------------------------Last but not least, Figure 2 is the state diagram and honestly it's giving main character energy 👑 It starts with the keyboard unlocked and no commands executed, then bounces between the LOCAL state and the Control State depending on what happens. Hitting the Break key sends INS and X'80', an INS received moves things over to the Control State, and once INS has been received, any LOCAL command gets ignored until SYNC (X'80') shows up 🫶
Keyboard Unlocked
No Commands Executed
+--------------------+
| |
+------>| LOCAL |------+
| +--->| State | |
| | +--------------------+ |
| | | | |
| | | | |
| | |Break | |
| | | | | INS received
LOCAL | | | key | |
| | | [send INS | |
Command | | | and X'80'] | |
Executed| | | |Transmit|
| | Reset | | |
| | | | key |
| | key | | |
| | v v |
| | +--------------------+ |
| +---| Control |<------+
| | State |
+------| |
| +--------------------+
| ^
| | Keyboard locked,
| | Execute Commands
+------+
After INS is
received, LOCAL
command is ignored
until SYNC (X'80')
is encountered
FIGURE 2. VCD STATES
---------------------And that's the archive note, bestie 🌸 It tells us this RFC was put into machine readable form for the online RFC archives by Lorrie Shiota, back in 2/02 🎀
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Lorrie Shiota, 2/02]That's the whole doc, babe! 🌈💖✨
📦 where this page comes from
- ietf: rfc205 1971-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms