Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!RADC-LONEX.ARPA!jam From: jam@RADC-LONEX.ARPA Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8810281524.AA05253@radc-lonex.arpa> Date: 28 Oct 88 15:24:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 94 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 (slevy@us.msc.umn.edu): 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!): (dab%opus.cray.com@uc.msc.umn.edu): 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 late. Rob Austein (sra@xx.lcs.mit.edu): 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 () which can be interpreted differently by different host servers. I should point out that were I said UNIX treats as this applies to older UNIX systems. 4.3 was patched after last years discussion to make it , which solved a lot of problems. I'll get to more of this in a minute. Charles Hedrick (hedrick@aramis.rutgers.edu): Charles Hedrick feels that the 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 and make it the default end-of-line on their computer. Pre 4.3 update UNIX systems, and MULTICS systems, make this a because that is what a normal line termination is. Not a bad choice actually. BUT, what about getting a when you are playing with some fancy software on the remote host? All telnet servers should have treated as a , and passed that on through. No problem there, except for a lot of telnet clients that always treated (and still do) the key as end-of-line and sent . That means that many hosts never will see a 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 . Which is the easiest solution. If only everybody did it! 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. Joel (The opinions here are of course only my own)