RFC relevance of facility

As per Relevance of the word facility, we have this rfc below:

Network Working Group A.
Request for Comments: 1043 T.
Defense Intelligence
Updates: RFC 732 February 1988

TELNET Data Entry Terminal
DODIIS

Status of this

This RFC suggests a proposed protocol on the TELNET Data
Terminal (DET) Option - DODIIS Implementation for the
community. It is intended that this specification be compatible
the specification of DET Option in RFC-732. Discussion
suggestions for improvements are encouraged. Distribution of
memo is unlimited

In the early 1980s, the Defense Intelligence Agency (DIA)
the tasks of developing a TELNET capability to access full
applications across a packet switching network. This effort
successful by implementing Data Entry Terminal (DET) options
the TELNET protocol based on RFC 732. These DET options have
implemented on IAS, MVS, OS86 and UNIX operating systems.
options are being developed for VM and VMS operating systems

The Department of Defense Intelligence Information System (DODIIS)
a confederation of heterogeneous computer systems and
terminals utilizing the Defense Data Network (DDN) as
communications backbone (namely the SCINET/DSNET-3).

Although the reason for implementing a DET option specification
based upon data base application interfaces, the use of a full
TELNET provides a method to achieve higher efficiency on the network
Most terminal to host applications on the ARPANET are character
TELNETs. This is both costly in time and network utilization,
one character pressed on the keyboard generates a datagram
of TCP/IP headers plus the character sent to the host and the
echoes back a similar datagram. In the DODIIS community,
are highly encouraged to implement full screen applications; line
a time is acceptable; and character remote echo mode is discouraged

This RFC in its final form will be implemented on SCINET. During
interim period, the "DODIIS TELNET Network Virtual Data
Terminal (NVDET) Option Specification", DIA, April 1983, will
implemented

Yasuda & Thompson [Page 1]

RFC 1043 Data Entry Terminal - DODIIS February 1988

TABLE OF
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
to express numbers in decimal. Data fields are described left
right, with the most significant octet on the left and the
significant octet on the right

The order of transmission of the data described in this document
resolved to the octet level. Whenever a diagram shows a group
octets, the order of transmission of those octets is the normal
in which they are read in English. For example, in the
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

Whenever an octet represents a numeric quantity, the left most bit
the diagram is the high order or most significant bit. That is,
bit labeled 0 is the most significant bit. For example,
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

Similarly, whenever a multi-octet field represents a
quantity, the left most bit of the whole field is the
significant bit. When a multi-octet quantity is transmitted the
significant octet is transmitted first

Yasuda & Thompson [Page 3]

RFC 1043 Data Entry Terminal - DODIIS February 1988

1. Command Name and Option

DET 20

2. Command

IAC WILL

The sender of this command REQUESTS permission to begin,
AGREES that it will begin, sending and receiving Data
Terminal (DET) subcommands to control session interactions

IAC WONT

If the connection is already operating in DET mode, the
of this command DEMANDS that the connection stop operating
DET mode and begin operating in TELNET NVT mode. If
connection is not operating in DET mode, the sender REFUSES
begin operating in DET mode. A connection is operating
TELNET NVT mode when both parties are interpreting data
described by the TELNET SPECIFICATION, MIL-STD-1782.

IAC DO

The sender of this command REQUESTS permission to begin,
AGREES that it will begin, sending and receiving Data
Terminal (DET) subcommands to control session interactions

IAC DONT

If the connection is already operating in DET mode, the
of this command DEMANDS that the connection stop operating
DET mode and begin operating in TELNET NVT mode. If
connection is not operating in DET mode, the sender REFUSES
begin operating in DET mode. A connection is operating
TELNET NVT mode when both parties are interpreting data
described by the TELNET SPECIFICATION, MIL-STD-1782.

DODIIS implementations of the DET option use the
described in the remainder of Section 2. A description of
DODIIS DET model and DET subcommand usage is contained in
5.

FACILITIES SUBCOMMANDS. Facilities subcommands are used to
DET facilities (subcommands and attributes). The
subcommands indicate the DET facilities the sender supports
Facility negotiation may be viewed as the terminal indicating
facilities it provides and the application indicating the

Yasuda & Thompson [Page 4]

RFC 1043 Data Entry Terminal - DODIIS February 1988

it desires. The bits of the facility maps are numbered from
right starting at zero. Thus, if bit 2 is set, the field will have
decimal value of 4.

IAC SB DET EDIT-FACILITIES <facility map> IAC

subcommand code: 1

This subcommand indicates the edit facilities the
supports. The <facility map> parameter is one eight bit
containing the following flags

Bits 5-7
Bit 4 Read
Bits 0-3

where

If the Read-Cursor bit is set, the sender supports
READ-CURSOR and CURSOR-POSITION subcommands

Reserved bits represent edit facilities that are
defined for DODIIS implementations; therefore,
descriptions are provided. Reserved bits must be
to indicate non support of the associated edit facilities

IAC SB DET ERASE-FACILITIES <facility map> IAC

subcommand code: 2

This subcommand indicates the erase facilities the
supports. The <facility map> parameter is one eight
byte containing flags. Since no erase facilities
defined for DODIIS implementations, no descriptions
provided. The ERASE-FACILITIES subcommand is part of
minimal DET implementation and is included for that reason
DODISI implementors must declare non support of
facilities by sending this subcommand with a zeroed
map

IAC SB DET TRANSMIT-FACILITIES <facility map> IAC

subcommand code: 3

This subcommand indicates the transmit facilities the
supports. The <facility map> parameter is one eight bit
containing the following flags

Yasuda & Thompson [Page 5]

RFC 1043 Data Entry Terminal - DODIIS February 1988

Bits 6-7
Bit 5 Data
Bits 0-4

where

If the Data-Transmit bit is set, the sender supports
DATA-TRANSMIT subcommand

Reserved bits represent transmit facilities that are
defined for DODIIS implementations; therefore,
descriptions are provided. Reserved bits must be
to indicate non support of the associated
facilities

IAC SB DET FORMAT-FACILITIES <facility map> IAC

subcommand code: 4

This subcommand indicates the format facilities the
supports. The <facility map> parameter is two eight bit
containing the following

Byte 0
Bit 7 Function
Bit 6
Bit 5 Field
Bit 4
Bit 3
Bit 2 Reverse
Bit 1 Right
Bit 0

Byte 1
Bit 7 Reserved for
Bit 6
Bit 5
Bit 4 Alphabetic-
Bit 3 Numeric-
Bits 0-2

where

If the Function-Key bit is set, the sender supports
FUNCTION-KEY and ENABLE-FUNCTION-KEY subcommands

If the Modified bit is set, the sender supports
FORMAT-DATA subcommand's Modified attribute and

Yasuda & Thompson [Page 6]

RFC 1043 Data Entry Terminal - DODIIS February 1988

TRANSMIT-MODIFIED subcommand

If the Field-Selection bit is set, the sender
the FORMAT-DATA subcommand's Selectable attribute
the SELECTED-FIELD subcommand

If the Repeat bit is set the sender supports the
subcommand

If the Blinking bit is set, the sender requests
provides the ability to emphasize a string of
by causing them to blink when displayed. (See
FORMAT-DATA subcommand.)

If the Reverse-Video bit is set, the sender requests
provides the ability to emphasize a string of
by "reversing their video image". If characters
normally displayed as dark characters on a
background, they are reversed and displayed as
characters on a dark background,
vice versa. (See the FORMAT-DATA subcommand.)

If the Right-Justification bit is set, the
requests or provides the ability to cause data
in a field to be right justified within the field. (
the FORMAT-DATA subcommand.)

If the Protection bit is set, the sender requests
provides the ability to protect certain fields
on the DET screen from being altered by the user
supports the ERASE-UNPROTECTED, FIELD-SEPARATOR,
TRANSMIT-UNPROTECTED subcommands. (See the FORMAT-
subcommand.)

If the Alphabetic-Only bit is set, the sender
or provides the ability to constrain the user of the
such that only alphabetic data may be entered
certain fields. (See the FORMAT-DATA subcommand.)

If the Numeric-Only bit is set, the sender requests
provides the ability to constrain the user of the
such that only numeric data may be entered into
fields. (See the FORMAT-DATA subcommand.)

The Intensity parameter is three bits wide and
interpreted as a positive binary integer indicating
number of visible levels of intensity that the
requests or provides for displaying data. (See

Yasuda & Thompson [Page 7]

RFC 1043 Data Entry Terminal - DODIIS February 1988

FORMAT-DATA subcommand.)

Reserved bits represent format facilities that are
defined for DODIIS implementations; therefore,
descriptions are provided. Reserved bits must
zeroed to indicate non support of the associated
facilities

EDIT SUBCOMMANDS. Edit subcommands are sent by the application
position the cursor on the DET screen

IAC SB DET MOVE-CURSOR IAC

subcommand code: 5

This subcommand positions the DET cursor at screen
(x,y). the and parameters are positive eight
binary integers representing the character and line positions
respectively, of a DET screen location. Values of x
from zero (0) through M-1, where M is the DET screen width
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

subcommand code: 12

This subcommand positions the cursor at DET screen
(0,0). It is equivalent to the MOVE-CURSOR subcommand,
x=0 and y=0.

TRANSMIT SUBCOMMANDS. Transmit subcommands are sent by
application to request data from the DET or by the terminal
identify data returned from the DET

IAC SB DET READ-CURSOR IAC

subcommand code: 17

This subcommand requests return of the DET cursor position
Use of this subcommand requires facility negotiation; see
EDITFACILITIES subcommand, Read-Cursor bit

IAC SB DET CURSOR-POSITION IAC

subcommand code: 18

This subcommand returns cursor position in response to

Yasuda & Thompson [Page 8]

RFC 1043 Data Entry Terminal - DODIIS February 1988

READCURSOR subcommand. The and parameters
eight bit binary integers representing the cursor's position
The and parameters are positive eight bit
integers representing the character and line positions
respectively, of a DET screen location. Values of x
from zero (0) through M-1, where M is the DET screen width
characters. Values of y range from zero (0) through N-1,
where N is the DET screen length in lines. Use of
subcommand requires facility negotiation; see
EDIT-FACILITIES subcommand, Read-Cursor bit

IAC SB DET TRANSMIT-SCREEN IAC

subcommand code: 20

This subcommand requests return of all characters on the
screen beginning at cursor position (0,0). M x N characters
where M is the DET screen width in characters and where N
the DET screen length in lines, are returned with a
character returned for each character in the unwritten
(the areas between defined fields). FIELD-SEPARATOR
DATA-TRANSMIT subcommands are not required to delimit
identify fields

IAC SB DET TRANSMIT-UNPROTECTED IAC

subcommand code: 21

This subcommand requests return of all characters
unprotected fields. Use of this subcommand requires
negotiation; see the FORMAT-FACILITIES subcommand,
bit

IAC SB DET TRANSMIT-MODIFIED IAC

subcommand code: 27

This subcommand requests return of all characters in
fields. Modified fields are fields that have the
attribute set (see FORMAT-DATA subcommand) as well as
actually modified by the user. Use of this
requires facility negotiation; see the FORMAT-
subcommand, Modified bit

IAC SB DET DATA-TRANSMIT IAC

subcommand code: 28

Yasuda & Thompson [Page 9]

RFC 1043 Data Entry Terminal - DODIIS February 1988

This subcommand identifies a field returned in response
a TRANSMIT-MODIFIED subcommand. The and
are positive eight bit binary integers indicating the
position of the field that follows the DATA-
subcommand. This subcommand may precede the first field
a transmission with subsequent fields separated by
FIELD-SEPARATOR subcommand or it may precede each field
Use of this subcommand requires facility negotiation;
the TRANSMIT-FACILITIES subcommand, Data-Transmit bit

ERASE SUBCOMMANDS. Erase subcommands are used by the application
erase the DET screen or selected DET screen areas. In
erase operations, the erased characters are replaced with
characters

IAC SB DET ERASE-SCREEN IAC

subcommand code: 29

This subcommand erases all characters from the DET screen
All fields regardless of their attributes are deleted.
cursor position after the operation is at (0,0). If
protection attribute has been negotiated, the erased
contains protected SPACE characters

IAC SB DET ERASE-UNPROTECTED IAC

subcommand code: 35

This subcommand erases all characters in the unprotected
of the DET screen. This subcommand replaces field
with SPACE characters; field attributes and sizes are
changed. The cursor position after the operation is at
beginning of the first unprotected field or, if there is
unprotected field, at (0,0). Use of this subcommand
facility negotiation; see the FORMAT-FACILITIES subcommand
Protection bit

FORMAT SUBCOMMANDS. The format subcommands are used by
application to define the fields of a form and by the terminal
delimit fields sent from the DET

IAC SB DET FORMAT-DATA IAC

subcommand code: 36

This subcommand defines the attributes and size of a DET field
The parameter defines the field attributes and

Yasuda & Thompson [Page 10]

RFC 1043 Data Entry Terminal - DODIIS February 1988

parameter defines the field size. The field starts
the position of the cursor when the subcommand is acted upon
The next data characters in the data stream fill
field

The parameter is two eight bit bytes and
the following

Byte 0
Bit 7
Bit 6 Reverse
Bit 5 Right
Bits 3-4
Bits 0-2

Byte 1
Bits 5-7
Bits 2-4 Reserved for
Bit 1
Bit 0

where

If the Blinking bit is set, the following field
characters should have the Blinking
applied to it by the receiver

If the Reverse Video bit is set, the following field
characters should be displayed by the
with video reversed

If the Right Justification bit is set,
entered into the field by the user should be
justified

The Protection attribute is two bits wide and may
on the following values

0 No protection. Any valid DET data character
be entered in the field

1 Protected. No data may be entered in the field

2 Alphabetic-only. Only the alphabetic
(A-Z and a-z) or the space character may
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
point (.) or the space character may be entered
the field

The Intensity attribute is three bits wide and
the brightness to be used when displaying the
in or entered into the field characters wide
The available number of visible intensity levels
have been negotiated using the FORMAT-
subcommand. A value of zero (0) indicates
brightness should be OFF; that is, characters in
entered into the field should not be displayed.
values 1-7 indicate relative brightness; the
algorithm for mapping these values to the
levels of intensity is left to the implementors

If the Modified bit is set, the field is considered
have been modified and will be returned, along with
user modified fields

If the Selectable bit is set, the field is a
for field selection using the DET field
device

The parameter is two bytes and should be interpreted as
positive 16-bit binary integer that defines the field size.
high order bit is transmitted first. Data, not in the scope
the count of a FORMAT-DATA subcommand, should be displayed
the default field attributes (no blinking, no reverse video,
justification, no protection, not modified, not selectable, and
visible intensity). Minimum field size is one (1) character
Maximum field size is determined by a field's starting
and the end of the screen or the start of the next field

Use of field attributes requires facility negotiation; see
FORMAT-FACILITIES subcommand

IAC SB DET REPEAT IAC

subcommand code: 37

This subcommand permits compression of DET data by
strings of identical characters as the character and a
count. The parameter is a positive 8-bit
integer. The parameter is a valid DET data character
Use of this subcommand requires facility negotiation;
the FORMAT-FACILITIES subcommand, Repeat bit

Yasuda & Thompson [Page 12]

RFC 1043 Data Entry Terminal - DODIIS February 1988

IAC SB DET FIELD-SEPARATOR IAC

subcommand code: 39

This subcommand separates fields returned by the DET
response to TRANSMIT-MODIFIED or TRANSMIT-
subcommands. Use of this subcommand requires
negotiation; see the FORMAT-FACILITIES subcommand
Protection bit

MISCELLANEOUS

IAC SB DET FUNCTION-KEY IAC subcommand code: 40 This subcommand transmits a user entered function key code The parameter is one byte that identifies the function key entered. Function key values range 0 to 255. This subcommand is used in conjunction with ENABLE-FUNCTION-KEY subcommand. Use of this requires facility negotiation; see the FORMAT- subcommand, Function-Key bit IAC SB DET ERROR IAC subcommand code: 41 This subcommand allows a DET option implementation to errors it detects to the corresponding TELNET process. parameter is one byte containing the subcommand of the subcommand causing the error. The parameter is one byte containing a DET error code. ( Appendix 2 for DET error codes.) Errors should be reported when detected. However, implementation should attempt to carry out the intent the subcommand or data in error IAC SB DET START-OUT-OF-CONTEXT-DATA IAC subcommand code: 42 This subcommand precedes out-of-context data. The following this subcommand and prior to END-OUT-OF-CONTEXT-DATA subcommand is NOT part of the form. The out-out-of-context data should be interpreted NVT mode data (i.e., it may contain carriage return and Yasuda & Thompson [Page 13] RFC 1043 Data Entry Terminal - DODIIS February 1988 feed characters) and should be displayed in a timely non-destructive fashion IAC SB DET END-OUT-OF-CONTEXT-DATA IAC subcommand code: 43 This subcommand indicates the end of the out-of-context data IAC SB DET ENABLE-FUNCTION-KEYS IAC subcommand code: 44 This subcommand enables (or disables) virtual function keys indicates the application's data requirements on function selection. The parameter is a variable length string. Each byte contains four bit-pairs and each bit- represents a single function key. The first byte function keys zero (0) through three (3); the second byte function keys four (4) through seven (7); and so on. Bit- 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 screen data and/or cursor position, as well as, FUNCTION-KEY subcommand are returned on function selection 3 Undefined Function keys not explicitly represented in the bitmap disabled (i.e., they are assumed to have a bit-pair value zero (0)). Use of this subcommand requires facility negotiation; see FORMAT-FACILITIES subcommand; Function-Key bit IAC SB DET SELECTED-FIELD IAC subcommand code: 45 This subcommand identifies a user selected field. The parameters are the cursor position of the selected from within a selectable field (see the FORMAT- Yasuda & Thompson [Page 14] RFC 1043 Data Entry Terminal - DODIIS February 1988 subcommand, Selectable attribute.) Use of this requires negotiation; see the FORMAT-FACILITIES subcommand Field-Selection bit 3. Default and Minimal Default WONT DET -- DONT If the DET option cannot be negotiated, the connection not operated in DET mode Minimal DET Implementation The minimal DET implementation consists of all DET that may be used without prior negotiation. These are as follows EDIT- ERASE- TRANSMIT- FORMAT- MOVE- HOME- ERASE- TRANSMIT- FORMAT- START-OUT-OF-CONTEXT- END-OUT-OF-CONTEXT- DODIIS DET implementation requirements The minimal DET implementation set of subcommands is not enough to support forms interactions between DODIIS and DODIIS applications. Therefore, DODIIS implementations the DET option must support additional DET subcommands DODIIS terminal (User Host) implementations must implement support all of the DET subcommands contained in Section 2, well as those DET attributes supported by the terminal and any DET attributes easily emulated in software. application (Server Host) implementations must implement support those DET subcommands and attributes required by applications Yasuda & Thompson [Page 15] RFC 1043 Data Entry Terminal - DODIIS February 1988 DODIIS implementation recommendations are contained in table that follows. DODIIS implementors are cautioned failure to provide recommended support may interoperability Recommended DET support levels for DODIIS USER HOST SERVER DET SUBCOMMANDS SUPPORT LEVEL SUPPORT --------------- ------------- ------------- EDIT-FACILITIES send & receive send & ERASE-FACILITIES send & receive send & TRANSMIT-FACILITIES send & receive send & FORMAT-FACILITIES send & receive send & REPEAT send & receive send & ERROR send & receive send & MOVE-CURSOR receive only send HOME-CURSOR receive only send READ-CURSOR receive only send TRANSMIT-SCREEN receive only send TRANSMIT-UNPROTECTED receive only send TRANSMIT-MODIFIED receive only send ERASE-SCREEN receive only send ERASE-UNPROTECTED receive only send FORMAT-DATA receive only send START-OUT-OF-CONTEXT-DATA receive only send END-OUT-OF-CONTEXT-DATA receive only send ENABLE-FUNCTION-KEYS receive only send CURSOR-POSITION send only receive DATA-TRANSMIT send only receive FIELD-SEPARATOR send only receive FUNCTION-KEY send only receive SELECTED-FIELD send only receive DET -------------- 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) ----- 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 In 1981, the TELNET DET option (RFC 732) was selected as the to support interactions between DODIIS forms applications and forms terminals. The intent was to foster a high degree interoperability between DODIIS hosts with forms applications terminals. Since that time, the DET option has been and is implemented by several independent organizations within the community Motivated by concern that the independently developed of the DET option may not interoperate with one another, implementors met to identify DODIIS implementation requirements to resolve implementation issues that affect interoperability This document attempts to present the agreements and of the DODIIS implementors 5. Description and Implementation 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 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 fields of a form and returning the modified fields c. Function keys that may be enabled and disabled on a key-by- basis by the application d. A field selection device, similar to a light pen, that user selection of characters within appropriately "selectable" fields The DODIIS DET screen has default sizes of 80 characters and 24 lines. These defaults may be changed through negotiation using Output Line Width and the Output Page Size options. When the Yasuda & Thompson [Page 17] RFC 1043 Data Entry Terminal - DODIIS February 1988 cannot agree on screen size through negotiation, the default 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 special display character called the cursor, where x is the of a character on a line and y is the line position on the screen. Values of x range from 0 (the left most character on the line) to M-1, where M is the line length. Values of y from 0 (the top most line on the screen) to N-1, where N is the length. The cursor may be moved to any position on the DET without disturbing the characters already displayed Valid field data for DET forms are the displayable ASCII codes in the range 32 through 126 decimal and character 7 "BELL". Negotiating the DET The DET option is negotiated when either party REQUESTS use of DET option and the other party AGREES to its use. The DET is requested by sending a DO DET and WILL DET and is accepted sending a WILL DET and DO DET. (In the spirit of negotiation, the DET option must be negotiated for both on the connection.) Several TELNET options conflict with the DET option. Therefore when the DET option is negotiated, the following TELNET should be refused (or explicitly terminated): Echo, Suppress Go Ahead, and Binary. (The Suppress Go-Ahead is the default state DODIIS TELNET connections when they are first established.) DET facilities All implementations of the DET option are required to support minimal DET implementation described in Section 3. In addition DODIIS implementations are required to support subcommands attributes that are consistent with DODIIS requirements. Before any of these additional DET facilities be used, an implementation must negotiate with its for permission to use them The four facility subcommands (EDIT-FACILITIES, ERASE-FACILITIES TRANSMIT-FACILITIES, and FORMAT-FACILITIES) are used to DET subcommands and attributes. This negotiation consists of exchange of facility subcommands and may be viewed as the (User Host) indicating the facilities it provides and application program (Server Host) indicating the facilities desires. The facilities that are jointly supported (and may Yasuda & Thompson [Page 18] RFC 1043 Data Entry Terminal - DODIIS February 1988 used) are arrived at by forming the logical intersection of facility map that was sent with the facility map that received. (For the intensity attribute, the lesser of the of intensity levels sent and the number of intensity received will be used.) An implementation must record currently agreed upon set of subcommands and attributes. subcommands and attributes reflected in that set may be without further exchange of facility subcommands Either party or both parties may initiate facilities without confusion as long as care is taken to avoid non terminating negotiation loops. In particular, if you negotiation by sending a facility subcommand, you must that you did initiate the negotiation. On receipt of a subcommand; if you initiated the negotiation, no response required and the negotiation is complete; if you did not the negotiation, you must respond by sending the facility subcommand to the requester. (Note that there is requirement to negotiate facilities one class at a time and the awareness of who initiated the negotiation must be for each of the facility subcommands.) A TELNET implementation responding to a facility subcommand is required to compute the logical intersection of the maps responding. It should respond as quickly as possible with facility map indicating all facilities of that class that supports. There is no confusion since both parties compute set of supported subcommands and attributes in the same fashion Note that while both parties must agree to the use of the subcommands and attributes, either party may disable use at 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 facility maps are sent to indicate support and/or ignorance of the facility. The reserved bits may be in the future General DET In the general interaction, the application constructs a form, negotiates the desired options, indicates required responses, and sends the TELNET GO-AHEAD. The GO- signals that the form construction is complete and that the 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 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 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 the application may continue the interaction by altering the form Form The application implementation constructs a form on an screen by defining each of the fields in the form. The DET are defined by their starting cursor position, size, attributes and contents (data). A field's starting cursor position is the cursor position of first character in the field. The cursor may be explicitly by the MOVE-CURSOR subcommand or it may be implicitly by field data or other DET subcommands (e.g., ERASESCREEN and ERASE-UNPROTECTED). Field size, attributes, and contents may be defined using FORMAT-DATA subcommand followed by field data. Alternatively, field with default attributes may be defined using only the data. In this case, field size is the data string length. 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 applied to a field even though some combinations may not supported by terminal hardware. The terminal should display the field with a "reasonable" combination attributes. There is an error code that might be returned when "unsupported combination of format attributes" is detected. It not clear what the application should do about the error. In event, this condition should not provoke session termination Field contents (data) are restricted to printable ASCII and "BELL" (codes 32 through 126 and 7 decimal). It is responsibility of the application implementation to translate carriage returns, line feeds, tabs, etc. to appropriate DET subcommands The maximum number of fields a screen might contain is the Yasuda & Thompson [Page 20] RFC 1043 Data Entry Terminal - DODIIS February 1988 size in characters (the product of characters per line and per screen). Fields may not overlap. That is, a new field may not start or within a previously defined field. However, overwriting of field to change its attributes or contents is permitted There are no restrictions on the order in which a form is (e.g., left-to-right and top-to-bottom); the implementation must be prepared to handle any order. implementations are encouraged to display data as it arrives accommodate applications that persist in displaying status on the task(s) they are performing If an application elects to modify a user edited form, it properly position the cursor making no assumptions about where user might have left the cursor. Further it must overwrite the existing fields When form construction is complete, the application indicates response requirements by sending the appropriate subcommand. It may send TRANSMIT-SCREEN, TRANSMIT-UNPROTECTED, TRANSMIT-MODIFIED to request data and/or it may send READ- to request cursor position. TRANSMIT-MODIFIED should be whenever possible to minimize the volume of data between user and server hosts Form A form response is generated by the terminal implementation the user signals "form-complete" or enters an enabled key. The data returned are determined by the application the transmit subcommands. If no transmit subcommand was sent Modified and Protection attributes are used to determine implied transmit subcommand. If the Modified attribute has negotiated, assume TRANSMIT-MODIFIED. If the Protection has been negotiated but the Modified has not, TRANSMITUNPROTECTED. If neither has been negotiated, TRANSMITSCREEN. (The intent is to achieve transmission by returning the smallest amount of data permitted by the in- DET attributes.) CAUTION With TRANSMIT-MODIFIED the terminal must return all fields marked with the attribute in addition to fields actually modified the terminal user Yasuda & Thompson [Page 21] RFC 1043 Data Entry Terminal - DODIIS February 1988 Returned fields are identified and delimited using DATATRANSMIT and/or FIELD-SEPARATOR subcommands. The DATA TRANSMIT subcommand indicates the cursor address of the field follows it and there are no restrictions on the order in fields are returned. The FIELD-SEPARATOR subcommand left-to-right and top-to-bottom field ordering. Data not by one of these subcommands is assumed to be the first field in the form. A FIELD-SEPARATOR followed by FIELD- indicates a field was unchanged and not returned Unless otherwise restricted by Numeric-only or Alphabetic- attributes, data entered into unprotected fields is restricted the printable ASCII characters and "BELL" (codes 32 through 126 and 7 decimal); no other characters are permitted Function By general agreement, DODIIS terminal implementations will 64 function keys (key values 0 through 63). Information mapping function keys to application functions is responsibility of the application and should be provided to terminal user in the form of user documentation The application enables and disables the function keys indicates its form response requirements by sending ENABLEFUNCTION-KEY subcommand. The terminal validates function key selections based on information received the ENABLE-FUNCTION-KEY bitmap. When an enabled function key entered, the terminal returns a form response (if indicated in bitmap), a FUNCTION-KEY subcommand, and the GO-AHEAD Virtual function keys are part of the DET's virtual keyboard are "locked" when the application has the GO-AHEAD. Since terminal sends the GO-AHEAD when a function key is entered entering a function key "re-locks" all function keys until GO-AHEAD is returned Field Any character within a field having the Selectable attribute is candidate for selection. When selection is made, the returns a SELECTED-FIELD subcommand identifying the position selected. Multiple selections are permitted; however the ordering of the selections need not be preserved. selection does not cause the GO-AHEAD to be sent. The GO- must be sent as a result of another user action such as a key entry or "form-complete" indication. Field selection disabled when the application has the GO-AHEAD Yasuda & Thompson [Page 22] RFC 1043 Data Entry Terminal - DODIIS February 1988 Out-of-context The out-of-context-data subcommands identify data that is not in the context of the form interaction. It is a not in the mechanism for sending ARE-YOU-THERE responses or advisory messages to the user without disturbing the DET's screen or altering the context of the form interaction The application may send out-of-context data at anytime. The must be preceded by the START-OUT-OF-CONTEXT-DATA subcommand followed immediately by the END-OUT-OF-CONTEXT-DATA subcommand The out-of-context data should contain carriage returns and feeds to facilitate formatting. The sender should limit amount of data sent, since most terminal implementations buffer the data prior to displaying it. The implementation should display the data to the user in a fashion. The data is for display only, no user response required, and there is no mechanism for user response Line The subject of DET and line discipline (controlling the using the GO-AHEAD) causes a bit of confusion. The 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 explicitly When the application has the GO-AHEAD, the implementation may send TELNET commands (INTERRUPT-PROCESS ABORT-OUTPUT, BREAK, and ARE-YOU-THERE). Nothing else valid When the terminal has the GO-AHEAD, the application may out-of-context data or MOVE-CURSOR and FORMAT-DATA to update protected fields. Nothing else is valid. ( terminal implementation must display the out-of-context and the field updates as soon as convenient.) The terminal implementation sends the GO-AHEAD, without action on the part of the terminal user, when an function key or a "form-complete" is entered Since the terminal user must take explicit action to return GO-AHEAD to the application, instances will occur when the has the GO-AHEAD but the application needs it to display a form. (This is most likely to occur when the user enters Yasuda & Thompson [Page 23] RFC 1043 Data Entry Terminal - DODIIS February 1988 INTERRUPT PROCESS.) When it does occur, the application send an out-of-context-context message requesting the user enter a "form-complete". If the user cooperates, the can ignore any associated form response and regain control of connection to display its form The line discipline described here is more rigorous than described for NVT in MIL-STD-1782. These rules apply only operating in DET mode. At other times, the descriptions in MIL-STD-1782 apply. This distinction is necessary to interoperability with non-DET implementations of TELNET Standard TELNET control The TELNET control functions, ERASE CHARACTER and ERASE LINE, NOT required and should not be sent in DET mode Other implementation a. The DODIIS DET conceptual model does not support editors or basic scrolling applications b. Implementors are cautioned that DET subcommand (e.g., facilities maps) may take on the value of the character and must be replicated if they are to be interpreted c. Principle of Robustness: "Be conservative in what you send; 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 ------ ----------------- 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 12 HOME- 17 READ- 18 CURSOR-POSITION 20 TRANSMIT- 21 TRANSMIT- 27 TRANSMIT- 28 DATA-TRANSMIT 29 ERASE- 35 ERASE- 36 FORMAT-DATA 37 REPEAT <character 39 FIELD- 40 FUNCTION-KEY 41 ERROR 42 START-OUT-OF-CONTEXT- 43 END-OUT-OF-CONTEXT- 44 ENABLE-FUNCTION-KEYS 45 SELECTED-FIELD Yasuda & Thompson [Page 25] RFC 1043 Data Entry Terminal - DODIIS February 1988 APPENDIX 2 - DET ERROR 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]if you see any problems within the linking, don't worry be happy, this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes, just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA. RFC documents can be found at I.E.T.F. Relevance System Copyright © 2002 Spectrum WorldResearch other technical nosh by ServerMasters Corporation collaboration of BobX