Telnet Data Entry Terminal option(7)

　　In the case of formatting the data, the minimal implementation　should be able to support a low and high level of intensity and　protection for all or no characters in a field. These functions,　however, are not required.

　　The minimal implementation also requires that the Output Line Width　and Output Page Size Telnet options be supported.

　　4. Motivation

　　The Telnet protocol was originally designed to provide a means for　scroll-mode terminals, such as the standard teletype, to communicate　with processes through the network. This was suitable for the vast　majority of terminals and users at that time. However, as use of the　network has increased into other areas, especially areas where the　network is considered to provide a production environment for other　work, the desires and requirements of the user community have changed.

　　Therefore, it is necessary to consider supporting facilities that were　not initially supported. This Telnet option attempts to do that for　applications that require data entry terminals.

　　This option in effect defines the Network Virtual Data Entry Terminal.

　　Although the description of this option is quite long, this does not　imply that the Telnet protocol is a poor vehicle for this facility.　Data Entry Terminals are rather complex and varied in their abilities.

　　This option attempts to support both the minimal set of useful　functions that are either common to all or can be easily simulated and　the more sophisticated functions supplied in some terminals.

　　Unlike most real data entry terminals where the terminal functions are　encoded into one or more characters of the native character set, this　option performs all such controls within the Telnet subnegotiation　mechanism. This allows programs that are intimately familiar with the　kind of terminal they are communicating with to send commands that may　not be supported by either the option or the implementation. In other　words, it is possible to operate in a "raw" or at least "rare" mode　using as much of the option as necessary.

　　Although many data entry terminals support a variety of peripheral　devices such as printers, cassettes, etc. it is beyond the scope of　this option to entertain such considerations. A separate option should　be defined to handle this aspect of these devices.

　　5. Description

　　General Notes

　　All implementations of this option are required to support a certain　minimal set of the subcommands for this option. Section 3 contains a　complete list of the subcommands in this minimal set. In keeping　with the Telnet protocol philosophy that an implementation should　not have to be able to parse commands it does not implement, every　subcommand of this option is either in the minimal set or is covered　by one of the facility subcommands. An implementation must　"negotiate" with its correspondent for permission to use subcommands　not in the minimal set before using them. For details of this　negotiation process see the section below on facility subcommands.

　　Most data entry terminals are used in a half duplex mode. (Although　most DET's on the market can be used either as data entry terminals　or as standard interactive terminals, we are only concerned here　with their use as DET's.) When this option is used, it is suggested　that the following Telnet options be refused: Echo, Remote　Controlled Transmission and Echoing, and Suppress Go-Ahead. However,　this option could be used to support a simple full duplex CRT based　application using the basic cursor control functions provided here.

　　For these cases, one or more of the above list of options might be　required. (Support of sophisticated interactive calligraphic　applications is beyond the scope of this option and should be done　by another option or the Network Graphics Protocol.)

　　In RFC728, it was noted that a synch sequence can cause undesired　interactions between Telnet Control functions and the data stream. A　synch sequence causes data but not control functions to be flushed.

　　If a control function which has an effect on the data immediately　following it is present in the data stream when a synch sequence　occurs, the control function will have its effect not on the　intended data but on the data immediately following the Data Mark.

　　The following DET subcommands are susceptible to this pitfall:

　　CHAR INSERT

　　DATA TRANSMIT

　　FORMAT DATA