Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!MATHOM.CISCO.COM!BILLW
From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Want 8-bit/256 character clean TELNET session -- is it possible?
Message-ID: <12656013961.12.BILLW@mathom.cisco.com>
Date: 22 Jan 91 20:41:04 GMT
References: <89861@lll-winken.LLNL.GOV>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 46


    [Annex raw ``telnet'' mode requires:]

	stty -break -lbreak		# allow BREAKs to be passed through
	stty iflow none oflow none	# disable XON/XOFF processing
	stty attn undef			# disable "attention" character
	telnet -r host port		# ``TELNET'' ``raw'' to port@host
	^]toggle crmod			# turn off CRLF mapping
	^]mode remote_echo		# turn off local echoing
	^]set escape undef		# turn off escape processing


Whew!  A shining example of the superiority of a unix-compatible user
interface! :-)


    As far as Bill Westfield's proposal for a DONT_TELNET TELNET option, I
    think I have to agree that it's too much of a kludge.  TELNET was and is
    designed for *terminal* interactions with translations going on to
    convert different systems' CRLF models, etc.

Yes.  The point was that many hosts set all that up, perhaps completely
transparently, and then never do any further negotiation anyway.  These
systems would gain some efficiency in both the host and the terminal server.
In particular, I claimed that it would be much more likely to have kernal
based implementations if all they had tyo do was copy data back and forth.


    If such an option is proposed, I hope that it recommends that any
    TELNET client implementing such an option should strive to the best of
    it's ability to be fully 8-bit / 256 character transparent.  I.e.
    local client escape processing, in-band flow control and other in-band
    signals should all be disabled, etc.

Unfortunately, this brings up an interesting point - the user interface
connected to a protocol and the protocol itself should be divorced from one
another.  The ARPANet TACs used to turn off the escape characters when binary
mode was negotiated.  This prevented users from issuing all sorts of commands,
and they were not happy.  Doing this with "dont telnet" would be even more
dangerous - while a system can negotiate to turn binary mode off, once you
negotiate "don't telnet", it can never be turned on again...

Bill Westfield
cisco Systems.

-------