RFC 1043
Telnet Data Entry Terminal option: DODIIS implementation
RFC 1043: TELNET Data Entry Terminal Option, DODIIS Implementation 🎀
Okay bestie, let's get the title block sorted first 💅 This one is from the Network Working Group and was written by A. Yasuda and T. Thompson at the Defense Intelligence Agency. It's dated February 1988, and it updates RFC 732, which is the original DET option we're building on 🦋
Status of This Memo 📝
This RFC puts forward a proposed protocol for the TELNET Data Entry Terminal (DET) Option, DODIIS Implementation, for the Internet community 🌸 It's meant to stay compatible with the DET Option in RFC-732. Discussion and suggestions for improvements are super encouraged 🫶 Distribution of this memo is unlimited ✨
Introduction 🧚
Okay so, in the early 1980s the Defense Intelligence Agency (DIA) decided to build a TELNET capability for accessing full screen applications across a packet switching network 💖 It worked! They did it by adding Data Entry Terminal (DET) options to the TELNET protocol, based on RFC 732. DET options are already running on IAS, MVS, OS86, and UNIX, and they're being developed for VM and VMS too 🔥
The Department of Defense Intelligence Information System (DODIIS) is a confederation of heterogeneous computer systems and remote terminals. It uses the Defense Data Network (DDN) as its communications backbone, specifically the SCINET/DSNET-3 🌈
So why bother with a DET option? It was mainly for database application interfaces, but full screen TELNET also gives you a way to get way more efficiency out of the network 😭 Most terminal to host applications on the ARPANET are character echo TELNETs, and honestly, that's expensive in both time and network use. Every single keypress makes a datagram made of TCP/IP headers plus the character sent to the host, and then the host echoes back a similar datagram. Too much! 💀 In the DODIIS community, programmers are strongly encouraged to build full screen applications. Line at a time is acceptable, and character remote echo mode is discouraged 🙈
This RFC in its final form will be implemented on SCINET. In the meantime, during the interim period, the "DODIIS TELNET Network Virtual Data Entry Terminal (NVDET) Option Specification" (DIA, April 1983) will be implemented 🍓
Table of Contents 📖
TABLE OF CONTENTS
Page No.
--------
SECTION 1 COMMAND NAME AND OPTION CODE 4
SECTION 2 COMMAND MEANINGS 4
Facilities Subcommands 4
Edit Subcommands 8
Transmit Subcommands 8
Erase Subcommands 10
Format Subcommands 10
Miscellaneous Subcommands 13
SECTION 3 DEFAULT AND MINIMAL IMPLEMENTATION 15
SECTION 4 MOTIVATION FOR THE OPTION 17
SECTION 5 DESCRIPTION AND IMPLEMENTATION RULES 17
The DODIIS DET Model 17
Negotiating the DET Option 18
DET Facilities Negotiation 18
General DET Interaction 19
Form Construction 20
Form response 21
Function Keys 22
Field Selection 22
Out-Of-Context Data 23
Line Discipline 23
Standard TELNET Control Functions 24
Other Implementation Notes 24
APPENDIX 1 DET OPCODES AND SUBCOMMAND SYNTAX 25
APPENDIX 2 DET ERROR CODES 26Conventions 🌷
Numbers in the TELNET NVDET Protocol docs are written in decimal, so that's how we roll too 🔢 Data fields are described left to right, with the most significant octet on the left and the least significant octet on the right.
Transmission order is sorted out at the octet level. Whenever a diagram shows a group of octets, they're sent in the normal order you'd read them in English. Check out this one, where the octets go out in the order they're numbered:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transmission Order of BytesWhenever an octet stands for a numeric quantity, the leftmost bit in the diagram is the high order, most significant bit. In other words, the bit labeled 0 is the most significant one. For example, this diagram represents the value 170 (decimal) ✨
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Significance of BitsSame deal for multi-octet fields: the leftmost bit of the whole field is the most significant bit. When a multi-octet quantity gets transmitted, the most significant octet goes first 💜
1. Command Name and Option Code 🎀
The DET option is identified by the code 20 🦋
DET 202. Command Meanings 💅
Let's get into the commands. Each one has its own meaning, and yes, the sender matters 👑
IAC WILL DET
IAC WILL DETThe sender of this command REQUESTS permission to begin, or AGREES that it will begin, sending and receiving Data Entry Terminal (DET) subcommands to control session interactions 🫶
IAC WONT DET
IAC WONT DETOkay, this one is a bit of a mood. If the connection is already operating in DET mode, the sender of this command DEMANDS that the connection stop operating in DET mode and begin operating in TELNET NVT mode. If the connection is not operating in DET mode, the sender REFUSES to begin operating in DET mode 😭 A connection is operating in TELNET NVT mode when both parties are interpreting data as described by the TELNET SPECIFICATION, MIL-STD-1782.
IAC DO DET
IAC DO DETThe sender of this command REQUESTS permission to begin, or AGREES that it will begin, sending and receiving Data Entry Terminal (DET) subcommands to control session interactions. Same energy as WILL, just flipped 🔄
IAC DONT DET
IAC DONT DETSame vibe as WONT. If the connection is already operating in DET mode, the sender of this command DEMANDS that the connection stop operating in DET mode and begin operating in TELNET NVT mode. If the connection is not operating in DET mode, the sender REFUSES to begin operating in DET mode. A connection is operating in TELNET NVT mode when both parties are interpreting data as described by the TELNET SPECIFICATION, MIL-STD-1782 🌈
DODIIS implementations of the DET option use the subcommands described in the rest of Section 2. The DODIIS DET model and how DET subcommands get used is covered in Section 5 🧚
Facilities Subcommands
Facilities subcommands are how the two sides negotiate DET facilities, meaning subcommands and attributes 💖 Each one tells the other side which facilities the sender supports. You can think of it as the terminal saying what it can provide, and the application saying what it wants. The bits of each facility map are numbered from the right, starting at zero. So if bit 2 is set, that field has a decimal value of 4 ✨
EDIT-FACILITIES
IAC SB DET EDIT-FACILITIES <facility map> IAC SESubcommand code: 1 🔥
This one tells the other side which edit facilities the sender supports. The <facility map> parameter is one eight bit byte with these flags:
Bits 5-7 Reserved
Bit 4 Read Cursor
Bits 0-3 ReservedIf the Read-Cursor bit is set, the sender supports the READ-CURSOR and CURSOR-POSITION subcommands 🎀
The reserved bits stand for edit facilities that aren't defined for DODIIS implementations, so there are no descriptions for them. Reserved bits must be zeroed to show that the associated edit facilities aren't supported 🙈
ERASE-FACILITIES
IAC SB DET ERASE-FACILITIES <facility map> IAC SESubcommand code: 2 🧹
This one tells the other side which erase facilities the sender supports. The <facility map> parameter is one eight bit byte containing flags. No erase facilities are defined for DODIIS implementations, so no descriptions are given. The ERASE-FACILITIES subcommand is part of the minimal DET implementation, and that's the only reason it's included 💅
DODISI implementors must declare non support of erase facilities by sending this subcommand with a zeroed facility map 🍓
TRANSMIT-FACILITIES
IAC SB DET TRANSMIT-FACILITIES <facility map> IAC SESubcommand code: 3 🦋
This one tells the other side which transmit facilities the sender supports. The <facility map> parameter is one eight bit byte with these flags:
Bits 6-7 Reserved
Bit 5 Data Transmit
Bits 0-4 ReservedIf the Data-Transmit bit is set, the sender supports the DATA-TRANSMIT subcommand ✨
Just like the edit reserved bits, these reserved bits stand for transmit facilities that aren't defined for DODIIS implementations, so there are no descriptions. Reserved bits must be zeroed to show non support of the associated transmit facilities 🌸
FORMAT-FACILITIES
IAC SB DET FORMAT-FACILITIES <facility map> IAC SESubcommand code: 4 👑
This one tells the other side which format facilities the sender supports. The <facility map> parameter is two eight bit bytes, laid out like this:
Byte 0
Bit 7 Function Key
Bit 6 Modified
Bit 5 Field Selection
Bit 4 Repeat
Bit 3 Blinking
Bit 2 Reverse Video
Bit 1 Right Justification
Bit 0 Reserved
Byte 1
Bit 7 Reserved for color
Bit 6 Reserved
Bit 5 Protection
Bit 4 Alphabetic-Only
Bit 3 Numeric-Only
Bits 0-2 IntensityWhere:
If the Function-Key bit is set, the sender supports the FUNCTION-KEY and ENABLE-FUNCTION-KEY subcommands 💖
If the Modified bit is set, the sender supports the FORMAT-DATA subcommand's Modified attribute and the TRANSMIT-MODIFIED subcommand 🎀
If the Field-Selection bit is set, the sender supports the FORMAT-DATA subcommand's Selectable attribute and the SELECTED-FIELD subcommand 🦋
If the Repeat bit is set the sender supports the REPEAT subcommand 🌸
If the Blinking bit is set, the sender requests or provides the ability to emphasize a string of characters by causing them to blink when displayed ✨ (See the FORMAT-DATA subcommand.)
If the Reverse-Video bit is set, the sender requests or provides the ability to emphasize a string of characters by "reversing their video image". 🌈 If characters are normally displayed as dark characters on a light background, they are reversed and displayed as light characters on a dark background, or vice versa. (See the FORMAT-DATA subcommand.)
If the Right-Justification bit is set, the sender requests or provides the ability to cause data entered in a field to be right justified within the field. (See the FORMAT-DATA subcommand.) 🍓
If the Protection bit is set, the sender requests or provides the ability to protect certain fields displayed on the DET screen from being altered by the user and supports the ERASE-UNPROTECTED, FIELD-SEPARATOR, and TRANSMIT-UNPROTECTED subcommands. (See the FORMAT-DATA subcommand.) 🔒
If the Alphabetic-Only bit is set, the sender requests or provides the ability to constrain the user of the DET such that only alphabetic data may be entered into certain fields. (See the FORMAT-DATA subcommand.) 🔤
If the Numeric-Only bit is set, the sender requests or provides the ability to constrain the user of the DET such that only numeric data may be entered into certain fields. (See the FORMAT-DATA subcommand.) 🔢
The Intensity parameter is three bits wide and is interpreted as a positive binary integer indicating the number of visible levels of intensity that the sender requests or provides for displaying data. (See the FORMAT-DATA subcommand.) ✨
Reserved bits represent format facilities that are not defined for DODIIS implementations; therefore, no descriptions are provided. Reserved bits must be zeroed to indicate non support of the associated format facilities. 🫶
EDIT SUBCOMMANDS. Edit subcommands are sent by the application to position the cursor on the DET screen. 🧚
IAC SB DET MOVE-CURSOR <x><y> IAC SEsubcommand code: 5
This subcommand positions the DET cursor at screen location (x,y). The <x> and <y> parameters are positive eight bit binary integers representing the character and line positions, respectively, of a DET screen location. Values of x range from zero (0) through M-1, where M is the DET screen width in characters. Values of y range from zero (0) through N-1, where N is the DET screen length in lines. 📍
IAC SB DET HOME-CURSOR IAC SEsubcommand code: 12
This subcommand positions the cursor at DET screen address (0,0). It is equivalent to the MOVE-CURSOR subcommand, where x=0 and y=0. 🏠
TRANSMIT SUBCOMMANDS. Transmit subcommands are sent by the application to request data from the DET or by the terminal to identify data returned from the DET. 📤
IAC SB DET READ-CURSOR IAC SEsubcommand code: 17
This subcommand requests return of the DET cursor position. Use of this subcommand requires facility negotiation; see the EDITFACILITIES subcommand, Read-Cursor bit. 👀
IAC SB DET CURSOR-POSITION <x><y> IAC SEsubcommand code: 18
This subcommand returns cursor position in response to a READCURSOR subcommand. The <x> and <y> parameters are eight bit binary integers representing the cursor's position. The <x> and <y> parameters are positive eight bit binary integers representing the character and line positions, respectively, of a DET screen location. Values of x range from zero (0) through M-1, where M is the DET screen width in characters. Values of y range from zero (0) through N-1, where N is the DET screen length in lines. Use of this subcommand requires facility negotiation; see the EDIT-FACILITIES subcommand, Read-Cursor bit. 💌
IAC SB DET TRANSMIT-SCREEN IAC SEsubcommand code: 20
This subcommand requests return of all characters on the DET screen beginning at cursor position (0,0). M x N characters, where M is the DET screen width in characters and where N is the DET screen length in lines, are returned with a SPACE character returned for each character in the unwritten areas (the areas between defined fields). FIELD-SEPARATOR and DATA-TRANSMIT subcommands are not required to delimit or identify fields. 📺
IAC SB DET TRANSMIT-UNPROTECTED IAC SEsubcommand code: 21
This subcommand requests return of all characters in unprotected fields. Use of this subcommand requires facility negotiation; see the FORMAT-FACILITIES subcommand, Protection bit. 🔓
IAC SB DET TRANSMIT-MODIFIED IAC SEsubcommand code: 27
This subcommand requests return of all characters in modified fields. Modified fields are fields that have the Modified attribute set (see FORMAT-DATA subcommand) as well as fields actually modified by the user. Use of this subcommand requires facility negotiation; see the FORMAT-FACILITIES subcommand, Modified bit. ✏️
IAC SB DET DATA-TRANSMIT <x><y> IAC SEsubcommand code: 28
This subcommand identifies a field returned in response to a TRANSMIT-MODIFIED subcommand. The <x> and <y> parameters are positive eight bit binary integers indicating the cursor position of the field that follows the DATA-TRANSMIT subcommand. This subcommand may precede the first field of a transmission with subsequent fields separated by the FIELD-SEPARATOR subcommand or it may precede each field. Use of this subcommand requires facility negotiation; see the TRANSMIT-FACILITIES subcommand, Data-Transmit bit. 💜
ERASE SUBCOMMANDS. Erase subcommands are used by the application to erase the DET screen or selected DET screen areas. In performing erase operations, the erased characters are replaced with SPACE characters. 🧹
IAC SB DET ERASE-SCREEN IAC SEsubcommand code: 29
This subcommand erases all characters from the DET screen. All fields regardless of their attributes are deleted. The cursor position after the operation is at (0,0). If the protection attribute has been negotiated, the erased screen contains protected SPACE characters. 💥
IAC SB DET ERASE-UNPROTECTED IAC SEsubcommand code: 35
This subcommand erases all characters in the unprotected fields of the DET screen. This subcommand replaces field contents with SPACE characters; field attributes and sizes are not changed. The cursor position after the operation is at the beginning of the first unprotected field or, if there is no unprotected field, at (0,0). Use of this subcommand requires facility negotiation; see the FORMAT-FACILITIES subcommand, Protection bit. 🫧
FORMAT SUBCOMMANDS. The format subcommands are used by the application to define the fields of a form and by the terminal to delimit fields sent from the DET. 📋
IAC SB DET FORMAT-DATA <format map><count> IAC SEsubcommand code: 36
This subcommand defines the attributes and size of a DET field. The <format map> parameter defines the field attributes and the <count> parameter defines the field size. The field starts at the position of the cursor when the subcommand is acted upon. The next <count> data characters in the data stream fill the field. 🌟
The <format map> parameter is two eight bit bytes and contains the following:
Byte 0
Bit 7 Blinking
Bit 6 Reverse Video
Bit 5 Right Justification
Bits 3-4 Protection
Bits 0-2 Intensity
Byte 1
Bits 5-7 Reserved
Bits 2-4 Reserved for color
Bit 1 Modified
Bit 0 Selectablewhere:
If the Blinking bit is set, the following field of <count> characters should have the Blinking attribute applied to it by the receiver. ⚡
If the Reverse Video bit is set, the following field of <count> characters should be displayed by the receiver with video reversed. 🔄
If the Right Justification bit is set, characters entered into the field by the user should be right justified. 🍒
The Protection attribute is two bits wide and may take on the following values:
0 No protection. Any valid DET data character may
be entered in the field.
1 Protected. No data may be entered in the field.
2 Alphabetic-only. Only the alphabetic characters
(A-Z and a-z) or the space character may be
entered in the field.
3 Numeric-only. Only the numeric characters (0-9),
the plus sign (+), the minus sign (-), the decimal
point (.) or the space character may be entered in
the field.The Intensity attribute is three bits wide and indicates the brightness to be used when displaying the characters in or entered into the field <count> characters wide. The available number of visible intensity levels should have been negotiated using the FORMAT-FACILITY subcommand. A value of zero (0) indicates that brightness should be OFF; that is, characters in or entered into the field should not be displayed. The values 1-7 indicate relative brightness; the exact algorithm for mapping these values to the available levels of intensity is left to the implementors. 🌙
If the Modified bit is set, the field is considered to have been modified and will be returned, along with any user modified fields. 🎉
okay bestie so if the Selectable bit is set, the field is a candidate for field selection using the DET field selection device 🖱️✨ the <count> parameter is two bytes and should be read as a positive 16-bit binary integer that sets the field size. the high order bit goes first 🎀 data outside the count of a FORMAT-DATA subcommand should show up with the default field attributes: no blinking, no reverse video, no justification, no protection, not modified, not selectable, and a visible intensity 🌸 the minimum field size is one (1) character, and the maximum is set by where the field starts and where the screen ends or the next field begins 💖
using field attributes requires facility negotiation, so check the FORMAT-FACILITIES subcommand 💅
IAC SB DET REPEAT <count><char> IAC SEsubcommand code: 37
this one is giving compression 🗜️ it lets DET data get encoded as a run of identical characters, stored as the character plus a repeat count. the <count> parameter is a positive 8-bit binary integer, and the <char> parameter is a valid DET data character. using this subcommand requires facility negotiation, so look at the FORMAT-FACILITIES subcommand, Repeat bit 🦋
IAC SB DET FIELD-SEPARATOR IAC SEsubcommand code: 39
this subcommand is the field divider 🧚 it separates fields that the DET returns in response to TRANSMIT-MODIFIED or TRANSMIT-UNPROTECTED subcommands. using it requires facility negotiation, so check the FORMAT-FACILITIES subcommand, Protection bit 💜
MISCELLANEOUS SUBCOMMANDS ✨
IAC SB DET FUNCTION-KEY <code> IAC SEsubcommand code: 40
this one transmits a function key code that the user entered 🔑 the <code> parameter is one byte that identifies the virtual function key that got pressed, and the values run from 0 to 255. it's used together with the ENABLE-FUNCTION-KEY subcommand. using it requires facility negotiation, so see the FORMAT-FACILITIES subcommand, Function-Key bit 🌈
IAC SB DET ERROR <cmd><error code> IAC SEsubcommand code: 41
the ERROR subcommand is the tattletale, and I love that for her 🙈 it lets a DET option implementation report errors it detects back to the matching TELNET process. the <cmd> parameter is one byte holding the subcommand code of the subcommand that caused the error. the <error code> parameter is one byte holding a DET error code (check Appendix 2 for the DET error codes) 💀
errors should be reported as soon as they're detected. however, the implementation should try to carry out the intent of the subcommand or data that was in error 🫶
IAC SB DET START-OUT-OF-CONTEXT-DATA IAC SEsubcommand code: 42
this one precedes out-of-context data 🌙 the data after it, up until the END-OUT-OF-CONTEXT-DATA subcommand, is NOT part of the current form. the out-of-context data should be read as NVT mode data (so it may contain carriage return and line feed characters), and it should be displayed in a timely and non-destructive way ✨
IAC SB DET END-OUT-OF-CONTEXT-DATA IAC SEsubcommand code: 43
this subcommand marks the end of the out-of-context data 🏁
IAC SB DET ENABLE-FUNCTION-KEYS <key-map>IAC SEsubcommand code: 44
this one turns virtual function keys on (or off) and tells the DET what the application needs when a function key gets selected 🎛️ the <key-map> parameter is a variable length byte string. each byte holds four bit-pairs, and each bit-pair stands for one function key. the first byte covers function keys zero (0) through three (3), the second byte covers function keys four (4) through seven (7), and so on. here's what the bit-pair values mean:
0 The virtual function key is disabled (i.e., locked).
1 The virtual function key is enabled. Only the FUNCTION-
KEY subcommand is returned on function key selection.
2 The virtual function key is enabled. All requested
screen data and/or cursor position, as well as, the
FUNCTION-KEY subcommand are returned on function key
selection.
3 Undefined.any function keys that aren't explicitly represented in the bitmap are disabled (so they're treated as having a bit-pair value of zero (0)) 🔒
using this subcommand requires facility negotiation, so see the FORMAT-FACILITIES subcommand, Function-Key bit 🔥
IAC SB DET SELECTED-FIELD <x><y> IAC SEsubcommand code: 45
this subcommand identifies a field the user selected 👆 the <x> and <y> parameters are the cursor position of the character that got selected from inside a selectable field (see the FORMAT-DATA subcommand, Selectable attribute). using it requires negotiation, so check the FORMAT-FACILITIES subcommand, Field-Selection bit 💖
3. Default and Minimal Implementation ✨
Default.
WONT DET -- DONT DETif the DET option can't be negotiated, the connection doesn't run in DET mode 🙈
Minimal DET Implementation.
the minimal DET implementation is made up of all the DET subcommands that can be used without any prior negotiation 🌸 those are:
EDIT-FACILITIESERASE-FACILITIESTRANSMIT-FACILITIESFORMAT-FACILITIESMOVE-CURSORHOME-CURSORERASE-SCREENTRANSMIT-SCREENFORMAT-DATAERRORSTART-OUT-OF-CONTEXT-DATAEND-OUT-OF-CONTEXT-DATA
DODIIS DET implementation requirements.
okay so the minimal set isn't broad enough for forms interactions between DODIIS terminals and DODIIS applications 😭 which means DODIIS implementations of the DET option have to support more DET subcommands, full stop 💅
DODIIS terminal (User Host) implementations must implement and support all of the DET subcommands contained in Section 2, plus the DET attributes supported by the terminal hardware and any DET attributes that can be easily emulated in software. DODIIS application (Server Host) implementations must implement and support the DET subcommands and attributes their applications require 🧚
the DODIIS implementation recommendations are in the table below. DODIIS implementors are cautioned that not providing the recommended support may limit interoperability ⚠️
Recommended DET support levels for DODIIS implementations
USER HOST SERVER HOST
DET SUBCOMMANDS SUPPORT LEVEL SUPPORT LEVEL
--------------- ------------- -------------
EDIT-FACILITIES send & receive send & receive
ERASE-FACILITIES send & receive send & receive
TRANSMIT-FACILITIES send & receive send & receive
FORMAT-FACILITIES send & receive send & receive
REPEAT send & receive send & receive
ERROR send & receive send & receive
MOVE-CURSOR receive only send only
HOME-CURSOR receive only send only
READ-CURSOR receive only send only
TRANSMIT-SCREEN receive only send only
TRANSMIT-UNPROTECTED receive only send only
TRANSMIT-MODIFIED receive only send only
ERASE-SCREEN receive only send only
ERASE-UNPROTECTED receive only send only
FORMAT-DATA receive only send only
START-OUT-OF-CONTEXT-DATA receive only send only
END-OUT-OF-CONTEXT-DATA receive only send only
ENABLE-FUNCTION-KEYS receive only send only
CURSOR-POSITION send only receive only
DATA-TRANSMIT send only receive only
FIELD-SEPARATOR send only receive only
FUNCTION-KEY send only receive only
SELECTED-FIELD send only receive only
DET ATTRIBUTES
--------------
Blinking (1) (2)
Reverse video (1) (2)
Right justification (1) (2)
Protection required (2)
Alphabetic-only protection (1) (2)
Numeric-only protection (1) (2)
Intensity level > 1 (1) (2)
OTHER
-----
Page size (lines) 24-48
Line size (characters) 80
Function keys (number) 64
(1) Implement if supported by terminal hardware.
(2) Implement if required by the application.4. Motivation for the option ✨
okay so back in 1981, the TELNET DET option (RFC 732) got picked as the protocol for interactions between DODIIS forms applications and DODIIS forms terminals 🎀 the goal was a high degree of interoperability between DODIIS hosts with forms applications and terminals. and ever since then, several independent organizations in the DODIIS community have been implementing the DET option (and they're still doing it) 🌈
here's the tea: those independently developed implementations of the DET option might not interoperate with each other 😬 so DODIIS implementors got together to pin down DODIIS implementation requirements and to sort out the implementation issues that affect interoperability 🫶
this document is basically the agreements and recommendations those DODIIS implementors came up with 💜
5. Description and Implementation Rules ✨
The DODIIS DET model.
the conceptual model of the DODIIS DET is a half-duplex, forms oriented device with the following 🖥️
- a. A rectangular screen for displaying protected and unprotected data (a form) and optional capability to support blinking, reverse video, and up to seven display intensity levels.
- b. A keyboard and onboard mechanisms for editing unprotected fields of a form and returning the modified fields.
- c. Function keys that may be enabled and disabled on a key-by-key basis by the application.
- d. A field selection device, similar to a light pen, that permits user selection of characters within appropriately identified "selectable" fields.
the DODIIS DET screen has default sizes of 80 characters and 24 lines 💅 these defaults can be changed through negotiation using the Output Line Width and the Output Page Size options. if the parties can't agree on screen size through negotiation, the default values get used. by agreement, DODIIS terminal (User Host) implementations of DET will support page sizes of 24 to 48 lines ✨
The cursor is the blinky little marker that shows where the next character goes on the DET screen 💖 It's written as (x,y), where x is which character you're on across the line and y is which line you're on down the page. x starts at 0 on the far left and goes up to M-1, where M is the line length. y starts at 0 at the top and goes up to N-1, where N is the page length. You can zip the cursor anywhere on the screen without messing up the characters already there ✨
Valid field data for DET forms is the displayable ASCII codes from 32 through 126, plus character 7 "BELL" 🔔
Negotiating the DET option 🤝
DET gets switched on when one party REQUESTS it and the other party AGREES. The request is made by sending DO DET and WILL DET, and the acceptance is sent as WILL DET and DO DET. (Like the rest of TELNET negotiation, DET has to be negotiated for both directions on the connection 💅)
Some TELNET options just don't vibe with DET 🙈 So when DET is negotiated, the following options should be refused (or explicitly terminated): Echo, Suppress Go-Ahead, and Binary. Fun fact: Suppress Go-Ahead is already the default on DODIIS TELNET connections when they first get set up, so it's the one you'll see most.
DET facilities negotiation ✨
Every DET implementation is required to support the minimal DET implementation from Section 3. On top of that, DODIIS implementations are required to support subcommands and attributes that match DODIIS requirements. But before any of these extra DET facilities can be used, an implementation has to negotiate permission with its correspondent first. Be patient, bestie 🫶
There are four facility subcommands (EDIT-FACILITIES, ERASE-FACILITIES, TRANSMIT-FACILITIES, and FORMAT-FACILITIES) that handle this negotiation. It's basically a swap of facility subcommands, where the terminal (User Host) says what it's able to do, and the application program (Server Host) says what it wants. The stuff that both sides support, and that is therefore allowed, is the logical intersection of the map that was sent and the map that was received. (For the intensity attribute, it's the lesser of the number of intensity levels sent and the number received.) Each implementation has to keep track of the agreed set of subcommands and attributes, and only the ones in that set can be used without another round of facility subcommands 🦋
Either party or both can start facilities negotiation with zero confusion, as long as nobody gets stuck in a negotiation loop that never ends 🔁 If you start the negotiation by sending a facility subcommand, you have to remember that you started it. When a facility subcommand comes in, if you were the one who started it, no response is required and the negotiation is done. If you didn't start it, you must respond by sending the right facility subcommand back to the requester. (Also, there's no rule saying you have to negotiate one class at a time. You just have to keep track of who started things for each facility subcommand.)
When a TELNET implementation responds to a facility subcommand, it doesn't have to compute the logical intersection first. It should reply as fast as it can with a facility map listing every facility in that class that it supports 🏃♀️ There's no mix-up, because both parties work out the supported set the same way. Also, while both parties have to agree before the optional subcommands and attributes get used, either party can switch use off at any time by just sending the appropriate facility subcommand. And there are no restrictions on when facilities can be sent.
CAUTION: Every facilities map has reserved bits in it. Those reserved bits must be zeroed when the map is sent, so it's clear the facility isn't supported and/or the sender doesn't know about it. The reserved bits may be defined in the future 👀
General DET Interaction 🌸
In a general interaction, the application builds a form, negotiates the options it wants, says which responses it needs, and then sends the TELNET GO-AHEAD. That GO-AHEAD means the form is finished being built and the DET keyboard can be unlocked so the user can respond 🔓
Usually the user responds by editing the unprotected areas of the form and signaling "form-complete", pressing a function key, selecting a field, or doing some combination of those. In every case, the terminal sends the DET subcommands that describe the user's response and then returns the GO-AHEAD. That second GO-AHEAD marks the end of the user's response 💜
The form, with whatever the user edited, stays on the virtual screen. So the application can keep the conversation going by changing the form 🧚
Form construction 🎀
The application builds a form on a screen it has erased, by defining each of the fields in it. Each DET field is defined by its starting cursor position, its size, its attributes, and its contents (data).
A field's starting cursor position is the cursor position of its first character. The cursor can be placed explicitly with the MOVE-CURSOR subcommand, or it can get placed implicitly by field data or by other DET subcommands (for example, ERASESCREEN and ERASE-UNPROTECTED) 📍
Field size, attributes, and contents can be defined using the FORMAT-DATA subcommand followed by the field data. Or, if you're happy with default attributes, you can define a field with only the field data. In that case, the field size is the length of the data string. The data string ends at the GO-AHEAD or at any DET subcommand, except the REPEAT subcommand 🙌
There are no restrictions on which attribute combinations can be applied to a field, even though some combinations might not be supported by the terminal hardware 🤷♀️ The terminal should display the field with a "reasonable" combination of attributes. There's an error code that might come back when an "unsupported combination of format attributes" gets detected. It's not clear what the application should do about that error. Either way, this condition should not provoke session termination 🙅♀️
Field contents (data) are restricted to printable ASCII characters and "BELL" (codes 32 through 126 and 7 decimal). It's the application's job to translate carriage returns, line feeds, tabs, and so on into the right DET subcommands 🍓
The maximum number of fields a screen can hold is the screen size in characters, which is characters per line times lines per screen. Iconic, right? 🤓
Fields may not overlap. A new field may not start or end inside a field that's already been defined. However, you can overwrite a field to change its attributes or its contents 🔄
There are no restrictions on the order a form gets built in (for example, left-to-right and top-to-bottom). The terminal implementation must be ready to handle any order. Terminal implementations are encouraged to display data as it arrives, so applications that keep showing status updates on whatever task they're running can do that 📊
If an application decides to change a form the user already edited, it must position the cursor without assuming where the user might have left it. It must also exactly overwrite the existing fields 🎯
When form construction is complete, the application says what responses it needs by sending the right transmit subcommand. It can send TRANSMIT-SCREEN, TRANSMIT-UNPROTECTED, or TRANSMIT-MODIFIED to request data, and/or it can send READ-CURSOR to ask for the cursor position. TRANSMIT-MODIFIED should be used whenever possible, to keep the amount of data moving between the user and server hosts as small as possible 📉
Form response 💌
A form response is generated by the terminal implementation when the user signals "form-complete" or presses an enabled function key. The data that comes back is decided by the application through the transmit subcommands. If no transmit subcommand was sent, the Modified and Protection attributes are used to figure out an implied one. If the Modified attribute has been negotiated, assume TRANSMIT-MODIFIED. If the Protection attribute has been negotiated but Modified hasn't, assume TRANSMIT-UNPROTECTED. If neither one has been negotiated, assume TRANSMIT-SCREEN. (The whole point is transmission efficiency, returning the smallest amount of data the in-force DET attributes allow 🚀)
CAUTION: With TRANSMIT-MODIFIED, the terminal implementation must return all fields marked with the Modified attribute, in addition to any fields the terminal user actually modified 💅
Returned fields are identified and delimited using the DATA-TRANSMIT and/or FIELD-SEPARATOR subcommands. The DATA-TRANSMIT subcommand gives the cursor address of the field that follows it, and there are no restrictions on the order fields come back in. The FIELD-SEPARATOR subcommand carries the left-to-right and top-to-bottom field ordering. Data that isn't preceded by either of these subcommands is assumed to be the first unprotected field in the form. A FIELD-SEPARATOR followed directly by another FIELD-SEPARATOR means that field was unchanged and wasn't returned 🧩
Unless the Numeric-only or Alphabetic-only attributes say otherwise, data typed into unprotected fields is restricted to printable ASCII characters and "BELL" (codes 32 through 126 and 7 decimal). No other characters are allowed 🚫
Function keys ⌨️
By general agreement, DODIIS terminal implementations will support 64 function keys (key values 0 through 63). Mapping function keys to application functions is the application's responsibility, and that info should be handed to the terminal user in the form of user documentation 📖
The application enables and disables the function keys, and says what its form response requirements are, by sending the ENABLE-FUNCTION-KEY subcommand. The terminal implementation checks function key selections against the information in the ENABLE-FUNCTION-KEY bitmap. When an enabled function key gets pressed, the terminal returns a form response (if the bitmap says to), a FUNCTION-KEY subcommand, and the GO-AHEAD 🎉
Okay so, virtual function keys live inside the DET's virtual keyboard 💻, and they're "locked" whenever the application has the GO-AHEAD 🔒. Here's the tea: the terminal sends the GO-AHEAD when a function key gets entered, so pressing one "re-locks" all the function keys until the GO-AHEAD is returned. The keys are very protective of their space 💅
Field selection
Any character inside a field with the Selectable attribute is a candidate for selection ✨. When a selection happens, the terminal sends back a SELECTED-FIELD subcommand that says which character position got picked 🎯. You can make multiple selections, but the order doesn't have to be preserved, so don't count on it being in order 🙈
Field selection does not cause the GO-AHEAD to be sent, though. The GO-AHEAD must be sent as a result of another user action, like a function key entry or a "form-complete" indication 🔑. And field selection is disabled whenever the application has the GO-AHEAD 🚫
Out-of-context data
Out-of-context data is data that is clearly not part of the form interaction 🧚. It's a handy mechanism for sending ARE-YOU-THERE responses or host advisory messages to the user without messing up the DET's virtual screen or changing the context of the form interaction 🫶
The application may send out-of-context data at any time 💌. The data must be preceded by START-OUT-OF-CONTEXT-DATA and followed immediately by END-OUT-OF-CONTEXT-DATA. It should contain carriage returns and line feeds to help with formatting 📝. The sender should limit how much data gets sent, since most terminal implementations have to buffer it before displaying it 💾. The terminal implementation should display the data to the user in a timely fashion ⏰. The data is for display only: no user response is required, and there is no mechanism for user response 🙅♀️
Line Discipline
The subject of DET and line discipline (controlling the connection using the GO-AHEAD) causes a bit of confusion 😵💫, so here are the rules that apply to GO-AHEAD and the DET option:
- When DET is negotiated, the application assumes the GO-AHEAD. GO-AHEAD is never passed implicitly; it is always passed explicitly 🤝
- When the application has the GO-AHEAD, the terminal implementation may send TELNET commands (
INTERRUPT-PROCESS,ABORT-OUTPUT,BREAK, andARE-YOU-THERE). Nothing else is valid 🚧 - When the terminal has the GO-AHEAD, the application may send out-of-context data or
MOVE-CURSORandFORMAT-DATAsubcommands to update protected fields. Nothing else is valid. (The terminal implementation must display the out-of-context data and the field updates as soon as convenient 🌸) - The terminal implementation sends the GO-AHEAD, without further action on the part of the terminal user, when an enabled function key or a "form-complete" is entered 🎀
Since the terminal user must take explicit action to return the GO-AHEAD to the application, there will be instances where the user has the GO-AHEAD but the application needs it to display a new form 🥺. This is most likely to happen when the user enters an INTERRUPT PROCESS. When it does happen, the application should send an out-of-context-context message asking the user to enter a "form-complete". If the user cooperates, the application can ignore any associated form response and regain control of the connection to display its form 👑
The line discipline described here is more rigorous than the one described for NVT in MIL-STD-1782 🧐. These rules apply only when operating in DET mode. At other times, the descriptions in MIL-STD-1782 apply. This distinction is necessary to ensure interoperability with non-DET implementations of TELNET 🦋
Standard TELNET control functions
The TELNET control functions, ERASE CHARACTER and ERASE LINE, are NOT required and should not be sent in DET mode 🙅♀️✨
Other implementation notes
- a. The DODIIS DET conceptual model does not support character editors or basic scrolling applications 📜
- b. Implementors are cautioned that DET subcommand parameters (e.g., facilities maps) may take on the value of the IAC character and must be replicated if they are to be properly interpreted 🔁
- c. Principle of Robustness: "Be conservative in what you send; be liberal in what you accept from others." 🫶
APPENDIX 1 - DET OPCODES AND SUBCOMMAND SYNTAX ✨
OPCODE SUBCOMMAND SYNTAX
------ -----------------
1 EDIT-FACILITIES <facility map>
2 ERASE-FACILITIES <facility map>
3 TRANSMIT-FACILITIES <facility map>
4 FORMAT-FACILITIES <facility map 1><facility map 2>
5 MOVE-CURSOR <x><y>
12 HOME-CURSOR
17 READ-CURSOR
18 CURSOR-POSITION <x><y>
20 TRANSMIT-SCREEN
21 TRANSMIT-UNPROTECTED
27 TRANSMIT-MODIFIED
28 DATA-TRANSMIT <x><y>
29 ERASE-SCREEN
35 ERASE-UNPROTECTED
36 FORMAT-DATA <format map><count>
37 REPEAT <count><character>
39 FIELD-SEPARATOR
40 FUNCTION-KEY <code>
41 ERROR <cmd><error code>
42 START-OUT-OF-CONTEXT-DATA
43 END-OUT-OF-CONTEXT-DATA
44 ENABLE-FUNCTION-KEYS <key-map>
45 SELECTED-FIELD <x><y>APPENDIX 2 - DET ERROR CODES 🌈
1 Facility not previously negotiated.
2 Illegal subcommand code.
3 Cursor Address Out of Bounds.
4 Undefined FUNCTION-KEY value.
5 Can't negotiate acceptable line width.
6 Can't negotiate acceptable page length.
7 Illegal parameter in subcommand.
8 Syntax error in parsing subcommand.
9 Too many parameters in subcommand.
10 Too few parameters in subcommand.
11 Undefined parameter value.
12 Unsupported combination of Format Attributes.
13 Invalid field - overlap detected.📦 where this page comes from
- ietf: rfc1043 1988-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms