Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!MATHOM.CISCO.COM!BILLW
From: BILLW@MATHOM.CISCO.COM (William Westfield)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  TELNET Buffering Woes
Message-ID: <12490874186.48.BILLW@MATHOM.CISCO.COM>
Date: 2 May 89 21:41:11 GMT
References: <8905021526.AA03195@oliver.cray.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 29

Dave Borman says:

    The problem here is not with the remote machine, but with the local
    telnet implementation.  The way that things should work is:
	    User types ^C
	    Local telnet translates that to, and sends, IAC IP,
		    and then sends IAC DO TIMING-MARK and begins to
		    flush all output.
	    Local telnet receives IAC WILL/WONT TIMING-MARK, and
		    resumes terminal output.

This would work just great except when you are talking to an ITS system
and running EMACS, in which case you want ^C to be passed transparently
through the connection, so that it means "control-meta".  Or when you
are trying to upload a file using the MODEM2 protocol, or etc, etc
This is why the "Telnet Line Mode" specificaion (soon to be an RFC) is
so important - it lets you negotiate which characters are special, and
exactly how they behave, and it lets you turn things on and off...

On the brighter side, I have heard that the "skid" on terminals connected
to properly behaving, well implemented terminal servers/unix hosts is
typically less than 1/2 screenfull.  Unfortunately, properly operating
terminal servers are rare, and properly oeprating hosts are even more
rare. (The case that seems to work well is a cisco terminal server talking
to the rutgers kernal based telnet on a pyramid...)

Bill Westfield
cisco Systems.
-------