> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of J. David Bryan > Sent: 14 November 2010 21:07 > To: SIMH List > Subject: Re: [Simh] Question on telnet mantra in simh > > > Holger, > > > On Thursday, November 11, 2010 at 21:08, Holger Veit wrote: > > > I see: here be dragons. > > Indeed. > > > > As a non-native speaker, I have problems figuring out what was > > actually intended in RFC854/5 with the WILL/WONT and > DO/DONT pairs... > > It is not much easier for this native speaker! ;-) > > If I read RFC 854 and RFC 1143 correctly, the basic idea is: > > 1. Each side starts with the same known, basic > configuration: the Network > Virtual Terminal (NVT). > > 2. One side may offer to the other side to enable an option > with WILL. > The other side responds with DO if the offer is accepted and DON'T > if the offer is rejected. > > 3. One side may request that the other side enable an option with DO. > The other side responds with WILL if the request is accepted and > WON'T if the request is rejected. > > 4. One side may announce to the other side that it will > disable a current > option with WON'T. The other side must acknowledge the > announcement > with DON'T. > > 5. One side may demand that the other side disable a current > option with > DON'T. The other side must acknowledge the demand with WON'T. > > 6. Neither side announces the mode it is in. Only changes > of mode are > negotiated. > > 7. If a side receives a request to enter a mode it is already in, the > request is ignored. > > > > ...and it seems to me that whatever the correct intention > was, simh is > > broken anyway, beyond incompletely implementing the IAC options > > negotiation. > > Correct. > > > > In contrast to my idea of having simh report to the client what it > > does > > not like (in contrast to your #2.) simh should only tell > what it offers > > to handle, so WILL ECHO, WILL BIN, and WILL SGA appears to > be okay, but > > WILL LINEMODE is not, because simh neither wants to do LINEMODE > > suboption negotiation at all nor can it do it at all, so it > shouldn't > > announce it. > > Correct. > > > > However, if the other side would request DO LINEMODE it > should deny it > > with WONT LINEMODE. The other side is a client, though, so > should not > > DO LINEMODE at all, according to RFC1184... > > Correct. > > > > For the WILL ECHO/BIN/SGA offers, simh should accordingly react > > properly when the other side does not accept the offer. > While a WONT > > BIN from the client seems to be handled correctly, DO/DONT > BIN is not, > > and the RFC default mode ASCII is not respected. Neither does it > > respect a WONT ECHO reply to the DO ECHO it demands. > > Correct. > > > > Now, I am curious why this line is present at all. > > Arthur Krewat wrote the following to me in 2007, when I asked > that same > question: > > "Most likely because it was easier to hack something together that > worked. Some clients needed those to be offered or they'd puke - I > think they locked up in negotiation and never fully connected. > > "Solaris telnet worked with it just fine." > > > > Has there been any client relying on this, or do all > present clients > > deny this offer (which will then be dropped by simh as it > ignores what > > it does not understand)? > > The four clients that I use respond to SIMH negotiation as follows: > > Telnet client Negotiation > ==================== > ================================================ > Microsoft Telnet DONT LINEMODE, DO SGA, DO ECHO, DO > BIN, WILL BIN
It should be noted that Windows/2000 telnet behaves differently to Windows/XP Telnet as I know from my experiences with Hercules which for a time worked with w2k telnet and not with XP telnet... > Microsoft Hyperterm DONT LINEMODE, DO SGA, DO ECHO, DO > BIN, WILL BIN > Attachmate Crosstalk DONT LINEMODE, DO SGA, DO ECHO, DO BIN > AICS QCTERM DO ECHO, DO SUPPRESS LOCAL ECHO, WONT BIN > > -- Dave > > _______________________________________________ > Simh mailing list > [email protected] > http://mailman.trailing-edge.com/mailman/listinfo/simh > _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
