Telnet SUPDUP-Output option(2)

　　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 RFC734as the "terminal parameters." It　is to be sent as a series of six-bit bytes, one byte per eight-bit　Greenberg 　TELNET data byte. These words may or may not contain the optional　line speed and graphics capabilities parameters described by RFC747　the first six bytes specify the count of 36-bit words to follow as　described by RFC734.

　　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 RFC734. 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 RFC734　are NOT implicitly handled by IAC WILL SUPDUP-OUTPUT.

　　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", RFC734, 7 October 1977, NIC 44213.

　　Crispin, Mark:

　　"TELNET SUPDUP Option", RFC736, 31 October 1977, NIC 44213.

　　Crispin, Mark:

　　"Recent Extensions to the SUPDUP Protocol", RFC747, 21 March

　　1978, NIC 44015.

　　Greenberg