Fri, 28 Oct 88 11:24:47 EDT
Wow! This time everyones getting into the act! This is great, a perfect
example of how this forum should be used!
I want thank and applaud everyone who threw their hat (and nickle) into
the ring. And now for a few comments on items that I have received...
To Stuart Levy (email@example.com):
Sorry if I sounded too discouraged. I didn't quite mean to be
that bad, I mostly meant that it will probably be a while before
the manufacturers' of terminal servers get things on an even
keel about this. I suspect most of them would welcome some of
the improvements being considered.
I agree with you on both the "open" and "closed" loop flushing
mechanisims. The open-loop is implemented in many cases, but
due to the speed of the network a lot can get through before
things catch up. The closed loop is obviously the one of choice,
and I'm glad to hear that Dave Borman's group is working on it.
If I hadn't said something about the problems, I wouldn't have
heard about the work! Last year we were a cry in the wilderness,
seems like a lot of people have been thinking about telnet
improvments since that echo last rebounded. A couple of new
RFCs supports that theory!
To Dave Borman (who just received honorable mention!):
Thanks for the info! Actually I was aware of IAC IP, but it still
doesn't solve the problem of exactly what is the interrupt character?
I was trying to make the point that there needs to be a mechanisim
to update telnet clients when modifications are made on the fly.
UNIX allows ^C to be changed, other systems might not. Stuart
tells me your group is tackling this, I wasn't aware of that!
Sitting at RADC I sort of get things weeks, months, yes even years
Rob Austein (firstname.lastname@example.org):
I have to go back to studying my writing skills. I didn't mean
that the server queues up a line and then sends it. What I
did mean to say is that the old specification of telnet was designed
around the idea of line orientated systems, hence the end-of-line
sequence (<CR><LF>) which can be interpreted differently by different
I should point out that were I said UNIX treats <CR><LF> as <LF>
this applies to older UNIX systems. 4.3 was patched after last
years discussion to make it <CR>, which solved a lot of problems.
I'll get to more of this in a minute.
Charles Hedrick (email@example.com):
Charles Hedrick feels that the <CR><LF> question is probably going to
go away. This is probably the case, more so with so many people
diving into it.
Let me see if I can get a better handle on what the problem actually
was. There are still many telnet servers which want to take <CR><LF>
and make it the default end-of-line on their computer. Pre 4.3
update UNIX systems, and MULTICS systems, make this a <LF> because
that is what a normal line termination is. Not a bad choice actually.
BUT, what about getting a <CR> when you are playing with some fancy
software on the remote host?
All telnet servers should have treated <CR><NUL> as a <CR>, and
passed that on through. No problem there, except for a lot of
telnet clients that always treated (and still do) the <CR> key
as end-of-line and sent <CR><LF>. That means that many hosts
never will see a <CR> arrive on the other side of a telnet server.
4.3 just gave up on the idea and decided that end-of-line meant
use a <CR>. Which is the easiest solution. If only everybody
The negoiations proposed last year, and being reproposed (by others)
now, merely offer a way for the host to tell the client that, hey,
I want to see REAL carriage returns when the user types them.
And more power to those designing better ways to handle things like ^C, ^O.
The above is for the benifit of those persons who have not had much
idea of exactly what was being bandied about. Personally I was
glad I pried the subject open, because I was not aware of the work
being done by others. If the appropriate RFCs are written and
accepted, this should all eventually come out in the wash.
(The opinions here are of course only my own)
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:57 GMT