RFC 596

Second Thoughts on Telnet Go-Ahead 💖

Okay bestie, let's start with the title block 🎀 This is RFC 596, from the Network Working Group, written by E. Taft of PARC-MAXC (NIC 15372), dated 8 December 1973. The header doesn't list a category, and it doesn't say this RFC obsoletes or updates anything. Iconic minimalism 💅

INTRODUCTION ✨

Okay so Taft is here to object to the requirement that hosts implement the Telnet Go-Ahead (GA) command, as specified in the Telnet Protocol Specification (NIC #15372) 🧚 Her objections go in three main directions:

1. GA is esthetically unappealing, both to Taft and to lots of people she's talked to. She'll explain why 🙈
2. As the Protocol is written, GA won't really work in general. It won't do its job unless hosts make a bunch of unwarranted assumptions about how other hosts operate 💀
3. GA is basically impossible for most hosts to implement correctly in every case. She says this is definitely true for the PDP-10 operating systems she knows, which are the 10/50 and Tenex 😭

The whole point of this RFC is to push for either fully removing the GA mechanism or demoting it to a negotiated option whose default state is suppressed. Main character energy for the default 👑

TERMINOLOGY 🦋

"Half-duplex" is a two-way communication setup where data only goes one direction at a time. The receiving side isn't allowed to transmit until the sending side has explicitly let go of the path ("turned the line around") 🍓

Here's the tea: lots of people (incorrectly) use "half-duplex" and "full-duplex" to mean local and remote character echoing. That's NOT what the terms mean in this RFC 🙅‍♀️

"Reverse break" is how a computer that's connected to a terminal over a half-duplex path gets control of the path back for more typeout after it already gave it up 🔥

It's the counterpart to the "break" or "attention" mechanism. Every half-duplex terminal has that, and it's how the user takes control of the line while the computer is using it 💜

ESTHETIC OBJECTIONS TO GA 🌸

Here's the vibe check. The Telnet Protocol spec assumes (and says so right on Page 7) that the "normal" way computers and terminals talk is half-duplex, one line at a time. Historically that's kinda true, sure. But it's also obvious, both in the ARPA Network community and beyond, that things are trending toward highly interactive man-machine systems, and those are hard to build on half-duplex rules 🚀

The GA mechanism was made to solve one specific problem: switching control between computer and user for a subset of hosts that use IBM 2741 terminals or something equivalent. It's a "subset" because the problem only shows up with TIPs talking to 2741s (with reverse break). From what Taft has seen, the TIP handles turning the line around at the right moments really well. (She's been told Multics does too ✨)

So with everything trending toward interactivity, and with terminals that need GA being a small minority, she thinks we should be reluctant to clutter our protocols with kludges that are so obviously a concession to obsolete design 🙄

I have little doubt that before long somebody (if not IBM) will produce a full-duplex 2741-like terminal (indeed, perhaps it has already been done). There is an obvious need for a terminal with Selectric quality keyboard and hard-copy better suited to interactive applications (i.e. full-duplex).

Then there's the practical side 🎀 It makes zero sense for the default state of the GA option to be the one that helps the fewest hosts and terminals.

There is no question that most parties to Telnet communication will immediately negotiate to suppress GA. To do otherwise will double the amount of network traffic generated by character-at-a-time typein, and will increase it by a non-negligible amount even for a line-at-a-time typein.

It's worth keeping the number of those "necessary" option negotiations low, especially since the Network has tons of TIPs and mini-hosts 📱 Lots of those have limited resources, so they can only implement a small subset of the options. So logically, the default state of every option should be the one most hosts are willing to use 💅

WHY GA WON'T WORK 🙃

Okay, the big plot twist: a server process being "blocked on input" (as the Protocol describes it) is NOT by itself enough reason to send GA 😳

That's because the user Telnet has no control over how a "line" of information gets packaged up when it's sent to the server. That's up to the NCP, which has to follow constraints like allocation and buffering. Let's walk through an example 👀

A user types a line of text. The user's host Telnet buffers it until they signal end-of-line. Their keyboard then locks up (that's how half-duplex terminals act while the computer has control of the line) and stays locked, waiting for the server's response and the GA command that follows.

The user Telnet sends that text line over the connection. But because of insufficient allocation or other conditions, the text actually gets split into two or more separate messages. They arrive at the server host in the right order, just with some time between them ⏳

The server Telnet hands the first message's contents to the right process. That process reads the partial line and immediately blocks for more input. Right then (assuming the second message hasn't shown up yet), the server Telnet, following the Protocol, sends back a GA command 😬

The rest of the text arrives after that, and the server process might generate a big pile of output. But the GA command already unlocked the user's keyboard and blocked the computer's output. So now we're deadlocked 💀 It only gets resolved when the user notices what happened and manually gives control back to the computer.

Yes, this specific problem goes away if the Telnet protocol says the server Telnet only sends GA when the server process is blocked for input AND the most recent character passed to that process was end-of-line. BUT Taft says this fix is bad in principle, because it assumes the serving host knows too much about what counts as "end-of-line" on the using host 🙅‍♀️

Also, the Protocol (and honestly, correctly) says the user Telnet should give the user some way to signal that all buffered text should go out immediately, without end-of-line terminating it. So the server can't rely on end-of-line either way 🫶

Bottom line: in general, the server Telnet has no precise way of knowing when it should send GA commands 💔

IMPLEMENTATION PROBLEMS 🧚

The analysis above shows the problems with GA when servers and users normally operate half-duplex, one line at a time. Once you get to hosts that provide full-duplex service, like the PDP-10s and lots of other hosts on the Network, the problems get way worse 😭

This is especially true for operating systems like Tenex, which control terminal behavior so tightly that they prefer server echoing in character-at-a-time mode. That'll probably matter less once things like Remote Controlled transmission and Echoing Option are widely used. Those would let servers control echoing and break character classes in user Telnets 🌈

Even on hosts like 10/50 systems, which handle line-at-a-time users fine for most subsystems (excluding DDT and TECO, say), GA is impossible to implement correctly. There are several reasons 💅

First, some subsystems never block for terminal input. They poll for it or accept it on an interrupt basis. When there's no typein, those processes just move on to other tasks, which might produce terminal output.

Processes like these are everywhere. The user telnet, FTP, and RJE programs are all done this way by almost every host. The 10/50 also has a subsystem called OPSER, which controls multiple independent subjobs from one terminal ✨

Since these programs never block for input, the server Telnet will never send GA commands in these cases, even though the processes are ready to accept terminal input at any time 🙃

Second, processes and terminals don't necessarily have a one-to-one relationship. The Telnet Protocol spec seems to assume they do, but they don't always 🦋

For example, in Tenex, one process may be blocked waiting for terminal input while another process is generating output to that same terminal. (Those are typically parallel forks of the same job.) 👯

Third, inter-terminal links are possible. Lots of systems support them 🔗

Taft doesn't mean the special Telnet connections between a pair of NVTs made just for terminal-to-terminal communication (the ones suggested on page 9 of the Protocol specification). She means facilities like the Tenex LINK facility, where any number and any mix of local and Network terminals and processes can have their input and output streams linked together in arbitrarily complex ways. GA will fall flat on its face in that case 🤦‍♀️

It also offends her to no end that one user of an inter-terminal link would have to "manually signal that it is time for a GA to be sent over the Telnet connection" just to unblock another user's keyboard 😤

Finally, most systems let system personnel and processes broadcast important messages to all terminals (like SEND ALL on the 10/50, or NOTIFY on Tenex). Those asynchronous messages will be blocked by a half-duplex terminal that's been locked into the typein state by an earlier GA 🚨

Taft says this is such an obvious problem that she's forced to wonder how half-duplex hosts handle it even for their local terminals 🤔

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Mirsad Todorovac 5/98 ]