rfc:rfc749
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]
/home/gen.uk/domains/wiki.gen.uk/public_html/data/pages/rfc/rfc749.txt · Last modified: 1992/10/15 21:55 by 127.0.0.1