nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ") (06/27/88)
Throwing in the following I would like to see if it is worth
being discussed:
there are two defaults in the telnet standard that are a little bit
hampering on networks since on my opinion they cause lots of
evitable network charge: go ahead and remote echo.
On my own experience most communications in interactive telnet use are
from a workstation to a mainframe computer.
The lines are full duplex as seen from the telnet side. A virtual
circuit of two phone lines or a x.25 virtual circuit look as a
full duplex line to the telnet.
So: why bother with a go ahead as a default start and not just set
SGA as a default.
The same I think holds for the remote echo. This is a very useful
option when operating over very unreliable lines to very unreliable
hosts. When communicating over a standard network which is reliable
as seen from the bottom side of telnet, and when the tcp/ip used
as a type 4 protocol would take care of resending characters if
they are lost or timed out, so why charge the already overcrowded
network ( re. the breakdowns early in '88) with those single
character echo packets.
I would guess that nowadays - in 88, not in times on NCP-->TCP
transition - most communications could easily be done with SGA
and local echo. Seen from the mainframe pespective I personnally
judge it a gigantesque waste of resources to let a multi user
mainframe echo single characters - mainframes may of course
switch that off by negotiating, as is done with SGA. The problem I
see in my experience is that some implementations heavily rely on the
defaults. When confronted with a non default negotiation at
communication start some implementations don't work
correctly. They either insist negotiating their default or
just hang waiting for a GA.
By switching the defaults - SGA and local echo - I think
we could avoid network charge - two defaults together never
would negotiate e.g. the echo since there is no reson so
they will send those silly 1 character packets.
On the other hand implementors would perhaps be oriented
to the more useful modes as is SGA. Or is there somebody
who really knows he needs the GA any more?
Perhaps this will result in a level 3 or level 4 discussion
opposed to the link level discussion on connectors.(this is OSI
terminology).
And as usual: these are my personal views.
Michael F.H.Nittmannfin@UF.MSC.UMN.EDU (Craig Finseth) (06/27/88)
Your suggestion that local echo is acceptable implies that the local host knows exactly when and how to echo locally. As of now, the local host does not know when and how to locally echo (what about display editors such as Emacs and vi?). In the latest IETF meeting (held a couple of weeks ago), there was a discussion about Telnet EXTENSIONS to handle this type of negotiation on a dynamic basis (i.e., negotiate which characters are for editing, how to handle editing, how and when to go in and out of "raw" mode, etc.) Craig A. Finseth fin@uc.msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375
hedrick@athos.rutgers.edu (Charles Hedrick) (06/27/88)
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.)
mckenzie@LABS-N.BBN.COM (Alex McKenzie) (06/28/88)
Of course, instead of the IETF inventing a new set of Telnet options, the community could consider the (shudder) ISO Virtual Terminal Protocol, which was designed to do all this. Alex McKenzie
dzoey@TERMINUS.UMD.EDU (06/29/88)
> From: Alex McKenzie <mckenzie@LABS-N.BBN.COM> > Subject: Re: historical defaults > Of course, instead of the IETF inventing a new set of Telnet options, the > community could consider the (shudder) ISO Virtual Terminal Protocol, which > was designed to do all this. I don't think the internet community would want to do this because the various profiles for VTP (a profile is similar to a set of telnet options describing how all terminal capabilities should be mapped) are still being defined at NBS. This doesn't mean that people shouldn't take an active interest in VTP, just that they probably won't want telnet to emulate it. What is interesting is that the telnet way of doing terminal negotiation (one attribute at a time) can be done with VTP, but only with the extended model, not the basic one (forgive me if my terms are fuzzy, my copy of the VTP spec is at home). It sometimes seems that the Internet and ISO picked different ends of the implementation spectrum and are now busy rushing toward each other. That's what I like about standards, there's so many to choose from :-) Joe Herman U of Md. dzoey@terminus.umd.edu
nittmann@rusvx1.rus.uni-stuttgart.dbp.de ("Michael F.H. Nittmann ") (06/29/88)
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