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