1 files changed, 112 insertions, 0 deletions
diff --git a/doc/rfc/rfc340.txt b/doc/rfc/rfc340.txt
new file mode 100644
index 0000000..2f4d6ff
--- /dev/null
+++ b/doc/rfc/rfc340.txt
@@ -0,0 +1,112 @@
+
+
+
+
+
+
+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]
+
+Hide Your Input:
+
+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]
+