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