RFC 340

Proposed Telnet Changes

πŸ“… published May 1972, from ietf

Proposed TELNET Changes πŸŽ€

Hiya bestie! πŸ¦‹ This is RFC 340, filed under the Telnet category as NIC 9933. Tom O'Sullivan wrote it from Raytheon Company in Sudbury, Mass., and it's dated 15 May 1972. It's part of the Network Working Group crew, and it references RFC 328. It doesn't list anything it obsoletes or updates, so it's just vibing on its own. πŸ’…

The proposed change to the TELNET protocol is giving one standard protocol and dropping the idea of a minimum implementation. Honestly, that feels reasonable right now. ✨

Tom thinks both Data Types and Hide Your Input should stay, and he has reasons 🧚

Data Types

Okay so, the objection is that switching out of ASCII is an irreversible change and you lose control. 😭 Tom says this can be solved by requiring other codes to provide a way back to ASCII. Each code can have its own return code, but it might not always get used. 🫢 These other codes matter a lot for alphanumeric terminals that have special devices plugged in. Here are some cases he calls out:

  1. A Cal comp plotter attached to a teletype has logic that lets a program turn the plotter on and off. Tom believes that when it's running, it uses an 8 bit code that could clash with Telnet signals. πŸ™ˆ
  2. Numerically controlled machines are a whole vibe. They're either driven from a user terminal, or they get code prepared by a HOST computer to be punched onto the paper tape punch at a teletype. Both need an arbitrary 8 bit code. πŸ”₯
  3. Experiments run from an alphanumeric terminal, or sensor data collected through something cal-comp like, might need a full 8 bit code. 🌈

So for all of these, Tom says a transparent data type with a way to return to ASCII mode is the move. πŸ‘‘

Hide Your Input

As more and more data base systems join the network, access keys, passwords and stuff like that become way more important. πŸ” Tom says the fact that it's hard to pick the length of input to hide isn't a strong reason to drop the feature. ✨ There are possible fixes! For example, the protocol could accept length statements from the user program, the data base system, the operating system and so on. If none of those show up, it could fall back to a default length that matches what the server system expects as its optimum. Iconic solution, no cap. πŸ’–


[ This RFC was put into machine readable form for entry into the online RFC archives by BBN Corp. under the direction of Alex McKenzie. 12/96 ]
πŸ“¦ where this page comes from