Telnet Data Entry Terminal option: DODIIS implementation
updates
- rfc-732 — Telnet Data Entry Terminal option
Extracted elements (27)
Facility negotiation uses logical AND of both parties' capability bitmaps rather than a request-confirm handshake, allowing either party to initiate without confusion. The initiator sends its map and awaits the peer's map; the responder must reply. Either party may reduce negotiated facilities at any time by resending its facility subcommand.
Full-screen TELNET was chosen over character-echo mode because each keystroke in character-echo mode generates a full IP datagram for the character plus a return datagram for the echo, which is costly in both time and network utilization. Forms-based full-screen interaction dramatically reduces datagram count. DODIIS policy discourages remote character echo.
TRANSMIT-MODIFIED is recommended over TRANSMIT-SCREEN or TRANSMIT-UNPROTECTED whenever possible in order to minimize data volume between user and server hosts by returning only fields that were pre-marked Modified or actually edited by the user.
DODIIS terminal implementations must by agreement support exactly 64 virtual function keys (values 0–63). Function key mapping to application functions is application-defined and must be conveyed via user documentation, not protocol.
Robustness principle applied to DET: 'Be conservative in what you send; be liberal in what you accept from others.' Implementations encountering unsupported attribute combinations should attempt to render a reasonable approximation rather than terminating the session.
The RFC provides a recommended support-level table distinguishing User Host (terminal) from Server Host (application) roles: cursor movement, transmit, erase, and format commands are send-only for the server and receive-only for the terminal; cursor position, data transmit, field separator, function key, and selected field are send-only for the terminal. Deviating from these roles limits interoperability.
All reserved bits in facility maps must be zeroed by the sender to indicate non-support of the associated facilities. Reserved bits may be defined in the future and must not be set.
DODIIS implementors must declare non-support of erase facilities by sending the ERASE-FACILITIES subcommand with a zeroed facility map, since no erase facilities are defined for DODIIS implementations but the subcommand is part of the minimal implementation.
DODIIS terminal (User Host) implementations must implement and support all DET subcommands defined in Section 2, plus any hardware-supported or software-emulable attributes. Server Host implementations must support those subcommands required by their applications.
IAC WILL DET requests or agrees to begin sending and receiving DET subcommands. IAC DO DET has identical semantics. Both directions must be negotiated per the TELNET specification.
IAC WONT DET demands reversion to TELNET NVT mode if DET is active, or refuses DET if not yet active. IAC DONT DET has identical semantics. The connection reverts to NVT interpretation as described in MIL-STD-1782.
TELNET ERASE CHARACTER and ERASE LINE control functions are NOT required and should not be sent when operating in DET mode.
When a DET subcommand parameter takes on the value of the IAC character (255), it must be replicated (doubled) so it is not misinterpreted as the beginning of a TELNET command.
When the DET option is negotiated, the conflicting TELNET options Echo, Suppress Go-Ahead, and Binary should be refused or explicitly terminated. Suppress Go-Ahead is the default state of DODIIS connections at establishment.
DODIIS DET screen defaults are 80 characters wide and 24 lines tall. Terminal implementations must support page sizes of 24 to 48 lines. Screen dimensions may be changed via the Output Line Width and Output Page Size TELNET options; defaults apply when negotiation fails.
Four facility subcommands (EDIT-FACILITIES opcode 1, ERASE-FACILITIES opcode 2, TRANSMIT-FACILITIES opcode 3, FORMAT-FACILITIES opcode 4) carry bitmask maps indicating which DET subcommands and attributes each side supports. Negotiated capability is the logical AND of both maps.
Out-of-context data is bracketed by START-OUT-OF-CONTEXT-DATA (opcode 42) and END-OUT-OF-CONTEXT-DATA (opcode 43). The enclosed NVT-mode data (e.g., ARE-YOU-THERE responses or host advisory messages) is displayed without disturbing the virtual screen or the form interaction context.
The ERROR subcommand (opcode 41) carries a one-byte subcommand code identifying the failing command and a one-byte error code. Thirteen error codes are defined, including facility not negotiated, cursor out of bounds, illegal parameter, field overlap detected, and unsupported attribute combination.
The minimal DET implementation consists of subcommands usable without prior negotiation: EDIT-FACILITIES, ERASE-FACILITIES, TRANSMIT-FACILITIES, FORMAT-FACILITIES, MOVE-CURSOR, HOME-CURSOR, ERASE-SCREEN, TRANSMIT-SCREEN, FORMAT-DATA, ERROR, START-OUT-OF-CONTEXT-DATA, and END-OUT-OF-CONTEXT-DATA.
The TELNET Data Entry Terminal (DET) option is assigned option code 20. It enables full-screen, forms-oriented interactions over TELNET in place of character-at-a-time NVT mode.
RFC 1043 contains no dedicated Security Considerations section, reflecting 1988 era practice. The DET Protection attribute (values 0–3: none, protected, alphabetic-only, numeric-only) is a UI data-entry constraint enforced by the terminal, not a cryptographic or access-control mechanism. The protocol operates over plaintext TELNET with no confidentiality, integrity, or authentication guarantees.
GO-AHEAD controls half-duplex line discipline: DET starts with the application holding GO-AHEAD. The application passes GO-AHEAD to the terminal by sending a transmit subcommand followed by the TELNET GO-AHEAD signal. The terminal returns GO-AHEAD (with form data) when the user enters a function key or 'form-complete'. When the application holds GO-AHEAD, only TELNET commands (IP, AO, BREAK, AYT) are valid from the terminal; when the terminal holds GO-AHEAD, the application may send only out-of-context data, MOVE-CURSOR, and FORMAT-DATA for protected fields.
ENABLE-FUNCTION-KEYS (opcode 44) carries a variable-length <key-map> byte string where each byte encodes four 2-bit pairs. Each pair represents one function key: 0=disabled, 1=enabled (return FUNCTION-KEY only), 2=enabled (return screen data plus FUNCTION-KEY), 3=undefined. Keys beyond the map are disabled.
FORMAT-DATA (opcode 36) carries a 2-byte <format map> (Byte 0: Blinking, Reverse Video, Right Justification, 2-bit Protection, 3-bit Intensity; Byte 1: Modified, Selectable, color reserved) followed by a 2-byte big-endian unsigned <count> giving the field size in characters.
FORMAT-FACILITIES (opcode 4) carries two 8-bit bytes encoding: Byte 0 bits for Function Key, Modified, Field Selection, Repeat, Blinking, Reverse Video, Right Justification; Byte 1 bits for Protection, Alphabetic-Only, Numeric-Only, and a 3-bit Intensity level count.
MOVE-CURSOR (opcode 5) carries two 8-bit unsigned integers <x><y> specifying character position (0 to M-1) and line position (0 to N-1) on the DET screen. HOME-CURSOR (opcode 12) is equivalent to MOVE-CURSOR with x=0, y=0 and carries no parameters.
REPEAT (opcode 37) compresses runs of identical characters as a 1-byte <count> followed by the repeated <char>. DATA-TRANSMIT (opcode 28) and CURSOR-POSITION (opcode 18) each carry two 8-bit unsigned integers <x><y> identifying a screen position.