Proposed Telnet Changes

　　Network Working Group Tom O'Sullivan

　　Request for Comments: 340 Raytheon Company

　　NIC 9933 Sudbury, Mass.

　　Categories: Telnet

　　References: RFC32815 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.

　　As more and more use of data base systems in the network is　considered, the need for and importance of using accesskeys,　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 RFCwas put into machine readable form for entry ]

　　[ into the online RFCarchives by BBN Corp. under the ]

　　[ direction of Alex McKenzie. 12/96 ]