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