[Docs] [txt|pdf] [Tracker]
PROPOSED STANDARD
NWG/RFC 749 BSG 26-Sep-78 13:13 45499
Network Working Group Bernard Greenberg
Request for Comments 749 MIT-Multics
NIC 45499 18 September 1978
Telnet SUPDUP-OUTPUT Option
1. Command name and code.
SUPDUP-OUTPUT 22
2. Command meanings.
IAC WILL SUPDUP-OUTPUT
The sender of this command REQUESTS permission to transmit
SUPDUP-OUTPUT format messages over the TELNET connection.
IAC WON'T SUPDUP-OUTPUT
The sender of this command STATES that he will no longer send
SUPDUP-OUTPUT format messages over the TELNET connection.
IAC DO SUPDUP-OUTPUT
The sender of this command grants the receiver permission to send
SUPDUP-OUTPUT format messages over the TELNET connection.
IAC DON'T SUPDUP-OUTPUT
The sender of this command DEMANDS that the receiver not send
SUPDUP-OUTPUT format messages over the TELNET connection.
IAC SB SUPDUP-OUTPUT 1 <terminal-parameters> IAC SE
The sender of this command (which must be the TELNET user process) is
supplying information describing the capabilities of the user
process' terminal.
IAC SB SUPDUP-OUTPUT 2 n TD1 TD2 .. TDn SCx SCy IAC SE
The sender of this command, which must be the TELNET server process,
is sending explicit screen control information to be carried out by
the user TELNET process.
3. Default.
WON'T SUPDUP-OUTPUT
DON'T SUPDUP-OUTPUT
i.e., the SUPDUP-OUTPUT format messages may not be transmitted.
Greenberg [page 1]
NWG/RFC 749 BSG 26-Sep-78 13:13 45499
Telnet SUPDUP-OUTPUT Option
4. Motivation for the option.
The SUPDUP-OUTPUT protocol provides a means to access the virtual
display support provided by the SUPDUP protocol (see RFC 734) within
the context of a standard TELNET connection. This allows occasional
display-oriented programs at non-display-oriented servers to take
advantage of the standardized display support provided by SUPDUP.
This cannot be done with the standard SUPDUP protocol or the TELNET
SUPDUP option (RFC 736), for they both require that all communication
after the negotiation to use SUPDUP has been completed proceed
according to the protocol of RFC 734. This places upon the server
total responsibility for screen management for the duration of the
connection, which, by hypothesis, the non-display oriented server is
not willing to accept.
User TELNET programs at display-oriented user hosts provide local
screen management by mapping the NVT commands of TELNET into local
screen management commands; often, this involves scrolling,
end-of-page processing, line clearing etc. The SUPDUP-OUTPUT option
allows a display-oriented application program at the server side to
take over screen management explicitly, via the SUPDUP display
control repertoire. TELNET remains in effect throughout. The IAC IP
and other TELNET commands are still valid.
By means of the SUPDUP-OUTPUT option, display-oriented programs can
run on the server host, and control the user host's screen
explicitly. The user TELNET process sends a description of the user
terminal (as specified in RFC 734) to the server TELNET process as a
subnegiotiation block when the SUPDUP-OUTPUT negotiation has been
successfully completed. The server TELNET process sends explicit
screen control commands via subnegotiation blocks to the user TELNET
process.
5. Description of the option.
The SUPDUP-OUTPUT protocol may only be initiated by the server TELNET
process. A server TELNET process wishing to take advantage of the
SUPDUP-OUTPUT protocol will initiate a negotiation for it by sending
IAC WILL SUPDUP-OUTPUT. The user TELNET process must accept or
refuse the offer by sending IAC DO SUPDUP-OUTPUT or IAC DON'T
SUPDUP-OUTPUT.
If the user TELNET process agrees to support the SUPDUP-OUTPUT
option, it must follow the sending of IAC DO SUPDUP-OUTPUT
immediately with a description of the user's terminal. This
information is described in RFC 734 as the "terminal parameters." It
is to be sent as a series of six-bit bytes, one byte per eight-bit
Greenberg [page 2]
NWG/RFC 749 BSG 26-Sep-78 13:13 45499
Telnet SUPDUP-OUTPUT Option
TELNET data byte. These words may or may not contain the optional
line speed and graphics capabilities parameters described by RFC 747;
the first six bytes specify the count of 36-bit words to follow as
described by RFC 734.
The terminal parameter block will be sent as a subnegotiation of the
SUPDUP-OUTPUT option:
IAC SB SUPDUP-OUTPUT 1 byte1 byte2 ... byten IAC SE
The byte of "1" is a command code, for compatibility with future
extensions. Upon receipt of the terminal parameter block from the
user TELNET process, the server TELNET process may send SUPDUP-OUTPUT
blocks as described below.
The server TELNET process can specify explicit control of the user
host's screen by the sending of subnegotiation blocks of the
SUPDUP-OUTPUT option. The format of such a block, as seen in
eight-bit TELNET data bytes, is:
IAC SB SUPDUP-OUTPUT 2 N TD1 TD2 TD3 ... TDn SCx SCy IAC SE
The byte of "2" is a command code, for compatibility with future
extensions. The TDm bytes are the "%TDCODEs" and printing characters
of SUPDUP output of RFC 734. N is a byte containing a count of the
number of TDm's in this transmission. N may be zero, and may not be
greater than 254 (decimal). SCx and SCy are two bytes specifying the
anticipated horizontal and vertical (respectively) coordinates of the
cursor of the user host's screen after the latter has interpreted all
the %TDCODEs in this transmission.
The motivation for the SCx SCy screen position specification is to
allow hosts running the ITS operating system, which will transmit the
TDCODEs directly into the local output system, to assert the "main
program level" screen position without any interpretation of the
transmitted TDCODE sequence by the user TELNET program.
The user TELNET process must manage the position of the local cursor
with respect to standard TELNET NVT commands and output, and SUPDUP
OUTPUT transmissions. The user TELNET process may assume that the
server TELNET process is managing both NVT and SUPDUP-OUTPUT output
in an integrated way.
The SUPDUP-OUTPUT option makes no statement about how input is sent;
this may be negotiated via other options. By default, NVT input will
be used. The user-to-server screen management commands of RFC 734
are NOT implicitly handled by IAC WILL SUPDUP-OUTPUT.
Greenberg [page 3]
NWG/RFC 749 BSG 26-Sep-78 13:13 45499
Telnet SUPDUP-OUTPUT Option
In the absence of the transmission of SUPDUP-OUTPUT subnegotiation
blocks, a TELNET connection operating with the SUPDUP-OUTPUT option
in effect is indistinguishable from a normal TELNET connection. Thus
IAC WON'T SUPDUP-OUTPUT is highly optional, and if received by the
user TELNET process, should only be used to cause a diagnostic if
SUPDUP-OUTPUT subnegotiation blocks are subsequently received. If
received, the user TELNET process should respond with IAC DON'T
SUPDUP OUTPUT.
Because of the optional nature of IAC WON'T SUPDUP-OUTPUT, the user
TELNET process should be prepared to send the terminal parameter
subnegotiation block each time IAC WILL SUPDUP-OUTPUT is received,
i.e., even if the user TELNET process believes SUPDUP-OUTPUT to be in
effect.
The %TDORS (output reset) code may not be sent in a SUPDUP-OUTPUT
transmission. The user TELNET program may assume that no byte in a
subnegotiation block will be 255 (decimal).
No multi-byte TDCODE sequence (e.g., %TDMOV, %TDILP) may be split
across SUPDUP-OUTPUT subnegotiation blocks.
References:
Crispin, Mark:
"SUPDUP Display Protocol", RFC 734, 7 October 1977, NIC 44213.
Crispin, Mark:
"TELNET SUPDUP Option", RFC 736, 31 October 1977, NIC 44213.
Crispin, Mark:
"Recent Extensions to the SUPDUP Protocol", RFC 747, 21 March
1978, NIC 44015.
Greenberg [page 4]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/
