Summary

  • RFC 1043 documented a 1988 DODIIS implementation of TELNET's Data Entry Terminal option. Its authors described the cost of character echo: one keystroke could travel in a TCP/IP datagram and return in an echoed datagram.
  • DET moved form editing to a full-screen terminal. Terminal and application negotiated the features they shared, took turns with GO-AHEAD, and could return only modified fields rather than a whole screen. The record's Modified flag could also mark a field that the user had never touched.

A packet for the letter, another for the echo

The introduction to RFC 1043 describes a distinctly expensive typing habit. In the character-echo TELNET applications familiar to its authors, a keypress sent a datagram containing TCP/IP headers and the single character to the host; the host sent back a comparable echo. The specification came from the Defense Intelligence Agency's work on full-screen access across a packet-switched network. It reported Data Entry Terminal implementations on IAS, MVS, OS86 and UNIX, with work on VM and VMS under way. The systems differed. The users still needed a screen that behaved like one form rather than a long-distance typewriter.

The Data Entry Terminal option itself had appeared in RFC 732. RFC 1043 sought a compatible implementation for the DODIIS community after independently built versions raised interoperability questions. That institutional motive matters. A form that works on one terminal and scrambles on another is a very efficient way to turn a supposed network saving into a help-desk occupation. The authors wrote down what the terminal and application had to negotiate, which commands belonged to the common minimum, and how the two sides would take turns.

The conceptual device was half-duplex and forms oriented. It had a rectangular screen with protected text and unprotected areas a user could edit. Its keyboard could modify those open fields locally. Function keys and selectable fields added other ways to respond. The default canvas was 80 characters by 24 lines; user hosts were expected to support 24 to 48 lines, with size changes negotiated. The application assembled fields with positions, lengths, attributes and contents. Once the form was ready, it sent TELNET GO-AHEAD, releasing the keyboard for the user. When the user completed the form or pressed an enabled function key, the terminal sent its response and returned GO-AHEAD. The cursor, like a baton, crossed the room only when the current speaker was finished.

Before any of that, both ends had to agree to use DET. TELNET option code 20 was negotiated in both directions with DO and WILL. If the agreement failed, the default was WONT DET -- DONT DET and the connection used the ordinary network virtual terminal mode. Echo, Suppress Go-Ahead and Binary were among the TELNET options the RFC said should be refused or ended when DET was negotiated. The new screen had a different discipline for turns; keeping conflicting habits active would make the bargain ambiguous.

The bargain continued inside DET. Four facilities subcommands advertised editing, erasing, transmission and formatting capabilities. The terminal said what it supplied; the application said what it wanted. The usable facilities were the logical intersection of their maps. For display intensity, the lower of the two offered levels won. Optional facilities could be used only after agreement, and either side could later disable one. Reserved bits had to be sent as zero so a future facility would not appear by accident.

The RFC even told each side to remember whether it had started a negotiation; otherwise two polite machines could spend all day replying to each other's replies.

The form's return trip was where the network saving became concrete. The application could ask for the whole screen, just unprotected fields, or modified fields through TRANSMIT-SCREEN, TRANSMIT-UNPROTECTED and TRANSMIT-MODIFIED. If it sent no explicit request, negotiated Modified and Protection attributes determined a default that sought the smallest permitted response. The terminal could keep the screen visible while the application altered only the parts needed for another round. A user's work stayed local until the form was ready to travel.

There is a small trap in the word “modified.” RFC 1043 required TRANSMIT-MODIFIED to include fields carrying the Modified attribute as well as fields actually changed by the user. The return packet therefore described the protocol's chosen set, not a diary of finger movements. A server receiving a marked field had to understand the form contract before claiming to know what the person typed. The distinction is tucked into a caution box, exactly where a future debugger would wish someone had put a bright lamp.

The RFC also drew an honest line around compatibility. Its minimum DET set covered commands usable without extra negotiation, but DODIIS forms needed additional subcommands. User hosts were to support the specified commands and attributes their hardware offered or software could emulate; server hosts supported what their applications required. The document's table recommended direction and level of support for each side. The aim was interoperability among different machines, not a magical universal terminal with every feature switched on.

RFC 1043 turned a noisy network habit into a shared form. A keystroke could become a local edit. A screen could be built from agreed commands. A response could carry just the appropriate fields. The quiet came from two endpoints understanding the same small rules before either tried to save a packet.