RFC 749

RFC 749: Telnet SUPDUP-OUTPUT Option 🎀

okay bestie, let's start with the header stuff 💅 this is RFC 749, and it's called Telnet SUPDUP-OUTPUT Option. It's from the Network Working Group, written by Bernard Greenberg at MIT-Multics, and dated 18 September 1978. It's filed as NIC 45499. The top line also has a stamp, NWG/RFC 749 BSG 26-Sep-78 13:13 45499. The header doesn't name a category or status, and it doesn't say whether this one obsoletes or updates anything, so I'm not gonna guess 🙈

---

1. Command name and code ✨

okay so the name and code are super short 💖

SUPDUP-OUTPUT   22

2. Command meanings 🌸

these commands are the main event, so pay attention 👑 each one is a TELNET negotiation, and the sender is basically saying what it wants.

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. 🙅‍♀️

Now the subnegotiation ones 🧚

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 🍓

the default is the boring part but it matters 🥹 both of these are the same idea: SUPDUP-OUTPUT stays off unless someone turns it on.

WON'T SUPDUP-OUTPUT

DON'T SUPDUP-OUTPUT

i.e., the SUPDUP-OUTPUT format messages may not be transmitted.

4. Motivation for the option 💜

okay so why does this even exist? 🤔 SUPDUP-OUTPUT lets you use the virtual display support from SUPDUP (see RFC 734) inside a normal TELNET connection. That means a display-oriented program running on a server that isn't display-oriented can still use SUPDUP's standardized display support, but only sometimes. You literally can't do this with plain SUPDUP or with the TELNET SUPDUP option (RFC 736), because both of those need everything after the SUPDUP negotiation to follow RFC 734. That makes the server fully in charge of screen management for the whole connection, and a non-display-oriented server is NOT willing to take that on, so it's a whole no-go 🙃

User TELNET programs on display-oriented user hosts already handle screen management locally by mapping TELNET's NVT commands onto local screen commands. That usually covers scrolling, end-of-page handling, line clearing, and so on. ✨ SUPDUP-OUTPUT lets a display-oriented application on the server side take over screen management directly, using SUPDUP's display control repertoire. TELNET stays in effect the whole time, and IAC IP and the other TELNET commands are still valid. main character energy 💅

With SUPDUP-OUTPUT, display programs can run on the server and explicitly control the user host's screen. After the SUPDUP-OUTPUT negotiation succeeds, the user TELNET process sends a description of its terminal (as specified in RFC 734) to the server TELNET process, inside a subnegotiation block. After that, the server TELNET process sends explicit screen control commands to the user TELNET process through subnegotiation blocks. 🦋

5. Description of the option 🎀

okay this is the big one, so get comfy bestie 🛋️

The SUPDUP-OUTPUT protocol may only be initiated by the server TELNET process. A server TELNET process that wants to use SUPDUP-OUTPUT starts the negotiation 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 SUPDUP-OUTPUT, it must send a description of the user's terminal right after sending IAC DO SUPDUP-OUTPUT. RFC 734 calls this the "terminal parameters." They get sent as a series of six-bit bytes, with one byte per eight-bit TELNET data byte. These words may or may not include the optional line speed and graphics capabilities parameters described in RFC 747. The first six bytes give the count of 36-bit words that follow, as described in RFC 734. 🧚

The terminal parameter block gets sent as a subnegotiation of the SUPDUP-OUTPUT option:

IAC SB SUPDUP-OUTPUT 1 byte1 byte2 ... byten IAC SE

The "1" is a command code, which is there for compatibility with future extensions. Once the server TELNET process gets the terminal parameter block from the user TELNET process, it may start sending SUPDUP-OUTPUT blocks, which are described below. 🌈

The server TELNET process can take explicit control of the user host's screen by sending subnegotiation blocks of the SUPDUP-OUTPUT option. As seen in eight-bit TELNET data bytes, the format of one of these blocks is:

IAC SB SUPDUP-OUTPUT 2 N TD1 TD2 TD3 ... TDn SCx SCy IAC SE

The "2" is a command code, which is there for compatibility with future extensions. The TDm bytes are the "%TDCODEs" and printing characters of SUPDUP output from RFC 734. N is a byte holding the number of TDm's in this transmission. N may be zero, and it may not be greater than 254 (decimal). SCx and SCy are two bytes that give the expected horizontal and vertical (respectively) coordinates of the user host's screen cursor after it has interpreted all the %TDCODEs in this transmission. 🎯

Why SCx and SCy? ITS hosts send TDCODEs directly into the local output system, so this lets them set the "main program level" screen position without the user TELNET program interpreting the transmitted TDCODE sequence at all. Iconic, honestly 👑

The user TELNET process must manage the local cursor position in relation to standard TELNET NVT commands and output, and to 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 says nothing about how input is sent. That can be negotiated through 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. 🙅‍♀️

If no SUPDUP-OUTPUT subnegotiation blocks are being transmitted, a TELNET connection with the SUPDUP-OUTPUT option in effect looks exactly like a normal TELNET connection. So IAC WON'T SUPDUP-OUTPUT is highly optional. If the user TELNET process receives it, it should only be used to cause a diagnostic if SUPDUP-OUTPUT subnegotiation blocks are received afterwards. If it's received, the user TELNET process should respond with IAC DON'T SUPDUP OUTPUT. 😭

Because IAC WON'T SUPDUP-OUTPUT is optional like that, the user TELNET process should be ready to send the terminal parameter subnegotiation block every time IAC WILL SUPDUP-OUTPUT is received. That's true even if the user TELNET process thinks SUPDUP-OUTPUT is already 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 (for example %TDMOV or %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.