RFC 595

Some Thoughts in Defense of the TELNET Go-Ahead 🎀

okay bestie, so this RFC is RFC 595 💅 It was written by Wayne Hathaway (AMES-67) on 12 Dec 1973, and it's listed under NIC # 20617. Its one reference is NIC # 20812, which is the thing it's replying to. It doesn't list anything it obsoletes or updates in its header, so it's a pure reply with no drama beyond that 🫶 Now let's get into it 🦋

This note is a reply to Edward Taft's "Second Thoughts on TELNET Go-Ahead" (NIC #20812) 📝 Wayne basically wants to show three things about his three main objections:

1. It's the idea of line-at-a-time systems that's giving "not pretty," not the GA mechanism itself 😭 Maybe that's valid, but there are sooo many of these systems on the net, so it's kinda academic, ngl.
2. The specified GA mechanism will actually work really well between (reasonably implemented) line-at-a-time systems, and should help a lot everywhere else too ✨
3. The GA mechanism might not be correct in every case, but it can still give big wins to line-at-a-time systems and their users 💖

Wayne's comments are arranged under the original headings from the subject RFC (NIC #20812), so we're going in order 🌸

"TECHNOLOGY" 💜

The definitions of "half-duplex" and "reverse break" are satisfactory 👑 Two points should be made about "reverse break," though. First, having reverse break on the terminal is NOT enough on its own 🙈 the operating system has to support it too. And since "support" basically means "require" here, it's not surprising that some systems just don't do it. There are systems that won't let you type through an unlocked keyboard until the user manually turns the line around, and honestly the operational problems with those are way smaller than you'd think 🤷‍♀️ Second, at least on IBM 2741's and equivalents, the line turnaround takes real time, and characters you type during it can get missed or garbled 💀 A pretty standard way systems using reverse break (TIP's included) handle this is to automatically enter a "line delete" character and start over every single time reverse break gets used while you're typing. Which, not gonna lie, can hardly be called esthetic 😩 One fix would be for the system to stop using reverse break once the user has started typing (as suggested near the end of NIC #20812), but most systems, TIP's included, don't do that 😤

Some discussion is also needed here about line-at-a-time systems (from now on abbreviated as LAAT systems) 🧚 One big reason for LAAT operation is avoiding the overhead of interrupting the CPU (and maybe the user process) for every single character typed. Instead, characters get buffered (in a controller, a front-end computer, etc.) until some "end-of-line" signal shows up, and then they're passed to the system all at once as a group 📦 This means the system is totally unaware that any typing has happened until the "end-of-line" signal is sent. A partially completed line will literally never be recognized 😭

"ESTHETIC OBJECTIONS TO GA" 🌈

From everything above, Wayne feels like you can see that it's the operating mode of a system, not the type of features its terminals have, that decides whether GA is useful 💅 For example, IBM front-ends handle Teletypes in LAAT mode, while the TIP tries to run 2741's as full-duplex devices (with something less than "a very good job at turning the line around," from Wayne's experience) 🙃

Anyway, the half-duplex/full-duplex debate could go on forever 🌀 The real problem is trying to smooth the way for users on local LAAT systems that connect to foreign systems with all kinds of different characteristics 🫶

"WHY GA WON'T WORK" 🔥

As mentioned, on LAAT systems no terminal input is recognized until the specified "end-of-line" character is entered, with the earlier characters sitting buffered in a front-end and so on 📦 This can totally be carried over into server TELNET: incoming network messages can be buffered at a very low level in the NCP while they wait for a TELNET end-of-line signal ✨ User processes that want input would stay blocked until the end-of-line comes in, instead of getting handed each character as it's read. Honestly, this is how every LAAT system Wayne is familiar with is implemented 💖 The reason is super obvious: lots of hosts keep sending single characters even on LAAT systems, which adds a big chunk of overhead 😭 And it's equally obvious that in this mode the GA mechanism works really well, in fact as well as turning the line around to unlock the keyboard of a local terminal 👑

This also brings us to what Wayne calls one of the main reasons for the GA mechanisms: the need for a scheme like the above for user TELNET's 🦋 Here's the problem. A user TELNET on a LAAT system has no required "end-of-message" signal for incoming server-generated messages, so it has to read each character as it comes in, with all the attendant overhead 😩 On top of that, the user process is forced to write each character as it arrives, since it never knows when the server is going to stop sending. On systems that support reverse break, this just results in pretty erratic terminal behavior. On systems that don't support it, the user has to manually turn the line around (which they can actually do reasonably well with "attention") 🙈 And of course, handling character-at-a-time input on a line-at-a-time system has its own significant overhead too 💀

This is what Wayne sees as the most valuable reason for the GA mechanism, as was noted in NIC#20812: it's not so much a request for input as an assurance (although not an irrevocable one) that the server is done sending output 🫶 Honestly, that's what the name means to Wayne: "go ahead, it's your turn to type, I'm through for a while." 🎀 Maybe some of the objections would ease up if this part got more emphasis? Perhaps! As an aside, the problem of spontaneous system messages that might be generated after a GA is sent isn't a major one in practice, since the user will definitely see the message as soon as they manually turn the line around (by entering their next input line) 👀 Note, though, that the spontaneous message should also have a GA after it, to serve as the "end-of-message" for the receiving NCP 💜 And if the user system supports reverse break, it can deliver the message whenever it likes 🌸

Let's keep the good vibes going into the rest of the RFC, bestie 🧚💖 (More of Wayne's thoughts on implementation problems and the proposal are coming up in the next part!)

A GRIPE OF MY OWN 😭

okay bestie, I need to vent for a sec 🙄💅. The implementation schedule for the new TELNET said July 1 was the date by which systems should accept new TELNET without causing errors. Presumably the responsible reps of basically every active network site agreed to that date 🗓️✨. My system has been on the new TELNET since early September, which is well past the allowable date 💀. And I've been forced to disable all server-generated GA's because, among other problems, TENEX "SNDMSG" doesn't work when GA's come in over the FTP TELNET control connection 😤. Turning the GA's off was literally required so I could receive any deliveries from the Network Information Center 📦. Not ideal, no cap.

This brings up three points 🎀:

1. First, I really hope service functions like the NIC plan to accept the new TELNET protocol by the January 1 implementation date 🙏💖.
2. Second, I'm responding to RFC#593 by Alex McKenzie and Jon Postel 📚. I don't think trying to use a second TCP socket for "new TELNET" is going to work, because FTP uses TELNET 🙅‍♀️. Honestly, it doesn't seem too hard to build a "compatible" TELNET that accepts either mode, and sites have had since July 1 to do exactly that 🧚. I think it's the most reasonable way to implement this, even if it makes the January 1 date impractical 🫶.
3. And third, sites should be more careful about committing to implementation schedules in the future 🦋🌈.

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