diff options
Diffstat (limited to 'doc/rfc/rfc1043.txt')
| -rw-r--r-- | doc/rfc/rfc1043.txt | 1453 |
1 files changed, 1453 insertions, 0 deletions
diff --git a/doc/rfc/rfc1043.txt b/doc/rfc/rfc1043.txt new file mode 100644 index 0000000..df32e33 --- /dev/null +++ b/doc/rfc/rfc1043.txt @@ -0,0 +1,1453 @@ +Network Working Group A. Yasuda +Request for Comments: 1043 T. Thompson + Defense Intelligence Agency +Updates: RFC 732 February 1988 + + + TELNET Data Entry Terminal Option + DODIIS Implementation + +Status of this Memo + + This RFC suggests a proposed protocol on the TELNET Data Entry + Terminal (DET) Option - DODIIS Implementation for the Internet + community. It is intended that this specification be compatible with + the specification of DET Option in RFC-732. Discussion and + suggestions for improvements are encouraged. Distribution of this + memo is unlimited. + +Introduction + + In the early 1980s, the Defense Intelligence Agency (DIA) undertook + the tasks of developing a TELNET capability to access full screen + applications across a packet switching network. This effort was + successful by implementing Data Entry Terminal (DET) options within + the TELNET protocol based on RFC 732. These DET options have been + implemented on IAS, MVS, OS86 and UNIX operating systems. DET + options are being developed for VM and VMS operating systems. + + The Department of Defense Intelligence Information System (DODIIS) is + a confederation of heterogeneous computer systems and remote + terminals utilizing the Defense Data Network (DDN) as the + communications backbone (namely the SCINET/DSNET-3). + + Although the reason for implementing a DET option specification was + based upon data base application interfaces, the use of a full screen + TELNET provides a method to achieve higher efficiency on the network. + Most terminal to host applications on the ARPANET are character echo + TELNETs. This is both costly in time and network utilization, since + one character pressed on the keyboard generates a datagram composed + of TCP/IP headers plus the character sent to the host and the host + echoes back a similar datagram. In the DODIIS community, programmers + are highly encouraged to implement 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. During the + interim period, the "DODIIS TELNET Network Virtual Data Entry + Terminal (NVDET) Option Specification", DIA, April 1983, will be + implemented. + + + +Yasuda & Thompson [Page 1] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + 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 26 + + + + + + + + + + + + + + + + +Yasuda & Thompson [Page 2] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + The convention in the documentation of the TELNET NVDET Protocol is + to express numbers in decimal. Data fields are described left to + right, with the most significant octet on the left and the least + significant octet on the right. + + The order of transmission of the data described in this document is + resolved to the octet level. Whenever a diagram shows a group of + octets, the order of transmission of those octets is the normal order + in which they are read in English. For example, in the following + diagram the octets are transmitted in the order they are 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 Bytes + + Whenever an octet represents a numeric quantity, the left most bit in + the diagram is the high order or most significant bit. That is, the + bit labeled 0 is the most significant bit. For example, the + following diagram represents the value 170 (decimal). + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |1 0 1 0 1 0 1 0| + +-+-+-+-+-+-+-+-+ + + Significance of Bits + + Similarly, whenever a multi-octet field represents a numeric + quantity, the left most bit of the whole field is the most + significant bit. When a multi-octet quantity is transmitted the most + significant octet is transmitted first. + + + + + + + + + + + + +Yasuda & Thompson [Page 3] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + 1. Command Name and Option Code + + DET 20 + + 2. Command Meanings + + IAC WILL DET + + The 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 + + 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 + + The 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 DONT DET + + 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 remainder of Section 2. A description of the + DODIIS DET model and DET subcommand usage is contained in Section + 5. + + FACILITIES SUBCOMMANDS. Facilities subcommands are used to negotiate + DET facilities (subcommands and attributes). The facility + subcommands indicate the DET facilities the sender supports. + Facility negotiation may be viewed as the terminal indicating the + facilities it provides and the application indicating the facilities + + + +Yasuda & Thompson [Page 4] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + it desires. The bits of the facility maps are numbered from the + right starting at zero. Thus, if bit 2 is set, the field will have a + decimal value of 4. + + IAC SB DET EDIT-FACILITIES <facility map> IAC SE + + subcommand code: 1 + + This subcommand indicates the edit facilities the sender + supports. The <facility map> parameter is one eight bit byte + containing the following flags: + + Bits 5-7 Reserved + Bit 4 Read Cursor + Bits 0-3 Reserved + + where: + + If the Read-Cursor bit is set, the sender supports the + READ-CURSOR and CURSOR-POSITION subcommands. + + Reserved bits represent edit 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 edit facilities. + + IAC SB DET ERASE-FACILITIES <facility map> IAC SE + + subcommand code: 2 + + This subcommand indicates the erase facilities the sender + supports. The <facility map> parameter is one eight bit + byte containing flags. Since no erase facilities are + defined for DODIIS implementations, no descriptions are + provided. The ERASE-FACILITIES subcommand is part of the + minimal DET implementation and is included for that reason. + DODISI implementors must declare non support of erase + facilities by sending this subcommand with a zeroed facility + map. + + IAC SB DET TRANSMIT-FACILITIES <facility map> IAC SE + + subcommand code: 3 + + This subcommand indicates the transmit facilities the sender + supports. The <facility map> parameter is one eight bit byte + containing the following flags: + + + + +Yasuda & Thompson [Page 5] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + Bits 6-7 Reserved + Bit 5 Data Transmit + Bits 0-4 Reserved + + where: + + If the Data-Transmit bit is set, the sender supports the + DATA-TRANSMIT subcommand. + + Reserved bits represent transmit 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 transmit + facilities. + + IAC SB DET FORMAT-FACILITIES <facility map> IAC SE + + subcommand code: 4 + + This subcommand indicates the format facilities the sender + supports. The <facility map> parameter is two eight bit bytes + containing the following: + + 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 Intensity + + where: + + 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 + + + +Yasuda & Thompson [Page 6] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + 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 + + + +Yasuda & Thompson [Page 7] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + 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 SE + + subcommand 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 SE + + subcommand 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 SE + + subcommand 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 SE + + subcommand code: 18 + + This subcommand returns cursor position in response to a + + + +Yasuda & Thompson [Page 8] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + 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 SE + + subcommand 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 SE + + subcommand 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 SE + + subcommand 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 SE + + subcommand code: 28 + + + + +Yasuda & Thompson [Page 9] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + 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 SE + + subcommand 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 SE + + subcommand 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 SE + + subcommand code: 36 + + This subcommand defines the attributes and size of a DET field. + The <format map> parameter defines the field attributes and the + + + +Yasuda & Thompson [Page 10] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + <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 Selectable + + where: + + 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), + + + +Yasuda & Thompson [Page 11] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + 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. + + 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 interpreted as a + positive 16-bit binary integer that defines the field size. The + high order bit is transmitted first. Data, not in the scope of + the count of a FORMAT-DATA subcommand, should be displayed with + the default field attributes (no blinking, no reverse video, no + justification, no protection, not modified, not selectable, and a + visible intensity). Minimum field size is one (1) character. + Maximum field size is determined by a field's starting location + and the end of the screen or the start of the next field. + + Use of field attributes requires facility negotiation; see the + FORMAT-FACILITIES subcommand. + + IAC SB DET REPEAT <count><char> IAC SE + + subcommand code: 37 + + This subcommand permits compression of DET data by encoding + strings of identical characters as the character and a repeat + count. The <count> parameter is a positive 8-bit binary + integer. The <char> parameter is a valid DET data character. + Use of this subcommand requires facility negotiation; see + the FORMAT-FACILITIES subcommand, Repeat bit. + + + + +Yasuda & Thompson [Page 12] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + IAC SB DET FIELD-SEPARATOR IAC SE + + subcommand code: 39 + + This subcommand separates fields returned by the DET in + response to TRANSMIT-MODIFIED or TRANSMIT-UNPROTECTED + subcommands. Use of this subcommand requires facility + negotiation; see the FORMAT-FACILITIES subcommand, + Protection bit. + +MISCELLANEOUS SUBCOMMANDS + + IAC SB DET FUNCTION-KEY <code> IAC SE + + subcommand code: 40 + + This subcommand transmits a user entered function key code. + The <code> parameter is one byte that identifies the virtual + function key entered. Function key <code> values range from + 0 to 255. This subcommand is used in conjunction with the + ENABLE-FUNCTION-KEY subcommand. Use of this subcommand + requires facility negotiation; see the FORMAT-FACILITIES + subcommand, Function-Key bit. + + IAC SB DET ERROR <cmd><error code> IAC SE + + subcommand code: 41 + + This subcommand allows a DET option implementation to report + errors it detects to the corresponding TELNET process. The + <cmd> parameter is one byte containing the subcommand code + of the subcommand causing the error. The <error code> + parameter is one byte containing a DET error code. (See + Appendix 2 for DET error codes.) + + Errors should be reported when detected. However, the + implementation should attempt to carry out the intent of + the subcommand or data in error. + + IAC SB DET START-OUT-OF-CONTEXT-DATA IAC SE + + subcommand code: 42 + + This subcommand precedes out-of-context data. The data + following this subcommand and prior to the + END-OUT-OF-CONTEXT-DATA subcommand is NOT part of the current + form. The out-out-of-context data should be interpreted as + NVT mode data (i.e., it may contain carriage return and line + + + +Yasuda & Thompson [Page 13] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + feed characters) and should be displayed in a timely and + non-destructive fashion. + + IAC SB DET END-OUT-OF-CONTEXT-DATA IAC SE + + subcommand code: 43 + + This subcommand indicates the end of the out-of-context data. + + IAC SB DET ENABLE-FUNCTION-KEYS <key-map>IAC SE + + subcommand code: 44 + + This subcommand enables (or disables) virtual function keys and + indicates the application's data requirements on function key + selection. The <key-map> parameter is a variable length byte + string. Each byte contains four bit-pairs and each bit-pair + represents a single function key. The first byte represents + function keys zero (0) through three (3); the second byte, + function keys four (4) through seven (7); and so on. Bit-pair + values and there meanings are as follows: + + 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. + + Function keys not explicitly represented in the bitmap are + disabled (i.e., they are assumed to have a bit-pair value of + zero (0)). + + Use of this subcommand requires facility negotiation; see the + FORMAT-FACILITIES subcommand; Function-Key bit. + + IAC SB DET SELECTED-FIELD <x><y> IAC SE + + subcommand code: 45 + + This subcommand identifies a user selected field. The <x> and + <y> parameters are the cursor position of the character + selected from within a selectable field (see the FORMAT-DATA + + + +Yasuda & Thompson [Page 14] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + subcommand, Selectable attribute.) Use of this subcommand + requires negotiation; see the FORMAT-FACILITIES subcommand, + Field-Selection bit. + +3. Default and Minimal Implementation + + + Default. + + WONT DET -- DONT DET + + If the DET option cannot be negotiated, the connection is + not operated in DET mode. + + Minimal DET Implementation. + + The minimal DET implementation consists of all DET subcommands + that may be used without prior negotiation. These subcommands + are as follows: + + EDIT-FACILITIES + ERASE-FACILITIES + TRANSMIT-FACILITIES + FORMAT-FACILITIES + MOVE-CURSOR + HOME-CURSOR + ERASE-SCREEN + TRANSMIT-SCREEN + FORMAT-DATA + ERROR + START-OUT-OF-CONTEXT-DATA + END-OUT-OF-CONTEXT-DATA + + DODIIS DET implementation requirements. + + The minimal DET implementation set of subcommands is not broad + enough to support forms interactions between DODIIS terminals + and DODIIS applications. Therefore, DODIIS implementations of + the DET option must support additional DET subcommands. + + DODIIS terminal (User Host) implementations must implement and + support all of the DET subcommands contained in Section 2, as + well as those DET attributes supported by the terminal hardware + and any DET attributes easily emulated in software. DODIIS + application (Server Host) implementations must implement and + support those DET subcommands and attributes required by its + applications. + + + + +Yasuda & Thompson [Page 15] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + DODIIS implementation recommendations are contained in the + table that follows. DODIIS implementors are cautioned that + failure to provide 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 + + + +Yasuda & Thompson [Page 16] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + Function keys (number) 64 + + + (1) Implement if supported by terminal hardware. + (2) Implement if required by the application. + +4. Motivation for the option + + In 1981, the TELNET DET option (RFC 732) was selected as the protocol + to support interactions between DODIIS forms applications and DODIIS + forms terminals. The intent was to foster a high degree of + interoperability between DODIIS hosts with forms applications and + terminals. Since that time, the DET option has been and is being + implemented by several independent organizations within the DODIIS + community. + + Motivated by concern that the independently developed implementations + of the DET option may not interoperate with one another, DODIIS + implementors met to identify DODIIS implementation requirements and + to resolve implementation issues that affect interoperability. + + This document attempts to present the agreements and recommendations + of the DODIIS implementors. + +5. Description and Implementation Rules + + The DODIIS DET model. + + The conceptual model of the DODIIS DET is that of 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 may be changed through negotiation using the + Output Line Width and the Output Page Size options. When the parties + + + +Yasuda & Thompson [Page 17] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + cannot agree on screen size through negotiation, the default values + will be used. By agreement, DODIIS terminal (User Host) + implementations of DET will support page sizes of 24 to 48 lines. + + The next writing position (x,y) on the DET screen is indicated by a + special display character called the cursor, where x is the position + of a character on a line and y is the line position on the DET + screen. Values of x range from 0 (the left most character position + on the line) to M-1, where M is the line length. Values of y range + from 0 (the top most line on the screen) to N-1, where N is the page + length. The cursor may be moved to any position on the DET screen + without disturbing the characters already displayed. + + Valid field data for DET forms are the displayable ASCII character + codes in the range 32 through 126 decimal and character 7 "BELL". + + Negotiating the DET option + + The DET option is negotiated when either party REQUESTS use of the + DET option and the other party AGREES to its use. The DET option + is requested by sending a DO DET and WILL DET and is accepted by + sending a WILL DET and DO DET. (In the spirit of TELNET + negotiation, the DET option must be negotiated for both directions + on the connection.) + + Several TELNET options conflict with the DET option. Therefore, + when the DET option is negotiated, the following TELNET options + should be refused (or explicitly terminated): Echo, Suppress Go- + Ahead, and Binary. (The Suppress Go-Ahead is the default state of + DODIIS TELNET connections when they are first established.) + + DET facilities negotiation + + All implementations of the DET option are required to support the + minimal DET implementation described in Section 3. In addition, + DODIIS implementations are required to support subcommands and + attributes that are consistent with DODIIS implementation + requirements. Before any of these additional DET facilities may + be used, an implementation must negotiate with its correspondent + for permission to use them. + + The four facility subcommands (EDIT-FACILITIES, ERASE-FACILITIES, + TRANSMIT-FACILITIES, and FORMAT-FACILITIES) are used to negotiate + DET subcommands and attributes. This negotiation consists of an + exchange of facility subcommands and may be viewed as the terminal + (User Host) indicating the facilities it provides and the + application program (Server Host) indicating the facilities it + desires. The facilities that are jointly supported (and may be + + + +Yasuda & Thompson [Page 18] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + used) are arrived at by forming the logical intersection of the + facility map that was sent with the facility map that was + received. (For the intensity attribute, the lesser of the number + of intensity levels sent and the number of intensity levels + received will be used.) An implementation must record the + currently agreed upon set of subcommands and attributes. Only + subcommands and attributes reflected in that set may be used + without further exchange of facility subcommands. + + Either party or both parties may initiate facilities negotiation + without confusion as long as care is taken to avoid non- + terminating negotiation loops. In particular, if you initiate + negotiation by sending a facility subcommand, you must remember + that you did initiate the negotiation. On receipt of a facility + subcommand; if you initiated the negotiation, no response is + required and the negotiation is complete; if you did not initiate + the negotiation, you must respond by sending the appropriate + facility subcommand to the requester. (Note that there is no + requirement to negotiate facilities one class at a time and that + the awareness of who initiated the negotiation must be maintained + for each of the facility subcommands.) + + A TELNET implementation responding to a facility subcommand is not + required to compute the logical intersection of the maps before + responding. It should respond as quickly as possible with a + facility map indicating all facilities of that class that it + supports. There is no confusion since both parties compute the + set of supported subcommands and attributes in the same fashion. + Note that while both parties must agree to the use of the optional + subcommands and attributes, either party may disable use at any + time by merely sending the appropriate facility subcommand. + Further, there are no restrictions on when facilities may be sent. + + CAUTION: + + All facilities maps contain reserved bits. + These reserved bits must be zeroed when + facility maps are sent to indicate non + support and/or ignorance of the associated + facility. The reserved bits may be defined + in the future. + + General DET Interaction + + In the general interaction, the application implementation + constructs a form, negotiates the desired options, indicates the + required responses, and sends the TELNET GO-AHEAD. The GO-AHEAD + signals that the form construction is complete and that the DET + + + +Yasuda & Thompson [Page 19] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + keyboard may be unlocked to permit a user response. + + The user normally responds by editing the unprotected areas of the + form and signaling "form-complete", entering a function key, + electing a field, or performing a combination of the preceding. + In each case, the terminal implementation sends the DET + subcommands indicating the user's response and returns the GO- + AHEAD. The GO-AHEAD signals the end of the user response. + + The form, as edited by the user, remains on the virtual screen so + the application may continue the interaction by altering the form. + + Form construction + + The application implementation constructs a form on an erased + screen by defining each of the fields in the form. The DET fields + are defined by their starting cursor position, size, attributes, + and contents (data). + + A field's starting cursor position is the cursor position of the + first character in the field. The cursor may be positioned + explicitly by the MOVE-CURSOR subcommand or it may be positioned + implicitly by field data or other DET subcommands (e.g., + ERASESCREEN and ERASE-UNPROTECTED). + + Field size, attributes, and contents may be defined using the + FORMAT-DATA subcommand followed by field data. Alternatively, a + field with default attributes may be defined using only the field + data. In this case, field size is the data string length. The + data string is terminated by the GO-AHEAD or any DET subcommand, + except the REPEAT subcommand. + + There are no restrictions on attribute combinations that might be + applied to a field even though some combinations may not be + supported by terminal hardware. The terminal implementation + should display the field with a "reasonable" combination of + attributes. There is an error code that might be returned when an + "unsupported combination of format attributes" is detected. It is + not clear what the application should do about the error. In any + event, 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 is the + responsibility of the application implementation to properly + translate carriage returns, line feeds, tabs, etc. to the + appropriate DET subcommands. + + The maximum number of fields a screen might contain is the screen + + + +Yasuda & Thompson [Page 20] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + size in characters (the product of characters per line and lines + per screen). + + Fields may not overlap. That is, a new field may not start or end + within a previously defined field. However, overwriting of a + field to change its attributes or contents is permitted. + + There are no restrictions on the order in which a form is built + (e.g., left-to-right and top-to-bottom); the terminal + implementation must be prepared to handle any order. Terminal + implementations are encouraged to display data as it arrives to + accommodate applications that persist in displaying status updates + on the task(s) they are performing. + + If an application elects to modify a user edited form, it must + properly position the cursor making no assumptions about where the + user might have left the cursor. Further it must exactly + overwrite the existing fields. + + When form construction is complete, the application indicates its + response requirements by sending the appropriate transmit + subcommand. It may send TRANSMIT-SCREEN, TRANSMIT-UNPROTECTED, or + TRANSMIT-MODIFIED to request data and/or it may send READ-CURSOR + to request cursor position. TRANSMIT-MODIFIED should be used + whenever possible to minimize the volume of data transmitted + between user and server hosts. + + Form response + + A form response is generated by the terminal implementation when + the user signals "form-complete" or enters an enabled function + key. The data returned are determined by the application through + the transmit subcommands. If no transmit subcommand was sent the + Modified and Protection attributes are used to determine an + implied transmit subcommand. If the Modified attribute has been + negotiated, assume TRANSMIT-MODIFIED. If the Protection attribute + has been negotiated but the Modified has not, assume + TRANSMITUNPROTECTED. If neither has been negotiated, assume + TRANSMITSCREEN. (The intent is to achieve transmission efficiency + by returning the smallest amount of data permitted by the in-force + DET attributes.) + + CAUTION: + + With TRANSMIT-MODIFIED the terminal implementation + must return all fields marked with the Modified + attribute in addition to fields actually modified by + the terminal user. + + + +Yasuda & Thompson [Page 21] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + Returned fields are identified and delimited using the + DATATRANSMIT and/or FIELD-SEPARATOR subcommands. The DATA- + TRANSMIT subcommand indicates the cursor address of the field that + follows it and there are no restrictions on the order in which + fields are returned. The FIELD-SEPARATOR subcommand conveys + left-to-right and top-to-bottom field ordering. Data not preceded + by one of these subcommands is assumed to be the first unprotected + field in the form. A FIELD-SEPARATOR followed by FIELD-SEPARATOR + indicates a field was unchanged and not returned. + + Unless otherwise restricted by Numeric-only or Alphabetic-only + attributes, data entered into unprotected fields is restricted to + the printable ASCII characters and "BELL" (codes 32 through 126 + and 7 decimal); no other characters are permitted. + + Function keys + + By general agreement, DODIIS terminal implementations will support + 64 function keys (key values 0 through 63). Information on + mapping function keys to application functions is the + responsibility of the application and should be provided to the + terminal user in the form of user documentation. + + The application enables and disables the function keys and + indicates its form response requirements by sending the + ENABLEFUNCTION-KEY subcommand. The terminal implementation + validates function key selections based on information received in + the ENABLE-FUNCTION-KEY bitmap. When an enabled function key is + entered, the terminal returns a form response (if indicated in the + bitmap), a FUNCTION-KEY subcommand, and the GO-AHEAD. + + Virtual function keys are part of the DET's virtual keyboard and + are "locked" when the application has the GO-AHEAD. Since the + terminal sends the GO-AHEAD when a function key is entered, + entering a function key "re-locks" all function keys until the + GO-AHEAD is returned. + + Field selection + + Any character within a field having the Selectable attribute is a + candidate for selection. When selection is made, the terminal + returns a SELECTED-FIELD subcommand identifying the character + position selected. Multiple selections are permitted; however, + the ordering of the selections need not be preserved. Field + selection does not cause the GO-AHEAD to be sent. The GO-AHEAD + must be sent as a result of another user action such as a function + key entry or "form-complete" indication. Field selection is + disabled when the application has the GO-AHEAD. + + + +Yasuda & Thompson [Page 22] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + Out-of-context data + + The out-of-context-data subcommands identify data that is clearly + not in the context of the form interaction. It is a convenient + not in the mechanism for sending ARE-YOU-THERE responses or host + advisory messages to the user without disturbing the DET's virtual + screen or altering the context of the form interaction. + + The application may send out-of-context data at anytime. The data + must be preceded by the START-OUT-OF-CONTEXT-DATA subcommand and + followed immediately by the END-OUT-OF-CONTEXT-DATA subcommand. + The out-of-context data should contain carriage returns and line + feeds to facilitate formatting. The sender should limit the + amount of data sent, since most terminal implementations must + buffer the data prior to 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. The following + rules 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, and ARE-YOU-THERE). Nothing else is + valid. + + When the terminal has the GO-AHEAD, the application may send + out-of-context data or MOVE-CURSOR and FORMAT-DATA subcommands + 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, instances will occur when the user + has the GO-AHEAD but the application needs it to display a new + form. (This is most likely to occur when the user enters an + + + +Yasuda & Thompson [Page 23] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + + INTERRUPT PROCESS.) When it does occur, the application should + send an out-of-context-context message requesting 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 that + described for NVT in MIL-STD-1782. These rules apply only when + operating in DET mode. At other times, the descriptions contained + 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." + + + + + + + + + + + + + + + + + + + + + + +Yasuda & Thompson [Page 24] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + +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> + + + + + + + + + + + + + + + + + + + + + + + +Yasuda & Thompson [Page 25] + +RFC 1043 Data Entry Terminal - DODIIS February 1988 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + +Yasuda & Thompson [Page 26] + |