Discussion of Telnet Protocol(6)

　　It should be noted that some controls are network-wide TELNET　controls, while others are specific to the ASCII Data Type. It　should be further recognized that some local control messages do　not require a corresponding network-wide code.

　　While it is recognized that even a minimum implementation of　TELNET for a using site is expected to permit the user to send any　selected ASCII string (and only that string) to the serving site,　it is not necessary for a serving site to implement a full mapping　from ASCII to local code, nor is it necessary for either the using　or serving sites to implement all control codes.

　　_Example - Using Site_

　　A minimum implementation of the TELNET protocol for the using site　would permit ignoring (and stripping) any control signals from the　serving site since they would all either require agreement or　acknowledgement (e.g., DATA TYPE, ECHO CONTROL, etc.) or can be　ignored with no particularly harmful results (e.g., reverse　break).

　　_Example - Serving Site_

　　A minimum implementation of the TELNET protocol for the serving　site could provide one for one mapping for the most important 128　serving system controls and graphic signals, and ignore all　control signals.

　　It would be helpful if a minimally implemented receiving site, when　it recognizes an incoming control signal for which appropriate　reaction is not available, could respond with X'87' (The following　not implemented at this site) and follow it with the code just　received.

　　Whenever an ASCII TELNET connection is lost, it should be assumed　that the process at the other end of the connection has been quit,　aborted, failed, etc. In this way, a minimum using site installation　can fail to implement the break and break synchronization, and have　the user rely on the using site local procedure for leaving a running　local process and returning to the supervisor to break a connection　to a remote serving site.

　　_Example_

　　User recognizes that he is caught in an output loop and wishes to　stop his user process at the serving site. The serving site　requires a break, but the using site minimum implementation has　not made it available. Even if it had, the INS was not　implemented and could not be used to unblock the input pipe.

　　Locally, the using site convention for leaving a process and　getting to supervisory level is to hit the attention key on the　2741 terminal. The user does this and is passed to the supervisor　where he signals to release the TELNET connection. The serving　site, seeing that an ASCII TELNET connection has been lost,　assumes that the user is ended either normally or abnormally.

　　Serving site cancels the user's process. The user tries again by　re-establishing the connection, logging in again, re-initiating　the process, etc.

　　Other conventions under TELNET may make quite different assumptions　about lost connections, and some may go as far as dynamic　establishing and releasing of connections.

　　The proposed TELNET ASCII implementation leaves much uncovered, but　seems to permit early simple implementation with varying levels of　capability, along with the capacity to expand in several ways to meet　others needs.

　　There is an important open question. Should a PROTOCOL such as　TELNET provide the basis for extending a system to perform functions　that go beyond the normal capacity of the local system. For example,　a local system may not provide functions such as Hold Output, Kill　Print, etc., but it could extend it for network purposes through　TELNET. If so, to what extent should such extensions be thought of　as Network-wide standards as opposed to purely local implementations.

　　Endnotes

　　[1] Please drop the (s) at the end of "character" in paragraph 3,　page 3, RFC137, NIC #6714.

　　[2] Also make note that the starting assumption in the initial　exchange between using site and serving site will be that the using　site will (if necessary) provide echo and the serving site will not.

　　[3] Note: Please change RFC#137, NIC #6714, page 4 - Code X'85' to　read Reserved.

　　[4] Please note on page 4 of RFC137that the receipt of an X'88'　should be responded with by the receiver sending a double signal,　i.e., X'88'X'88' if the new DATA TYPE can be handled.

　　[5] Cent sign

　　[This RFCwas put into machine readable form for entry]

　　[into the online RFCarchives by Lorrie Shiota, 1/02]