RFC 513

RFC 513: Comments on the New TELNET Specs 🎀

Okay bestie, this one is a comment document, not a formal spec. 💅 Wayne Hathaway (AMES-67) wrote it on 30 May 1973 under Network Working Group, with NIC # 16444 and RFC # 513. The header doesn't list a category, and it doesn't say what it obsoletes or updates. 🦋 It's Wayne's feedback on the proposed new TELNET Protocol Specification (NIC # 15372) and TELNET Option Specification (NIC 15373).

Wayne's overall take is that the new TELNET protocol is far superior to the previous version ✨ but there are a few substantive things to change, plus some editorial fixes.

Sub-negotiations: The Big Oof 😭

Wayne thinks the most significant error is in the "Note on 'Sub-negotiations'" section of the Option Specification (page 2). The trouble comes from two statements: "Each party is presumed to be able to parse the parameter(s)" and "Finally, if parameters in an option 'subnegotiation' include a byte with a value of 255, it is not necessary to double this byte in accordance with the general TELNET IAC."

Here's the tea ☕ Those two lines assume there's only one "Telnet Interpreter" and that it handles all TELNET functions. Wayne calls that assumption "completely unwarranted but all too prevalent" 🙄 It breaks down when a TELNET "synch" arrives and the receiving NCP has to scan the input for "interesting" things. If a user process (not the "TELNET interpreter") was doing the subnegotiation, then that user process is probably the only one that knows how to read the SB parameters. The NCP would have no way to parse them. 💀

Wayne's fix is to have all subnegotiation parameters delimited at the end, maybe with the same TELNET command SB, and to make them obey all TELNET rules, including doubling IACs. 🫶 Someone might argue that the user process reading the SB should do the scanning itself, but Wayne says that burden shouldn't land on every user process. Fair point, honestly.

The fix is fairly simple to define and implement. The bigger issue is that the spec didn't properly consider "user processes": programs that aren't network standards but are just trying to get work done over the network. 🌸 Wayne wants future network standards designed with these very real user processes in mind, so the network can be as useful as it possibly can be. ✨

"Interesting" Things: Too Vague, Bestie 🙈

The second thing Wayne objects to is the "incredibly loose definition of 'interesting' things." (Side note from Wayne: words so imprecise they need quotation marks should never show up in protocol specs. Iconic, honestly. 👑)

The specs define some "interesting" things, like most TELNET commands, but then add "and perhaps other characters or character strings as well". To kill that undefined set, Wayne proposes that the set of "interesting" things contain only the DM command itself. So a TELNET "synch" would be defined as "discard all input up to and including the next DM command."

This should be fine for user-generated "interesting" things sent after the "synch", as the proposed new File Transfer Protocol Specifications lay out. 🧚 System-generated signals, like option requests, could get discarded, though, so that needs more discussion. If the recommendation that requests not be sent except when something changes is followed, then TELNET generating "interesting" things on its own (whatever that implies) should be rare, especially when users are also generating "synch"s. 🍓

Wayne also has a more positive idea: define a "synch response" (SR) TELNET command. The SR would be sent once the INS and DM had both been processed, meaning the "synch" was completely received. If a process gets an SR while it has an option request outstanding, that request has been discarded and must be repeated. 💅 User processes that carry on option negotiations would be the ones generating any "synch"s, so they can handle discarded option requests however they like.

Heads up: this assumes the TELNET process itself will never generate a spontaneous "synch". Wayne is asking for comments on that. 🙏

Another option is a "TIMING-MARK" TELNET command (see "TELNET Timing Mark Option", NIC # 16238), sent immediately after the DM of a "synch". The response to the TIMING-MARK (still to be defined) would mean the same thing as the proposed SR. ⭐

Horizontal Tabs 🦋

The last non-editorial comment is about needing a way to specify horizontal tab positions and use. It's a real nuisance when dealing with systems that normally handle tabs for local terminals. Wayne suggests this might be best handled with an appropriate option, and comments are solicited. 🌈

Editorial Comments on the TELNET Protocol Document 📝

Wayne's editorial notes refer to the TELNET Protocol document by page number.

Page 8 🌙

The parenthetical "(i.e., when a process at one end of a TELNET connection is 'blocked on input')" should either be removed or rewritten to avoid the (to Wayne) incomprehensible phrase "blocked on input." 😵‍💫 Wayne suggests "i.e., when a process at one end of a TELNET connection cannot proceed without additional input)." If examples are needed, Wayne proposes "(e.g., in the state characterized by the Multics term 'blocked on input')." Wayne also says a parallel could be drawn between the GA and the concept of a "read command" being issued to request more input.

Page 10 🫧

Wayne wants more discussion of the Abort Output (AO) command, especially the statement that it "allows a process... to run to completion... but without sending the output to the user's terminal." The problem is that nothing says when output is supposed to resume (presumably at the next system prompt character). Wayne figured AO is only meant to trigger this on systems that already provide it, but says it would be more useful if it were fully specified. 💖

Page 11 🎀

Wayne doesn't get what the example "(e.g., an over-strike)" is trying to say. An overstrike on output would suggest that both characters print in the same print position, which reduces the EC to a backspace. Wayne also wants more discussion of what EC (and EL) mean on output, if anything.

On the same page, Wayne wants the word "promptly" (which is in quotation marks) either eliminated or defined, as per the earlier aside. And the phrase "if necessary" in the last line seems unnecessary. 🙃

Page 12 🌷

Wayne's proposed redefinition of "interesting" signals would remove the middle paragraph entirely and substantially change the third paragraph. 🧩 The line "discard all characters which would have had an effect on the NVT printer" should change too, since BELL's should also be discarded. 🔔

Page 14 🍑

Wayne sees no reason why the sequence "CR NUL" is required to generate a "CR" only. Wayne also objects to "and the CR character must be avoided in other contexts." Either some supporting discussion should be added, or the restriction should be removed. ✨

---

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.             9/99 ]