Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!lll-winken!gauss.llnl.gov!casey
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Want 8-bit/256 character clean TELNET session -- is it possible?
Message-ID: <89861@lll-winken.LLNL.GOV>
Date: 21 Jan 91 21:32:56 GMT
References: <89689@lll-winken.LLNL.GOV> <89746@lll-winken.LLNL.GOV> <1991Jan21.091019.23563@erbe.se>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@gauss.llnl.gov (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 54
Nntp-Posting-Host: gauss.llnl.gov

| From: prc@erbe.se (Robert Claeson)
| 
| The "-r" flag to the Annex telnet command will open a raw TCP connection
| without the telnet protocol.

  Someone else pointed that out to me in a private response.  I had seen
the switch and had initially thought ``yes!'' But was discouraged almost
immediately when I saw all the stuff about local line editing, etc. and
realized that the connection was anything but raw.  Fortunately the
person who pointed out the Annex raw ``telnet'' mode told me that I
needed to do:

	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!  As I mentioned in a response to him (and Xylogics), I felt that
"-r" should be renamed "-l" for local line editing, etc., and that a new
"-r" should be developed (or better yet just add a command called "tcp"
since this really has absolutely nothing to do with the TELNET protocol)
that did much of the above seven lines.  (Although I don't think I would
have my proposed "tcp" command automatically disable BREAK processing
since there's really nothing I can think of to map BREAKs to in a raw TCP
connection and it would be nice to have *some* method of breaking the
connection and returning to the Annex CLI (Command Line Interpreter.)
I'm also hesitant to have it do anything about flow control, but I can
see strong arguments for disabling in-band flow control.)

  I guess I just don't see the problem with having terminal servers offer
a command like my proposed "tcp" command above.  It's certainly within
the domain of a terminal server's function in life (offering EIA-232 /
network interconnectivity.)

  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.  I think it makes much more
sense to simply offer a TCP interconnect command in terminal servers and
other systems needing it.  *BUT*, 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.  Otherwise
we'll have a bunch of different TELNET clients which offer varying
implementations of DONT_TELNET ``cleanliness'' and no one will ever have
confidence that such a connection can truly be trusted.

Casey

Casey