Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: historical defaults
Message-ID: 
Date: 27 Jun 88 15:56:10 GMT
References: <111:nittmann@rusvx1.rus.uni-stuttgart.dbp.de>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 23
To: nittmann@rusvx1.rus.uni-stuttgart.dbp.de

I agree that the telnet defaults are archaic.  However in most cases
there's going to have to be some negotiation at startup anyway (to
pass terminal type, for example).  So changing the defaults wouldn't
simplify very much, and would lead to great confusion.  Around
universities in the U.S., I think telnet is typically used with Unix
machines or DEC timesharing systems.  Both of these OS's expect
full-duplex connections.  They sometimes do things with characters
other than just echoing them.  E.g. editors like emacs move the cursor
around in response to single characters.  Even when you are not in
Emacs, there are commands for editing single lines in the normal
command scanner.  While I agree that it would be best to do as much
work locally as possible, there are few systems where you can do this
by using local echo in the sense it is defined in the telnet spec.
Since most systems these days expect various characters to trigger
special actions, in order to echo locally, the local host is going to
have to be told something about those special characters.  This means
that a new telnet option will be defined that allows the host to tell
the local system what characters are special.  Discussions are
currently going on within the Internet Engineering Taskforce about
such an option.  I think you'll see an RFC or the draft for one fairly
soon.  (Of course there are existing experimental protocols that do
this already, such as SUPDUP, and the protocol used by Encore for
their terminal servers.)