Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Specification of Berkeley networking utilities
Message-ID: <29743@think.UUCP>
Date: 26 Oct 88 23:06:57 GMT
References: <8810260021.aa23976@SPARK.BRL.MIL>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 46

In article <8810260021.aa23976@SPARK.BRL.MIL> phil@BRL.MIL (Phil Dykstra) writes:
>Surely you jest!  Maybe once telnet can: (1) log you in without requiring
>a password in a file, (2) handle remote window size changes, (3) handle
>OOB data for (e.g.) SIGINT output flushing, and (4) have every machine
>handle raw octet data correctly, then I'll believe you.

There's no reason why TELNET couldn't do all those things.  The TELNET
option mechanism provides nearly infinite expansion capability.

(1) A TELNET server that supports such a feature could send IAC DO
SEND-USERNAME (a new option I just made up) before sending the
"login:" prompt.  If the client supports this it will respond with IAC
WILL SEND-USERNAME and then uses the subnegotiation mechanism to send
the name.  The server would then bypass the normal login prompt and
log the user in, subject to access checks like those rlogin does.

(2) There are already standardized TELNET options for transmitting
line length and screen height.  Either these could be used or a new
window-size negotiation could be defined.

(3) TELNET already has this: IAC AO (Abort Output).  There is also an
IAC code for sending an interrupt.  Other OOB data could be
implemented using options.

(4) Again, this just needs a new option.  Actually, many
implementations interpret the TRANSMIT-BINARY negotiation as
specifying this.  This could be made official, or a new option could
be defined.

Yes, these things would require changes to TELNET implementations.
However, the effort to modify a TELNET implementation to support these
should be less than the effort to write an RLOGIN implementation from
scratch.  Of course, if you already have an RLOGIN implementation you
aren't going to be interested in modifying TELNET; even if you don't,
it's probably easier to port one than to extend TELNET.

The problem isn't that TELNET can't do what RLOGIN does, it's that
nobody bothered to define the necessary TELNET enhancements before
RLOGIN proliferated.  I think it's too late, and anyone who thinks
that RLOGIN can be phased out is dreaming.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar