Completeness of Win32 telnet implementations

"Philip A. Prindeville" <> Thu, 08 February 1996 08:41 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa07643; 8 Feb 96 3:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07636; 8 Feb 96 3:41 EST
Received: from by CNRI.Reston.VA.US id aa02987; 8 Feb 96 3:41 EST
Received: from ( []) by (8.6.12/CRI-gate-8-2.11) with ESMTP id CAA16364; Thu, 8 Feb 1996 02:38:33 -0600
Received: (from daemon@localhost) by (8.6.12/CRI-ccm_serv-8-2.8) id CAA19247 for telnet-ietf_list@sdiv; Thu, 8 Feb 1996 02:26:32 -0600
Received: from (root@timbuk []) by (8.6.12/CRI-ccm_serv-8-2.8) with ESMTP id CAA19243 for <>; Thu, 8 Feb 1996 02:26:31 -0600
Received: from ( []) by (8.6.12/CRI-gate-8-2.11) with ESMTP id CAA15166 for <>; Thu, 8 Feb 1996 02:26:30 -0600
Received: from ( []) by (8.6.12/8.6.5) with SMTP id DAA29349 for <>; Thu, 8 Feb 1996 03:28:16 -0500
Message-ID: <>
Date: Wed, 07 Feb 1996 10:25:32 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Philip A. Prindeville" <>
Organization: Internet Consulting
X-Mailer: Mozilla 2.0GoldB1 (Win95; I)
MIME-Version: 1.0
Subject: Completeness of Win32 telnet implementations
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

After much aggravation caused by using too long the Microsoft telnet
provided as part of the Plus! package under Windows 95 (that is,
more than a week), I'm making a personal census on the abilities of
other implementations.

(For those who are curious, the poor terminal emulation was a problem,
but the *real* killer was the lack of robustness in the face of
micro-outages, ie. less than 2 minutes or transient ICMP Host
Unreachables caused by routing flaps...)

So I started trying various Shareware and Commercial telnet packages
that came with a 30 trial license, and I found that while some
implemented S/Key awareness or Window-Resized negotiation, that few
of them implemented Interrupt-Process, Abort-Output, Are-You-There,
etc.!  I was really surprised.

Aren't most of the commoner options "Internet Standard" or
"Recommended"?  Doesn't the "Host Requirements" specify what a
"complete" telnet should/must do?

I don't know what hooks the Win32 network API provides for a client
to advise the underlying protocol stack on how to react to spurious
ICMP Unreachables...  for instance an Upcall based API would allow
more flexibility in letting the Application decide how to deal with
this condition, obviously (at the cost of a "layering violation",
of course, but this isn't always a bad thing).

The MS telnet will drop a connection, even though an attempt 3
seconds later to connect will succeed.  Which tells me that they
aren't trying as hard as they could be.

Not that congestion is anything new to the Internet.

I remember when we used up all the capacity of those 64kb/s
NSFnet links and we started talking about upgrading to T1 in a
hushed air of complete awe...

The more things change, ...

So, what's my point?  If you are guilty of (sorry, poor choice
of words ;-) having written a telnet for the Win32 API, please
send me details on what you implement and how.