Re: TELNET SUPPRESS LOCAL ECHO OPTION as Experimental?

[David Borman <dab at BSDI.COM>]

Dave,

> Date: Wed, 01 Jul 1998 09:12:24 +0800
> From: Dave Crocker <dcrocker at brandenburg.com>
> Subject: Re: TELNET SUPPRESS LOCAL ECHO OPTION as Experimental?
>
> At 01:15 PM 6/29/98 -0700, braden at isi.edu wrote:
> >Gosh, it has been umpteen years since I thought about this stuff,
> >but we certainly had a solution for this problem in 1975.  I
> >dimly recall that the server negotiated WILL ECHO, then didn't,
>
> This presumes the server starts the session doing the echoing, and waits
> until login in is complete before telling the client to start doing the
> echoing.  That seems like it would work just fine for the primary equipment
> (login) but not for any suppressed echoing later, since the server might
> try to take over echoing too late, after the user has already typed the
> private text and had it echoed (locally.)

That depends.  In any scheme to automatically control the echoing
of data to the users screen, the primary requirement is that the server
know when data should or shouldn't be echoed.  A well coded application
that is going to disable echoing to protect the typed data, should turn
off the echoing before presenting the prompt to the user.  In that
situation, propagation delay is not an issue because the client will
have received "WILL ECHO" before the prompt.

> The Telnet Remote Controlled Echoing and Transmission (RCTE) option that
> Postel and I wrote was designed to allow the control to move back and forth
> (well, actually it was designed to allow the server to vary instructions to
> the client to solve the above problem).  The option did not work very well,
> primarily due to synchronization problem.
>
> If someone is serious about (finally) trying to get echoing the heck off
> the net, while still properly controlling what is and is not echoed, it
> requires a pretty sophisticated mechanism to keep client and server
> synchronized, with the server telling the client what to do during
> different "phases" of the session.

We were serios about it 9 years ago with the development of the Linemode
option.  The client code is pretty easy to run on most systems.  The
server code is a bit more difficult, because it requires support from the
OS.  Specifically, the OS needs to be able to maintain tty state, while
ignoring most of it, since the client will be doing that work, (as in the
"extproc" bit in BSD systems), and the OS has to notify the telnet server
when the state of the tty changes.

The biggest problem is screen oriented applications that turn off tty
echo and turn on single character input, so that they can have full
control over the screen.  Trying to eliminate the single character
output from the application is a non-trivial task, requiring that
the application and the telnet client/server have knowledge of each
other.

			-David Borman, dab at bsdi.com