Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!uwmcsd1!ig!agate!ucbvax!rusvx1.rus.uni-stuttgart.dbp.de!nittmann From: nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ") Newsgroups: comp.protocols.tcp-ip Subject: historical defaults Message-ID: <113:nittmann@rusvx1.rus.uni-stuttgart.dbp.de> Date: 29 Jun 88 02:01:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 81 This is a lengthy mail on echo no echo remote local etc. and telnet. Perhaps You even do not need to read it. Just to tell, I am fully aware of char. use of vi. But what vi needs is not the remote echo but the single character TRANSMISSION. And this is just the point I wanted to go to: why not use vi together with nfs, avoid those small char. sequences ( these are not the 1 char. echoes of course), and get a more secure vi session since the buffer just being edited will survive network/host crashes due to the statelesness of nfs. The same holds for all fullscreen editors and unix likes. Naturally there will be some VMS or so who will really need character mode. Let's ask: who is the most important section. Dynamic switching of modes is also already possible: I type escape ,mode line, return, return to the session and I am in line mode. I can change it back to character mode when I really need it (for a direct vi session). To do it better on a defined special character basis is a very good extension, let's hope that the extension rfc will come in soon. The point I see is that agreed defaults are never renegotiated and sessions that do not need these quasi default modes will run with them and waste resources. Doesn't this become even more true when there is an extended option on negotiated special characters? I would say that then even less sessions need to start in dont SGA. And since special characters are negotiated there is no need for single character mode of the sending NVT. With "agreed defaults" of course I do not only mean rfc854 defaults since there is already line mode stated as default for a telnet client's NVT. To order my imprecise formulation: only those who really have a physical half duplex terminal should need a GA, not the Unix-likes nor VMS. I agree that confusion would be too big in changing that particular - and rfc854 standardized - default since the GA is purely optional. But: A standard developed - or let's call it an implementor's easyway, or a sneeked in maniere - that telnet clients start in character mode, ask for remote echo and ping pong single characters between vaxes or suns, where by the way in line mode the line editing could be easily done locally and where NVT function codes pass. (the user has of course to enter some stty statements in his .cshrc ,.login or dec/new into login.com to get the editings done at the appropriate place and ctl c's understood on the other side) Of course some telnet implementations are really clumsy in passing NVT function codes and do ask the poor user to enter the escape to return to the client's command level and enter some sort of 'send IP' or so. People who have to use some of these should be able to go into the single character transmission mode WITHOUT at the same time ask for a remote echo. So perhaps I formulate it as a request to the developers: cannot we leave alone the agreed or sneeked in standard of starting in char. mode with remote echo and return to rfc defined real standard at the start of a session. And when a user really needs a character per character transmission ( it is that what is needed for vi, not the remote echo ) do just that but do not always request at the same time a server's echo. Vi is a very good example here since vi does not just an echo but a reply to the single character entry : on some escape ...A it sends cursor control to put the cursor up, dependent on the terminal type e.g. defined in .cshrc or login.com (for edt/tpu). And if I type a colon I do not get a colon echoed in command mode but my cursor is placed into the down left corner of the vi window and then my colon and command are replicated ( to use this to distinguish it from mere echo ). What is echoed at most is a rubout sequence for the already echoed colon. So the vi case is even worse than everything You thought of: you let remotely echo Your entered character and then vi comes and does a rubout on it since we do not need that colon in the middle of the screen! Couldn't such a rubout candidate be bought cheaper by local echo? If You properly set up Your terminal definitions on both sides, vi will work without the echo and know when to reply a character with itself echoed. I know I have a difficulty with writing clearly and simple so breath freely, this is my last on that. Michael F.H. Nittmann