diff options
Diffstat (limited to 'doc/rfc/rfc205.txt')
| -rw-r--r-- | doc/rfc/rfc205.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc205.txt b/doc/rfc/rfc205.txt new file mode 100644 index 0000000..2899123 --- /dev/null +++ b/doc/rfc/rfc205.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group R. Braden +Request for Comments: 205 UCLA/CCN +NIC: 7172 6 August 1971 + + + NETCRT - A CHARACTER DISPLAY PROTOCOL + + At the May NWG, meeting, CCN circulated dittoed copies of a proposed + character-display protocol NETCRT. Since that time, NETCRT has been + revised significantly; the current version is now being published as + an RFC, as promised last May. + + NETCRT was developed because a particular site (RAND) requested + Network access to URSA, CCN's display-based crje system. The primary + use of URSA at UCLA is conversational remote job entry from a display + terminal: entering and editing program text, submitting programs for + batch execution, and examining job output; URSA is not a general- + purpose time-sharing system. + + URSA's text editor is designed for a fast updating character display + and cannot be used in any reasonable way from a typewriter-like + console. Therefore, a simple TELNET protocol is not adequate for + using the crje function of URSA. Furthermore, we have assumed that + other ARPA sites will have their own text editors, well matched to + their own terminals and systems. Therefore, CCN has implemented + NETRJS (see RFC #189), to provide remote job submission and retrieval + services, before implementing NETCRT. + + There are a number of other functions in URSA besides crje; some of + these would probably be useful to remote users. URSA contains a + comprehensive STATus service, whose constantly-updating displays are + "windows" into the operation of the machine and the operating system, + allowing a user to watch the progress of his jobs through the system. + URSA also includes on-line data set (file) utilities, convenient for + a user with files stored at CCN. To obtain access to these + facilities, a few sites which use CCN heavily may want to implement + NETCRT. The schedule for implementation of NETCRT at CCN to allow + Network access to URSA will depend upon the existence of a user site + that wants the service and that will write a suitable NETCRT user + process. Interested sites are urged to contact the CCN Technical + Liaison, Bob Braden. + + Even though the implementation schedule for NETCRT is nebulous, we + are publishing the specs now for several reasons. First, we would + like comments and criticisms. Furthermore, NETCRT contains some + features which may be useful in the protocol(s) now being developed + for full graphical displays. + + + + +Braden [Page 1] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + +NETCRT PROTOCOL - VERSION 3 + +A. INTRODUCTION + + The UCLA Campus Computing Network (CCN) node intends to provide + Network access to its conversational remote job entry system URSA. + The URSA system is display-oriented, supporting only 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 allows a Network user in a remote Host + to look like a CCI console to URSA. NETCRT is defined in terms of a + virtual character display ("VCD") terminal, simulated by a process in + the user host. + + URSA, like many on-line console systems, attempts to provide a good + man/machine interaction by keeping tight control over the state of + the terminal. On the other hand, the Network Working Group has + deliberately built some "squishiness" into the standard Network + protocols. We believe this squishiness is a conceptual mistake when + dealing with remote man/machine interaction, and we would support + protocol revisions to allow control over the effective communication + compliance between processes in different hosts. However, this + NETCRT protocol attempts to cope with the present squishiness, which + is apparently built into a number of host's NCPs. In fact, we have + arranged things so 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 + + A VCD consists of the following virtual hardware (see Figure 1): + + 1. A rectangular _display screen_ capable of displaying N lines of M + characters. + + 2. A _local buffer_ of M x N characters used to refresh the display. + + 3. 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. + + 4. 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. + + + + + + +Braden [Page 2] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + + 5. 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, is displayed as a blitch, underscore, or other visual + indication at the corresponding point on the screen; this 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 may + format each display screen in a variety of ways, and may use a number + of styles of interaction. One consequence 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 requires. We may consider + three alternative mechanisms for transmitting 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 may be faulted as too costly in transmission time and + channel capacity, while Mechanism 2 is too restrictive. The scheme + which we propose here is based on Mechanism 3, which subsumes the + other two. + + + + +Braden [Page 3] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + + 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 do not 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. + + 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. + + + + + + +Braden [Page 4] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + + 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: + + (1) The user presses the _Transmit_ key; or + + (2) the user presses the _Break_ key; or + + (3) 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: + + 1. The user presses the _Reset_ key; or + + 2. 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 + have included both _Break_ and _Transmit_ keys in the VCD for + generality, but the URSA-NETCRT interface will be programmed to allow + a Network user of URSA to either (1) employ the _Break_ key + exclusively, or (2) use either _Break_ or _Transmit_ as appropriate. + This will be achieved by URSA 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: + + + + + + + + + + +Braden [Page 5] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + +1. Display & Keyboard Control Commands: + + 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: + + 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. + + + + + +Braden [Page 6] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + +I/O Commands: + + 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: + + 1. 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 + + 2. 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: + + + + + + +Braden [Page 7] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + + SAVE + CURSOR x + WRITE n, text + RESTORE + + 3. 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 + + 4. 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 0 + + and 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. + + + +Braden [Page 8] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + +F. NETWORK MESSAGE FORMATS + + The VCD connects the server through ICP to a standard socket, + establishing thereby a pair of connections between the VCD and the + server. Command segments (server-to-VCD) and response segments + (VCD-to-server) are sent over these connections, without regard to + physical message boundaries, using byte size 8. The VCD is defined + to operate in a segment-at-a-time mode (rather than character-at-a- + time), with local echo. Therefore, the server never echoes under + NETCRT. + + In many cases URSA will send a sequence of command segments (as in + the examples of the preceding section) at once; if there is + sufficient allcocation they will be sent in the same message. + Response time may be improved, therefore, if the user site is able to + buffer ahead on command segments. This buffering does raise break + synchronization problems, which are solved in the following manner + 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. On receiving either, + the VCD enters Control State and then achieves synchronization + between the INS and BREAK; if the INS arrives first, the VCD + executes normally all commands buffered in his host, _except_ it + ignores LOCAL commands, until the SYNC appears. Having achieved + synchronization, the VCD continues normal command interpretation + (without ignoring ensuring LOCAL commands). + + By this means the server can regain control of the VCD to write new + information at any time. For example, when URSA is used under + NETCRT, most WRITE or AWRITE sequences will be preceded by a BREAK + from the server, since URSA will not know the current state of the + VCD. Even if URSA left the VCD in Control State, the user might have + manually returned his VCD to Local State by pressing _Reset_. + + After receiving an INS, the VCD executes rather than ignores buffered + commands so that pending writes will not be lost in case that + processing at the user side has been held up temporarily. The read + commands executed after the server sent an INS might be irrelevant to + a server, which can ignore the corresponding response segments. In + order to do so, the server simply keeps matching counts of read + commands sent and corresponding response segments received. + + Command segments will use the following formats: + + Form 1 (No parameters) q:OPCODE(8) + + where q = X'80' means SYNC + + + +Braden [Page 9] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + + + X'91' " LOCAL + + X'92' " ERASE + + X'93' " BLANK + + X'94' " UNBLANK + + X'95' " SAVE + + X'96' " RESTORE + + X'97' " SREAD + + Form 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 N + + Form 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 FIND + + A 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_. + + + + + + + + + + +Braden [Page 10] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + +E. SCREEN SIZE + + For simplicity and consistency with URSA, we have chosen to treat the + cursor as a single integer. This in turn means that VCD and server + must agree upon the number of columns M; it is also desirable for the + server to know N. + + The agreement on M and N takes place through a one-sided negotiation. + The server is assumed to know what M and N values he can handle and + these are published for user sites. When the VCD is first connected + 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 does not like the + values, the server closes the connections and the user is considered + logged off. + +Endnotes + + [1] Graphic representation of start symbol: shaded triangle on its + side. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Braden [Page 11] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + + +---------------+ + | | + | 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 + ------------------------------------ + + + + +Braden [Page 12] + +RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971 + + + 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 + --------------------- + + + + + + [This RFC was put into machine readable form for entry] + [into the online RFC archives by Lorrie Shiota, 2/02] + + + + + + + +Braden [Page 13] + |