Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!ames!ucbcad!ucbvax!CS.UTAH.EDU!haas%gr
From: haas%gr@CS.UTAH.EDU (Walt Haas)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: RCTE
Message-ID: <8710021819.AA14527@gr.utah.edu>
Date: Fri, 2-Oct-87 14:19:47 EDT
Article-I.D.: gr.8710021819.AA14527
Posted: Fri Oct  2 14:19:47 1987
Date-Received: Tue, 6-Oct-87 05:43:37 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 39

I've been following the discussion about TELNET echoing with some interest.
The problem has long since been solved in the big (public) network world.
A good example of how the solution works is represented by my X.25
implementation for the DEC-20 (RIP, sigh...).  There were two cases worth
distinguishing:

1) Minimum packet charge.  In this case the PAD which was connected to the
   user's terminal did echoing of characters, and forwarded a packet only
   when there were enough characters to fill one, OR the user entered a
   transmission character, OR the user didn't type anything for a while.
   In this case the TOPS-20 system was set for page mode, half duplex
   operation.  The PAD grabbed ^Q/^S to use for terminal flow control.

2) Screen editting.  In this case characters were echoed by the host.
   The PAD forwarded soon after each character was keyed in.  The TOPS-20
   system was set for full duplex, and passed ^Q/^S thru transparently to
   the applicateion (usually EMACS or some such).

I wrote a little command which switched between the two modes by sending
an X.29 packet from host to PAD and, at the same time, switching terminal
modes inside TOPS-20.  With just a little more work this sequence could
have been built into EMACS.

So how did it work?  Great!  I had the pleasure of sitting in New York
running EMACS on UTAH-20 over Telenet, with good response.  Then I could
quickly switch back to mode 1 (the default) for normal TOPS-20 command
processing.

One of the reasons this is hard to do with TELNET is that the TELNET
standard is worded in such a way that you don't have to implement these
functions in order to say you have a standard TELNET implementation.
The CCITT standard for PADs, in contrast, requires that you actually
implement a lot of functionality before you can say you conform.

----------------*
Cheers  -- Walt     ARPA: haas@cs.utah.edu     uucp: ...utah-cs!haas

DISCLAIMER: If my boss knew I was using his computer to spread opinions
            like this around the net, he'd probably unplug my ter`_{~~~