3. Proposed Telnet Conventions

3A.

The server site is to assume initially that echoing is performed by a user site process until explicitly commanded otherwise. If the user site can send character-at-a-time, then after connection and login have been established, the user could switch to server-site-echo by command to the server site and then command (invisible to the server site) his local Telnet to change its echo mode also.

3B.

The server process is to assume it will receive the same character set which terminals "directly" connected to it can generate. (We recommend at least 128 character ASCII.) The user's Telnet may have to recognize two-character sequences to enable generation of both upper and lower-case codes and the control codes. We recommend that the user be able to set either upper or lower case as the default case for single case terminals and be able to specify a case shift character. The user should also be able to specify a character to indicate that the next character struck is to be converted to the appropriate control character code. This latter convention enables control codes directly generated at the terminal to be recognized by the user's system thus enabling escape to the user system. Creating a convention allowing all control codes to enter the network and allowing output of the network to feed into the server monitor before entering the server process, gives a simple mechanism for generating an escape to many existing systems. (The problem is more complicated than this for some systems and we discuss it further below.)

3C.

We recommend that network standards be established for the meaning of local echoes of HT, VT, and FF or a convention to be established for sending the meaning of these characters to the server process. The NLS(NIC), for example, needs to keep track of the position of the print head and in the absence of such conventions will convert these character codes to spaces and line feeds. This means that the appearance of the page on output may differ from the appearance on input. It would be helpful to the user if his page on output could be formatted as it appeared on input.

3D.

LF characters would be handled as if they were generated by hitting the line feed key on a terminal "directly" connected to the server system.

3E.

The carriage return (CR) character can be the source of considerable difficulty. For example, on input, different systems and the same system at different times, can echo and transmit different codes to the terminal and the user process. Some monitor systems echo nothing, just a CR, or a CRLF. Some systems transmit a CR, CRLF, or end of line code (EOL) to the user process. The user process may control the echo or add to it. Given the combinations which can exist at each end of the network connection and with respect to each other, confusion can exist unless we assume the definition of 2A and the implementation convention of 2E. These assumptions imply that when a CR is struck, a CR gets sent over the network. If the user monitor system or terminal control hardware converts a CR to a CRLF or EOL, then the Telnet program must convert it back to a CR. When the CR reaches the server monitor it will handle it properly for the server process.

When echoing is handled by the server system, the proper code or codes will be echoed. The user Telnet on receiving a CRLF can pad it with the proper nulls to handle carriage movement timing for a particular terminal.

When echoing is handled by the user system it would be ideal if the user's Telnet or system used the same echo convention as the server system would. This means that either the Telnet must have a table of echo conventions for the various systems to which it can connect, or that it can obtain this information from the server system or process, or vice versa.

For an initial Telnet protocol this is probably not necessary. The user system can default and echo a CRLF on each CR received. This default should be satisfactory for all the situations we are familiar with and for the NIC.

3F.

For communication from character- and line-at-a-time systems, the Telnet process may need to recognize a character (user assignable) which we call end of stream (EOS). This character is to have the function defined in the following discussion. The important point is to distinguish end-of-stream as a network function and end-of-line as a user or server system function. Consider line-at-a-time systems first. We have not had much experience with line-at-a-time systems, so what follows will need further study and clarification. As we understand it, line-at-a-time systems recognize a character such as CR or a break signal as the code to wake up the user process and cause transmission to it of the line of text. From the point of view of NLS(NIC) it is important that the user be able to enter lines of text each terminated by a CR where appropriate and at other times to be able to enter text not terminated with a CR. (A statement for NLS(NIC) is a string of text of "arbitrary" length and need not have CRs in it; on output the line is folded for the user at his (user definable) page boundary.)

As an example of what is required, consider the case where the user's system recognizes CR as end-of-line. In this case the Telnet would be awakened when a CR is received. We would recommend that in this case the CR code be literally entered into the Telnet output buffer. If a CR is preceded by an EOS character, then the CR should not be placed in the Telnet output buffer. Transmission through the network can take place either when an EOS is received or automatically when the Telnet output buffer fills. Transmission to character-at-a-time systems from line-at-a-time systems could require the awkward striking of three keys to get one character through the network.

Now consider transmission for a character-at-a-time system to a server line-at-a-time system. A similar problem to the one to be described also exists between line-at-a-time systems. Given the definition of an EOS character different from CR, a line can be buffered up until the EOS is received and then sent without the EOS. How is the serving system to know that a line has been sent? One way would be for the serving NCP to recognize message boundaries. This convention would violate a design goal. Another way would be for the user Telnet to request its NCP to send an INS command. The sending of INS type of control commands might introduce race conditions in the network and should be investigated before their use with a Telnet process is established. Since some of the line-at-a-time systems we know have special hardware that recognizes the end-of-line signal, we need some way to be compatible with this hardware using software control signals. We leave this problem for further NWG subgroup study.

3G.

We now come back to the problem of interrupting or escaping in the remote server system. In systems which do not lock out the input keyboard when output is going on, the mechanisms and conventions outlined above would seem adequate unless a special break signal is the escape signal. This latter case requires more study. In systems which allow no input while output is occurring, one may have to live with the consequences of such a terminal discipline and be prepared to wait until output stops before an escape code can be sent. If the keyboard is locked and an escape break signal can be sent to the user's system, it can prevent output from going to the terminal, but must be prepared to continue receiving it from the server site until the user can inform his Telnet process to send an interrupt or escape signal to the server site. Again this is a problem for further study.

The Online System of the Network Information Center operates on a character-at-a-time monitor system and the conventions established in this paper are adequate for access to it. These conventions are summarized in Appendix A.