Index Journeys
RFC 328 UNKNOWN TELNET · PROPOSAL

Suggested Telnet Protocol Changes

A 1972 proposal to trim three features from the Telnet protocol, to be adopted unless people objected.

On rfc-editor.org ↗
PUBLISHED
April 1972
AUTHORS
J. Postel
STREAM
Legacy
OBJECTION DEADLINE
15 May 72
CHANGES PROPOSED
3
DOI
10.17487/RFC0328

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
Network Working Group                                 Jon Postel
Request for Comments: 328                             Computer Science
                                                      UCLA-NMC
NIC 9635                                              29 April 72
Categories: Telnet
References: RFC 328

                   Suggested Telnet Protocol Changes

    I hereby propose the following changes to the Telnet protocol.  If
no substantial negative response is received by 15 May 72 it will be
assumed that these changes are desired and should be incorporated in
any "Official Telnet Protocol".

    First I suggest that we drop the idea of a "minimum"
implementation and require a standard implementation which includes all
aspects of the protocol.

    Second I suggest that we eliminate the DATA TYPE signals.

    Third I suggest that we do away with HIDE YOUR INPUT signal.

Arguments:

    Standard Implementation:
         The idea of an accepted implementation which does not include
         whole protocol is an admission that the parts of the
         protocol left out are either not useful or not expected to be
         used, and that other mechanisms will be constructed to provide
         those functions.  Thus there should be no minimum
         implementation, but only the standard implementation which
         includes the whole protocol.

    Data Types:
         The DATA TYPE signals are supposed to allow the communicating
         processes to switch from ASCII to some other code set.  However,
         the other code sets suggested do not allow for the Telnet
         signals, and thus once the switch is made the Telnet
         protocol is no longer applicable.  There is no way to specify
         how to get back to ASCII or Telnet thus the
         conversation is "out of control".

    Hide Your Input:
         The HIDE YOUR INPUT signal is supposed to tell the user Telnet
         process to do whatever it can to hide the user's
         subsequent input.  One problem with this is determining
         how much input is to be hidden.  It is very difficult to find a
         method of hiding input which works for all combinations of
         systems and terminals, but the HIDE YOUR INPUT signal dosen't
         help in any real way.


       [ 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   ]

AI ELI5

On this page
PROBLEMThe Telnet protocol of 1972 allowed a minimal implementation and included signals that, the author argues, did not work well in practice.
MECHANISMJon Postel proposes dropping the idea of a minimum implementation, eliminating the DATA TYPE signals, and doing away with the HIDE YOUR INPUT signal, with a short reason for each.
HOW IT WAS TO BE DECIDEDThe RFC says the changes would be assumed wanted if no substantial negative response arrived by 15 May 72, and then folded into any Official Telnet Protocol.

§1The Proposal

In April 1972 Jon Postel proposed three changes to the Telnet protocol. First, drop the idea of a "minimum" implementation and require a standard implementation that covers every aspect of the protocol. Second, eliminate the DATA TYPE signals. Third, do away with the HIDE YOUR INPUT signal.

The RFC sets a deadline: if no substantial negative response is received by 15 May 72, it will be assumed that the changes are desired and should be incorporated in any "Official Telnet Protocol".

He lists three things he wants to remove from the rules and says silence will count as a yes.

§2One Standard Implementation

The argument against a minimum implementation is about what it admits. An accepted implementation that leaves out part of the protocol is, the RFC says, an admission that the omitted parts are either not useful or not expected to be used, and that other mechanisms will be built to provide those functions.

So there should be no minimum implementation, only the standard implementation that includes the whole protocol.

If a game lets you skip half the rules, then those rules probably were not needed. So either keep them all or drop them.

§3Dropping DATA TYPE and HIDE YOUR INPUT

The DATA TYPE signals were meant to let the two communicating processes switch from ASCII to some other code set. The RFC objects that the other suggested code sets do not allow for the Telnet signals, so once the switch is made Telnet no longer applies. There is no way to specify how to get back to ASCII or Telnet, so the conversation is "out of control".

The HIDE YOUR INPUT signal was supposed to tell the user Telnet process to hide the user's subsequent input. The RFC points out that it is hard to determine how much input is to be hidden, and hard to find a hiding method that works for every combination of systems and terminals. The signal does not help in any real way.

One button switches to a language that has no way to switch back. Another button says "hide what I type" but cannot say for how long or how.