Telnet issues(3)

　　One complaint we have heard about the present convention for　establishing an echoing mode is about the lack of a provision to　synchronize a change of echoing mode with the user-to-server data　stream our scheme, too, is guilty on this count. John Davidson of　the University of Hawaii has documented, in RFC357, a more elaborate　echoing scheme which doesn't have this problem. We, however, feel　that it is possible to eliminate most of the trouble involved with　normal changing of echo mode at a more modest cost than that required　by the highly interactive scheme described by Davidson. We can do　this by borrowing a small piece of that scheme. The rule we would　incorporate is that whenever a party initiates a request for a change　in echo mode, it then buffers, without transmitting or processing,　all data in the user-to-server data stream until it receives an　acknowledgement, positive or negative, at which time it deals with　the buffered data in the newly negotiated mode. Since with both our　proposed and the current schemes such a request is guaranteed to be　acknowledgement, the buffering time is bounded.

　　An important aspect of this technique of eliminating the　synchronization problem is that it need not ever become part of the　official protocol. Since its operation is entirely internal to the　server or user, each may independently weigh the value of elegance　against the cost of the required code and buffer space.

　　Other options

　　Abhay Bushan has suggested to us that whether the user and server　operate line-at-a-time or character-at-a-time mode (see RFC318)　should also be a negotiated option. Further, he suggested that　whether the terminal follows the TELNET end-of-line convention or not　should also be negotiated. Thus, when a connection is opened, in　addition to being set to NO ECHO mode, the terminal would also be set　to LINE-AT-A-TIME and EOL modes. We could augment the command space　with the new commands LINE, NO LINE (CHARACTER), EOL and NO EOL　(=separate CR and LF).

　　Once started in this direction, we found several further　applications. HIDE YOUR INPUT could be made an option, as could　Davidson's echoing scheme, and even the character set to be used!

　　Consider that an APL subsystem might well want to suggest to its user　that EBCDIC be used for the connection.

　　In mentionaing that the character set could be negotiated, it was　implicit that 7-bit USASCII was the default. The possibility of　having the default be straight binary suggests itself. If we　augmented the protocol with a QUOTE character, the byte after which　were to be always interpreted as data, then codes 128-255 could be　retained as the 'TELNET command space' independently of the data mode　in use by merely prefixing all data bytes in this region with a　QUOTE. If BINARY were a permissible data mode, then it is easy to　visualize many higher level protocols, e.g., perhaps, File Transfer　and Graphics, being built on top of, and into, the TELNET protocol.

　　What we would have accomplished is to promote TELNET from being a　constrained, terminal-oriented protocol to its being a flexible,　general protocol for any type of byte oriented communication. With　such a backbone, many of the higher level protocols could be designed and implemented more quickly and less painfully -- conditions which　would undoubtedly hasten their universal acceptance and availability

　　[3].

　　Looking toward a better world of the future, we have come up with a　more compact and flexible command scheme. We'll describe it after　the next section.

　　Symmetry

　　Some of the TENEX group (in particular, Thomas, Burchfiel and　Tomlinson) have pointed out to us that although we have made the　rules for the protocol symmetrical, we have not made the meanings of　the commands symmetrical. For example, the interpretations of the　ECHO command -- 'I'll echo to you' and 'You echo to me' -- implicitly　assume that both the server and user know who is which. This is a　problem not only for server-server connections where it is not clear　which is the user, but also for user-user connections, e.g., in　linking Teletypes together, where it is not clear which is the　server.