Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!PANDA.PANDA.COM!MRC
From: MRC@PANDA.PANDA.COM (Mark Crispin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: CMU package
Message-ID: <12377413647.11.MRC@PANDA.PANDA.COM>
Date: 25 Feb 88 02:03:50 GMT
References: <331260.880224.JBVB@AI.AI.MIT.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38

I sympathize with JBVB's problem.  I've been fighting it for almost 10 years
now, both in my own code (Telnet implementations for 3 different operating
systems) and in other's code.  As far as I know, Telnet implementations
which get various of these complexities right are few and far between.
Here's my own list of Neanderthals:

 . host systems which send parity over Telnet connections.  These are
   becoming rarer over time, but there's still a few out there.

 . operating systems which can't tell the difference between a terminal
   which sends parity and one which doesn't, making it virtually impossible
   for the Telnet client to know what to do with that 8th bit.  ITS is the
   only OS I know that lets an application know that the 8th bit is
   significant.  WAITS gets partial credit for supporting this for terminals
   it recognizes under its display service.  VAX/VMS may also be a winner.
   I believe Unix flunks, as does most versions of TOPS-20 (only PANDA
   TOPS-20 has a "parity terminal" status bit).

 . Telnet servers which confuse Telnet binary state with some local concept
   of what is binary.  Tenex gets a big, red F in this (this was the infamous
   "new Telnet performance bug" of the late 70's), as do certain versions of
   Unix which associate Telnet binary with something called "raw mode."  This
   is one of the most serious problems facing Telnet application developers
   trying to do something useful with 8-bit I/O.

 . operating systems which have no way to instruct the Telnet server to get
   out of binary mode.  WAITS and PANDA versions of TOPS-20 are the only OS's
   I know of that handle this problem, which is what once a TAC user does
   @B I S he can't get out of binary mode.

 . Telnet servers which fail to double '377 (FFh for you Unix guys).  Most
   versions of TOPS-20 (except for PANDA) have this serious bug, and it's led
   to a plethoria of programs which manually double FFh.  Guess what happens
   when you try to run such programs on a PANDA system which does it right...

The most distressing part about all of this is that these bugs are ancient
bugs, that intelligent hackers have fixed years ago, but still broken versions
continue to proliferate.
-------