[Simh] Question on telnet mantra in simh

J. David Bryan jdbryan at acm.org
Sun Nov 14 16:06:59 EST 2010


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
  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




More information about the Simh mailing list