[Simh] Question on telnet mantra in simh
Dave
dave.g4ugm at gmail.com
Sun Nov 14 16:59:16 EST 2010
> -----Original Message-----
> From: simh-bounces at trailing-edge.com
> [mailto:simh-bounces at trailing-edge.com] 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
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
More information about the Simh
mailing list