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
