RFC 719

Title Block 🎀

Okay bestie, here's the vibe check first. This is RFC 719, called Discussion on RCTE ✨, written by Jon Postel (SRI-ARC) in the Network Working Group. It's dated Jul 76 (July 1976) and has NIC #36138. It doesn't list a category, and it doesn't say it obsoletes or updates anything. It's basically a group chat that happened right after RFC 718 got published 💬🦋

The Group Chat 💖

15-Jul-76 Nancy Mimno (BBN-NET) 🌸

Jon, okay so Nancy here 💅 I've read RFC718 and I have some comments, especially about the "third problem" or the clearing-the-input-buffer part 🙈

1) Ngl, I think the stated implementation is backwards 😭 In the normal case of RCTE mode negotiation, the server sends "WILL RCTE" and the user sends ,"DO RCTE". So the reverse case is the server sending "DO RCTE" and the user sending "WILL RCTE". Also, it's probably smart to say explicitly that when the server sends "DO RCTE", the user process has to respond "WILL (or WON'T) RCTE", and that this response is the synchronizing mark. It's giving clarity ✨

2) The problem is a real one 💀 I think the RCTE protocol would be better with a "clear input, reset counters" function. The question is Ill now to do it. I talked with Rav yesterday, and he had this in mind as a general function, not just for RCTE 👑 Like, TENEX sends the "reverse RCTE" option for "clear your input buffer" whether or not the connection is in RCTE mode. So the statement about "cannot be confused with the normal use of the RCTE option" won't always be true 🙈 We both agreed the current solution should just be an interim one.

3) Here's my idea 🧚 Use the synch-datamark sequence instead. First, the RCTE option would have to explicitly require that this function reset the counters and cause a "clear your input buffer (of data)", all synchronized with the datamark, obvi. This is pretty much what it is now, except for the reset counters. Receiving Synch-data mark while in RCTE probably needed defining anyhow. Because RCTE won't work unless both sides agree, the "clear input and reset counters" meaning for synch-data mark would have to be a mandatory part of the RCTE option 🔥

Second, the Synch-data mark is a "one-way" function, so there needs to be a way for one side to tell the other side to "send me a Synch-data mark". The New Telnet protocol spec implied that Abort Output could be used for that purpose. If that's hot, then maybe a new function could be defined. Again, the RCTE option should make some explicit statement requiring (or very strongLy recommending) this reading of AO. For non-RCTE mode, it's a nice idea but probably not required 🦋

Ray has tentatively agreed, and he thinks it could work on Tenex (server side) ✨ I'd like your comments, and Doug Dodds' too (he's the Tenex user RCTE person). I don't know of any other existing RCTE implementations that would have to change. I also don't know what it takes to extend official protocols these days, but maybe it's easier to do that than define a new option (ie reverse RCTE) 🌈

Regards, Nancy 💜

15-Jul-76 Doug Dodds (BBN-RCC) 🍓

Nancy, your suggestion for the RCTE-clear function being performed by the Au command (when RCTE is on) is a good one 🫶 I see no problem with it from the side of the Tenex User Telnet (NTELNET). Right now NTELNET is ignoring AO (and some other commands) entirely, so this is a great opportunity to implement it in general 🙌

Doug 💅

21-Jul-76 Jon Postel (SRI-ARC) 🌟

I met with Ray Tomlinson for a few minutes to talk about the RCTE-clear function and other RCTE features. We agreed that Nancy's suggestion for using the AO command for the clear function made sense 💯 We also figured out that the RCTE document should say something about the state some other options should be in while using RCTE.

For example, we believe that GO-AHEAD must be suppressed while RCTE is in use. When someone quits RCTE, the ECHO mode must be restored to what it was when they entered RCTE. And BINARY and RCTE don't make sense as a combo, because every byte would have to be assumed to be a break character 💀

We also decided it's unworkable to use RCTE with no break characters, since there's no way to get out of that state 😭🙈

22-Jul-76 Jon Postel (SRI-ARC) 🎀

Okay so because of all the above discussion, I'm going to prepare a revised RCTE specification document 📝 A draft will go out to interested parties for comments, and then the final document will be published as an RFC 🦋✨