RFC 563 (rfc563) - Page 1 of 5
Comments on the RCTE Telnet option
Alternative Format: Original Text Document
Network Working Group J. Davidson
Request for Comments: 563 University of Hawaii
NIC: 18775 28 August 1973
References: RFC 357, RFC 560
Comments on the RCTE TELNET Option
RFC 560 describes a Remote Controlled Transmission and Echoing TELNET
option. Its authors provide a framework wherein a serving host may
control two aspects of TELNET communication over the (simplex) user-
to-server path.
Commands are introduced which govern
1. when (and which) characters shall be echoed by the user, and
2. when (and which) characters shall be transmitted by the
user.
Motivation for the option was based on two considerations:
1. the latency between striking and printing of a character
which is to be echoed by a remote server is disconcerting to
the human typist, and
2. character-at-a-time transmission introduces processing
inefficiencies (for IMPS, for servers, for users) and
decreases effective channel thruputs over the net.
The author feels that the RCTE description is in error (or at least
unclear [1]) in its treatment of when characters are to be
transmitted. However, discussion of the subject in the RCTE
specification is incomplete, so it is difficult to point to a
statement which is "wrong." Rather, the present objections are based
on inferences drawn from the sample TENEX interaction
Perhaps there is some misunderstanding of the original issues to
which RCTE now addresses itself.
Original Motivation for Remote Controlled Echoing (RCE)
RFC 357 (An Echoing Strategy for Satellite Links) introduced a need
for RCE for users who are separated from a service host by a
satellite link. The motivation was to lessen human frustration and
confusion; no consideration was given to resulting processing
inefficiencies or channel thruputs.
(In the remainder of this RFC, we consider character transmission
apart from echoing considerations.)
Davidson