📄 rfc1043.txt
字号:
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -