RFC 393

Hiii bestie 🎀 okay so this is RFC 393, titled Comments on TELNET Protocol Changes. It's by Joel M. Winett from Lincoln Laboratory (NIC 11585, LL-67), filed under the TELNET category and dated 3 October 1972. It references RFC 109, 139, 158,318, and 328, and the original doesn't list anything it obsoletes or updates 💅 Joel is basically saying "I'm objecting to two of the three TELNET changes in RFC 328 and I have my own take on the Reverse Break code" 🦋

1. Hide-your-input ✨

okay so this code was originally added to TELNET so the virtual terminal could pretend to be a real terminal with print suppress 🙈 If the terminals at some installations can't turn off their printing, the TELNET being used can either ignore the code or fake it some other way (e. g., blacking out a bunch of character positions and jumping back to the first character position). Every attempt should be made to give a network user of a time-sharing system the same facilities as a local user 🫶 The TELNET spec shouldn't limit what users can do just because not every user can support a function 😤

The "Hide-your-input" and "Echo" TELNET control codes support two functions that some time-sharing systems have 💖 "Hide-your-input" is basically a special case of "Echo" mode, where the server tells the user it will echo but it actually doesn't 💀 It gets its own code because some servers might support hiding input without supporting the full "Echo" mode, and that's lowkey iconic of them 🧚

] This material has not been reviewed for public release and is [
] intended only for use with the ARPA network. It should not be [
] quoted or cited in any publication not related to the ARPA    [
] network.                                                      [

The "Hide-your-input" and "Echo" modes are turned off with the "No-echo" control 🌸 ASCII control codes could have been picked for these functions, but it was decided that NVT ASCII control codes should only be specified for commonly used functions ✨

Now, to say how many characters should have their printing suppressed, the "Hide-your-input" control could be redefined so it's followed by a byte giving that number 🍓 The "No-echo" control would still be sent anyway, so systems with the print suppress feature wouldn't have to count characters 🫶

2. Data Types 🦋

the protocol should let a server support users with character codes other than ASCII, like EBCDIC 🌈 The definition of an alternate character code should also include the definition of the TELNET control codes. An EBCDIC code was proposed in RFC # 109 and has been implemented on the Lincoln Laboratory 360/67 💜 If you want to go back to the network standard ASCII code, the non-ASCII code should contain a code that says "return to ASCII" 👑

3. Reverse Break 🔥

the code for Break is defined as a 129th ASCII data code 🎀 It's usually sent from a user's network virtual terminal to a server when the break or attention key gets typed on the TELNET terminal, and the server reads it as that special key 💅 Since interrupting a running process is a super common thing this key does, the server has to be alerted that this code was sent no matter when it arrives 😭 So the TELNET SYNC (a TELNET data mark together with a network interrupt on the TELNET send socket) also has to be sent, to make the serving process check the characters it received ✨ The ASCII control code EOT (Octal 4) could have been used for the break function, but not every system interprets it, so it was decided that an NVT TELNET control code should be used instead 🙈

The Break Code going from server to user TELNET hasn't been defined before, so it could fix some problems that happen with line-at-a-time and half duplex systems 🧚 Line-at-a-time systems don't output characters one at a time to the terminal. They wait until a line is ready for output. If a CR-LF sequence (the TELNET protocol for end of line) is received, it's treated as the end of a line and the characters received get output. But if characters come in that don't end with CR-LF, the user TELNET doesn't know whether more characters belonging to the current line are coming ngl 😵‍💫 So the characters received so far have to be output without a CR-LF (new line). If an end of message code were sent, the user TELNET would know whether more characters were coming for output. The user TELNET could then print characters either when the TELNET Break control is received or when the CR-LF newline sequence is received 💖

If the user TELNET is running from a half duplex terminal, the terminal can't receive input and type output at the same time 💀 So if output arrives while the terminal is being used for input, the TELNET program has to either buffer the received characters or abort the input mode to write them out 🫠 If the received characters get written out as they arrive, the terminal would work very similarly to a full duplex terminal 🦋 This mode needs the terminal to have a reverse break capability, so the input mode can be aborted by program control 👑

Some systems only want to abort the input mode when a complete line is ready for output 🌸 If a string of characters received doesn't end with an end of line code, those characters won't be output until the input line is entered, which means the mode changes from input to output 💅 If an end of message code were sent, the user TELNET could abort the input mode even though the end of line code wasn't received 😤

In systems that don't support the reverse break feature, or where the terminal doesn't have it, it's not possible to abort an input mode to output received characters 🙃 In that case the system can run in one of two modes: a) unlocked keyboard, or b) locked keyboard mode 🎀

In an unlocked keyboard system, received characters aren't output until the user finishes an input line 🌈 An input line is finished when the end of line code is entered, which might be a CR, a LF, or a NL code ✨ After any received characters are output, the input mode is re-entered 💜 To receive output, the user has to enter an input line (possibly a null line) 😭 If the user is waiting for output, they have to keep entering a line until the output comes through and gets typed 🫠 Since an input line has to be entered just to receive output, it's desirable to define an input line that doesn't send anything to the serving system 🍓 If a null line (a line made of just the end of line code) is picked for this, some other input line has to be defined to cause a null line to be transmitted 🙈

In a locked keyboard system, the input mode isn't re-entered right after an input line is entered 🧚 It's only re-entered after a defined prompt is received 🔥 The prompt can be defined as the reception of any character, or as a specific character code 💅 If a specific code is picked, the serving site has to send this code whenever the terminal should go into input mode 👑 If an end of message code were transmitted, this code could be interpreted as the input prompt code 🦋

So, in summary, there are three situations where an end of message code would be desirable 🌸

• a) To indicate when a line that doesn't end with CR-LF should be output for line-at-a-time systems
• b) To indicate that the input mode in half duplex operation should be aborted so received characters can be output
• c) As a prompt character to cause the input mode to be entered for locked keyboard half duplex systems

The ASCII TELNET control code for Break (Reverse Break) could be interpreted as an end of message code when sent from server to user 💖✨

🎀 Lincoln Lab note: this RFC was put into machine readable form for entry into the online RFC archives by BBN Corp. under the direction of Alex McKenzie, 1/97 🌈

[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the   ]
[ direction of Alex McKenzie.                      1/97 ]