Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!julius.cs.uiuc.edu!usc!elroy.jpl.nasa.gov!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: <89956@lll-winken.LLNL.GOV>
Date: 22 Jan 91 23:58:27 GMT
References: <9101220312.AA02066@ftp.com>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@gauss.llnl.gov (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 70
Nntp-Posting-Host: gauss.llnl.gov

| From: jbvb@FTP.COM (James B. Van Bokkelen)
| 
| If what you want is the ability to connect to an arbitrary remote
| host/port and send binary data fast, why is Telnet in the picture at
| all?  Just use the standard system API for TCP and blast away.  Telnet is
| intended for virtual terminal support, and isn't designed for bulk data
| transfer.  If the widget you're hacking doesn't have a TCP API, where are
| you getting the data you want to send from in the first place?

  Because I'm dealing with a terminal server whose only connection
mechanisms are RLOGIN and TELNET (actually it also supports some
proprietary protocol but that's of no import.)

  I'm only trying to do it with telnet because that's what I've got.  My
feeling is that I fundamentally agree with you.  TELNET is for terminal
interaction.

| From: billw@mathom.cisco.com (William "Chops" Westfield)
| 
|     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 to do was copy data
| back and forth.

  I don't think there's enough logic in the TELNET server side to really
provide much of an impediment to kernel implementation.  All it's got to
be able to do is acknowledge option processing and change it's behavior
in minor ways.

|     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...

  But without such a recommendation the DONT_TELNET proposed option is
going to be useless for my purposes.  Yes, I know that I could have users
explicitly unset all the client interface garbage, but I'd spend the rest
my life explaining it over, and over, and over, ...  At the very least,
let's have a *REAL* BINARY mode that specifies that the channel should be
as clear as possible, including in-band client command escapes.

  In any case, I'm now convinced that TELNET is the wrong way to do what
I'm trying to do which is simply establish a clear TCP connection between
the Annex and a remote, non-TELNET server.  It appears that I may be able
to kludge the Annex's TELNET into letting me do it, but it's not going to
be pleasant.

  I will lobby Xylogics to support a new command to implement this.
Maybe if Xylogics implements this and the CMC TranServer already has it
(see Lars Poulsen's note), other terminal server manufacturers will
implement the same functionality and it'll become common.

Casey