Connected: An Internet Encyclopedia
3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1123
Up: 3. REMOTE LOGIN -- TELNET PROTOCOL
Up: 3.2 PROTOCOL WALK-THROUGH
Prev: 3.2.1 Option Negotiation: RFC-854, pp. 2-3
Next: 3.2.3 Control Functions: RFC-854, pp. 7-8

3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858

3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858

On a host that never sends the Telnet command Go Ahead (GA), the Telnet Server MUST attempt to negotiate the Suppress Go Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or Server Telnet MUST always accept negotiation of the Suppress Go Ahead option.

When it is driving a full-duplex terminal for which GA has no meaning, a User Telnet implementation MAY ignore GA commands.

DISCUSSION:

Half-duplex ("locked-keyboard") line-at-a-time terminals for which the Go-Ahead mechanism was designed have largely disappeared from the scene. It turned out to be difficult to implement sending the Go-Ahead signal in many operating systems, even some systems that support native half-duplex terminals. The difficulty is typically that the Telnet server code does not have access to information about whether the user process is blocked awaiting input from the Telnet connection, i.e., it cannot reliably determine when to send a GA command. Therefore, most Telnet Server hosts do not send GA commands.

The effect of the rules in this section is to allow either end of a Telnet connection to veto the use of GA commands.

There is a class of half-duplex terminals that is still commercially important: "data entry terminals," which interact in a full-screen manner. However, supporting data entry terminals using the Telnet protocol does not require the Go Ahead signal; see Section 3.3.2.


Next: 3.2.3 Control Functions: RFC-854, pp. 7-8

Connected: An Internet Encyclopedia
3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858