Telnet SUPDUP-Output option
A Telnet option that lets a server on an ordinary Telnet connection use SUPDUP screen control on the user's display.
Greenberg, B., "Telnet SUPDUP-Output option", RFC 749, DOI 10.17487/RFC0749, September 1978, <https://www.rfc-editor.org/info/rfc749>.
@misc{rfc749,
series = {Request for Comments},
number = 749,
howpublished = {RFC 749},
publisher = {RFC Editor},
doi = {10.17487/RFC0749},
url = {https://www.rfc-editor.org/info/rfc749},
author = {B. Greenberg},
title = {{Telnet SUPDUP-Output option}},
pagetotal = 4,
year = 1978,
month = sep,
} RFC text
Contents
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.
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
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.
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.
AI ELI5
On this page
§1Why SUPDUP-OUTPUT
The option gives access to the virtual display support of the SUPDUP protocol (RFC 734) inside a standard Telnet connection. This is not possible with the standard SUPDUP protocol or the Telnet SUPDUP option (RFC 736), because after negotiation everything follows RFC 734 and the server takes total responsibility for screen management.
With SUPDUP-OUTPUT, Telnet stays in effect, and IAC IP and other Telnet commands remain valid. A display program on the server can control the user host's screen explicitly.
Normally the computer far away just sends lines of text. This lets a program there also say exactly where to draw things on your screen.
§2Negotiation and Terminal Parameters
The option code is SUPDUP-OUTPUT 22. Only the server may initiate it, by sending IAC WILL SUPDUP-OUTPUT. The user Telnet answers IAC DO or IAC DON'T. If it agrees, it must immediately send a description of the user's terminal, the terminal parameters from RFC 734, as six-bit bytes, one per eight-bit Telnet byte.
The block is IAC SB SUPDUP-OUTPUT 1 byte1 ... byten IAC SE. The code 1 is a command code kept for future extensions. Because IAC WON'T SUPDUP-OUTPUT is highly optional, the user Telnet should be ready to resend the parameters each time it receives IAC WILL SUPDUP-OUTPUT.
First your computer describes your screen to the server, like telling a painter how big your canvas is.
§3Screen Control Blocks
The server sends IAC SB SUPDUP-OUTPUT 2 N TD1 ... TDn SCx SCy IAC SE. The TD bytes are the %TDCODEs and printing characters of SUPDUP output. N counts them, may be zero, and may not be greater than 254. SCx and SCy give the expected horizontal and vertical cursor position after the user host interprets the codes.
Restrictions: the %TDORS output reset code may not be sent, no multi-byte TDCODE sequence such as %TDMOV or %TDILP may be split across blocks, and no byte in a block will be 255. The option says nothing about input, which defaults to NVT input.
Each message says which drawing moves to make and where the pen should end up afterwards.
§4Defaults and Status
The default is WON'T SUPDUP-OUTPUT and DON'T SUPDUP-OUTPUT, so the format may not be sent. The user Telnet must keep track of the cursor across normal NVT output and SUPDUP-OUTPUT blocks, and may assume the server manages both in an integrated way. The RFC lists RFC 734, RFC 736 and RFC 747 as references.
Unless both agree, nothing special happens, and the user's side keeps track of where the cursor is.