Telnet SGA: Telnet Suppress Go Ahead Option
Lets Telnet peers agree to omit Go Ahead signals on one or both data directions.
Postel, J. and J. Reynolds, "Telnet Suppress Go Ahead Option", STD 29, RFC 858, DOI 10.17487/RFC0858, May 1983, <https://www.rfc-editor.org/info/rfc858>.
@misc{rfc858,
series = {Request for Comments},
number = 858,
howpublished = {RFC 858},
publisher = {RFC Editor},
doi = {10.17487/RFC0858},
url = {https://www.rfc-editor.org/info/rfc858},
author = {J. Postel and J. Reynolds},
title = {{Telnet Suppress Go Ahead Option}},
pagetotal = 2,
year = 1983,
month = may,
} RFC text
Contents
Network Working Group J. Postel
Request for Comments: 858 J. Reynolds
ISI
Obsoletes: NIC 15392 May 1983
TELNET SUPPRESS GO AHEAD OPTION
This RFC specifies a standard for the ARPA Internet community. Hosts on
the ARPA Internet are expected to adopt and implement this standard.
1. Command Name and Code
SUPPRESS-GO-AHEAD 3
2. Command Meanings
IAC WILL SUPPRESS-GO-AHEAD
The sender of this command requests permission to begin
suppressing transmission of the TELNET GO AHEAD (GA) character
when transmitting data characters, or the sender of this command
confirms it will now begin suppressing transmission of GAs with
transmitted data characters.
IAC WON'T SUPPRESS-GO-AHEAD
The sender of this command demands to begin transmitting, or to
continue transmitting, the GA character when transmitting data
characters.
IAC DO SUPPRESS-GO-AHEAD
The sender of this commannd requests that the sender of data start
suppressing GA when transmitting data, or the sender of this
command confirms that the sender of data is expected to suppress
transmission of GAs.
IAC DON'T SUPPRESSS-GO-AHEAD
The sender of this command demands that the receiver of the
command start or continue transmitting GAs when transmitting data.
3. Default
WON'T SUPPRESS-GO-AHEAD
DON'T SUPPRESS-GO-AHEAD
Go aheads are transmitted.
4. Motivation for the Option
While the NVT nominally follows a half duplex protocol complete with
a GO AHEAD signal, there is no reason why a full duplex connection
between a full duplex terminal and a host optimized to handle full
duplex terminals should be burdened with the GO AHEAD signal.
Therefore, it is desirable to have a TELNET option with which parties
involved can agree that one or the other or both should suppress
transmission of GO AHEADS.
5. Description of the Option
When the SUPPRESS-GO-AHEAD option is in effect on the connection
between a sender of data and the receiver of the data, the sender
need not transmit GAs.
It seems probable that the parties to the TELNET connection will
suppress GO AHEAD in both directions of the TELNET connection if GO
AHEAD is suppressed at all; but, nonetheless, it must be suppressed
in both directions independently.
With the SUPPRESS-GO-AHEAD option in effect, the IAC GA command
should be treated as a NOP if received, although IAC GA should not
normally be sent in this mode.
6. Implementation Considerations
As the SUPRESS-GO-AHEAD option is sort of the opposite of a line at a
time mode, the sender of data which is suppressing GO AHEADs should
attempt to actually transmit characters as soon as possible (i.e.,
with minimal buffering) consistent with any other agreements which
are in effect.
In many TELNET implementations it will be desirable to couple the
SUPPRESS-GO-AHEAD option to the echo option so that when the echo
option is in effect, the SUPPRESS-GO-AHEAD option is in effect
simultaneously: both of these options will normally have to be in
effect simultaneously to effect what is commonly understood to be
character at a time echoing by the remote computer.
ISO Plain Language
On this page
§4Why Suppress Go Ahead
The Network Virtual Terminal assumes a half-duplex style of communication that uses a Go Ahead signal. A full-duplex terminal and a host designed for full-duplex use may not need this signal.
This option lets the parties agree that one end, the other end, or both ends can stop sending Go Ahead signals with their data.
Some connections can send data both ways without taking turns. The option lets them stop sending a signal that is unnecessary for that arrangement.
§2Negotiating the Option
The option is named SUPPRESS-GO-AHEAD and has code 3. WILL and DO request or confirm suppression, while WON'T and DON'T require Go Ahead signals to continue.
The default is that both ends send Go Ahead signals. Suppression applies separately to each direction, even if the peers usually enable it in both.
The peers negotiate whether each sender can omit Go Ahead signals. Unless they agree to suppression, Go Ahead signals continue to be sent.
§5Sending Data After Agreement
When suppression is active, the sender does not need to transmit Go Ahead signals. A received Go Ahead command should then be treated as a no-operation, though it should not normally be sent in this mode.
Because suppression is similar to line-at-a-time mode in reverse, a sender should try to transmit characters as soon as possible, with minimal buffering, while respecting other agreements.
Once suppression is active, data can flow without Go Ahead signals. The sender should avoid holding characters in buffers longer than necessary.
§6Working with Echo
The RFC notes that implementations may couple Suppress Go Ahead with the Echo option. Both options will normally need to be active to provide what users commonly understand as character-at-a-time remote echoing.
Remote echoing one character at a time usually needs both this option and ECHO. Each controls a different part of the interactive exchange.