Telnet issues(5)

　　We hereby volunteer to rigorously specify a version of TELNET which　embodies the principles we have described and to do so at any level　of complexity deemed sufficient by the network community.

　　Appendix: A Sample Implementation

　　The basis scheme we described represents most of what we have been　thinking about the further extensions are just that, extensions. We　fear, however, that some who are spiritually in league with us might　be frightened off by the magnitude of all the changes we suggest. To　combat this, we here provide an example of how simply and straight-　forwardly the basis scheme could be implemented for the TIP [5].

　　For each user terminal the TIP would keep three state bits: whether　the terminal echoes for itself (NO ECHO always) or not (ECHO mode　possible), whether the (human) user prefers to operate in ECHO or NO　ECHO mode, and whether the connection to this terminal is in ECHO or　NO ECHO mode. We call these three bits P(hysical), D(esired) and　A(ctual).

　　When a terminal dials up the TIP, the P-bit is set appropriately, the　D-bit is set equal to it, and the A-bit is set to NO ECHO. The P-and A-bits may be manually reset by direct commands if the user so　desires for instance, a user in Hawaii on a 'full-duplex' terminal　might know that whatever the preference of a mainland server, because　of satellite delay his terminal had better operate in NO ECHO mode --　he would direct the TIP to change his D-bit from ECHO to NO ECHO.

　　When a connection is opened from the TIP terminal to a server, the　TIP would send the server an ECHO command if the MIN (with NO ECHO　less than ECHO) of the P- and D-bits is different from the A-bit. If　a NO ECHO or ECHO arrives from the server, the TIP will set the A-bit　to the MIN of the received request, the P-bit and D-bit. If this　changes the state of the A-bit, it will send off the appropriate　acknowledgement if it does not, then the TIP will send off the　appropriate refusal if not changing meant that it had to deny the　request (i.e., the MIN of the P- and D- bits was less than the　received A- request). If while a connection is open, the TIP　terminal user changes either the P- or D-bit, the TIP will repeat the　above tests and send off an ECHO or NO ECHO, if necessary. When the　connection is closed, the TIP would reset the A-bit to NO ECHO.

　　While the TIP's implementation would not involve ECHO or NO ECHO　commands being sent to the server except when the connection is　opened or the user explicitly changes his echoing mode, we would　suppose that bigger Hosts might send these commands quite frequently.

　　For instance, if a JOSS subsystem were running, the server might put　the user in NO ECHO mode, but while DDT was running, the server might　put the user in ECHO mode.

　　[1] We have assumed that TELNET is defined as suggested by Jon Postel　in RFC318.

　　[2] Notice that a faulty implementation could achieve the effect of a　loop by repeatedly sending a command which has previously been　refused. We consider this a property of the implementation, not of　the scheme in general, a command which has be rejected should not be　repeated until something changes -- for instance, not until after a　different program has been started up.

　　[3] Will Crowther, with an eye towards building higher protocols upon　TELNET, has suggested that a SYNC command (not to be confused with　the existing SYNCH), and a SYNC REPLY be added to TELNET. For　example, a server might want to wait until the output buffer of a　user's terminal were empty before doing something like closing the　connection or passing the connection to another server. Although we　see no current use for the command pair, they seem to be a handy　enough building block that we recommend that they be included.

　　[4] It is perhaps appropriate to mention that most of the connections　in the network are TELNET connections, which are full duplex.

　　Wouldn't it be reasonable to make all Host/Host protocol connections　full duplex, rather than simplex? If, for some reason, one truly　needs a simplex connection, the reverse direction can always just be　ignored.

　　[5] Readers unfamiliar with the TIP may read the TIP Users Guide --　NIC 10916.

　　[This RFCwas put into machine readable form for entry]

　　[into the online RFCarchives by Helene Morin, Via Genie, 12/99]