Network Working Group Tom O'Sullivan
Request for Comments: 340 Raytheon Company
NIC 9933 Sudbury, Mass.
Categories: Telnet
References: RFC 328 15 May 1972
PROPOSED TELNET CHANGES
The proposed change to the TELNET protocol calling for one standard
- protocol and dropping the idea of minimum implementation seems
-
- reasonable at this time.
-
I suggest that both Data Types and Hide Your Input be kept for the
- following reasons:
-
Data Types:
- The objection stating that switching out of ASCII results in an
-
- irreversible change and loss of control can be met by requiring other
-
- codes to provide to a return to ASCII. Each other code may have its
-
- own return code, however, it may not always be employed. Other codes
-
- are important for alphanumeric terminals that have special devices
-
- attached. Several potential cases can be cited:
-
- 1. Cal comp plotter attached to a teletype has logic permitting a
-
program to turn the plotter on and off. When operating I believe
it uses an 8 bit code which could conflict with Telnet signals.
- 2. Numerically controlled machines, either controlled from a user
-
terminal or code prepared by a HOST computer to be punched on the
paper tape punch at a teletype way require the use of an arbitrary
8 bit code.
- 3. Experiments controlled from alphanumeric terminal or sensor data
-
collected through a cal-comp like connection may require the use
of a full 8 bit code.
- In these cases a transparent data type with a provision for a return
-
- to ASCII mode seems desirable.
-
[Page 1]
-
- As more and more use of data base systems in the network is
-
- considered, the need for and importance of using access keys,
-
- passwords, etc. grows. The fact that it is difficult to select the
-
- length of input to be hidden is not a persuasive argument. Potential
-
- solutions seem to exist, e.g. the protocol could provide for accepting
-
- length statements from the user program, data base system, operating
-
- system, etc. and in default of this, use a default length representing
-
- the server system expected optimum length.
-
[ 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 ]
[Page 2]
-