Skip to main content

2. Some Design Problems

2A. Basic Assumption​

The function of the Telnet process is to make a terminal at a user site appear over the network as logically equivalent to a terminal "directly" connected to the server site. There are a number of implications of this basic function.

i) The user should be able to cause generation of all codes which a server system terminal can generate. With respect to the Network Information Center and some other sites it would seem a reasonable requirement to have keying conventions so that the user can generate all 128 ASCII character codes as input to the network. Other sites with different character codes may require a Telnet process to provide those codes to the network.

ii) The user should be able to escape back to his local system or escape from the server process to the server system.

iii) The Telnets of line-at-a-time systems should be able to work with character-at-a-time systems and line-at-a-time systems and Telnets of character-at-a-time systems should be able to work with line-at-a-time and character-at-a-time systems.

2B. Echo Control​

We use the term echo control rather than the terms half duplex or full duplex because the Telnet connection is in reality full duplex with respect to network transmissions. Three terminal cases need to be considered.

  • Case 1 - Character-at-a-time serving site echoed
  • Case 2 - Character-at-a-time user site echoed
  • Case 3 - Line-at-a-time user site echoed

Some serving sites may be able to operate with all three cases and some convention is required to set the mode. Strictly speaking, what characters are echoed for what keys struck is of no concern to the serving site, although one would like to try to minimize differences in typescript as it appears to the user.

2C. Format Control Characters​

The format control characters of horizontal tab (HT), vertical tab (VT), form feed (FF), line feed (LF), and carriage return (CR), need to be handled in a consistent way for Cases 2 and 3 above. With Case 1 above, the situation is simplified.

2D. Network Message Boundaries​

The NCP to NCP protocol was specified with the goal of having the network message boundaries being invisible to the user processes. It would be good if this goal could be maintained, but it may be difficult with some line-at-a-time systems.

2E. An Implementation Convention​

Conventions to solve the above problems are most simply established if we assume that the character stream received from a Telnet process by the server site is entered into that point in the server monitor where character input from "directly" connected terminals is entered and output from the server process is entered into the monitor point where normal character output is entered. The server NCP receives its input at the point where normal monitor character output is obtained. In other words, the server process would obtain its input from the server monitor character buffers and send its output to these buffers rather than obtaining input directly from NCP buffers or outputting to NCP buffers.

The Telnet process, on the other hand, would obtain and send character streams directly from or to its local NCP.

Other situations exist where the user processes at both ends communicate directly with the NCP. Therefore, we would recommend that both modes of connection (user process-monitor-NCP, or user process-NCP) be available for communication between the NCP and a user process. These modes would be set under program control by the user process. The initial network convention during the login procedure and until changed by the server process would be to obtain characters from and send characters to the monitor. The server NCP communicates with the monitor also. The scheme is illustrated in Figure 1.

The motivation for such flexibility may be clearer from the discussion below.