🚀 go-pugleaf

> On 30 Nov 89 19:26:00 GMT, 01659@AECLCR.BITNET (Greg Csullog) said:

GC> The ONLY Kermit I trust is UNITERM's so WHAT problems are there?

I too like and trust Uniterm, but there is a small, subtle bug in the
8th bit quoting negotiation.  Here is a copy of the message I tried to
send to Simon Poole:

---------------------------------------------------------------------------
Date: Mon, 31 Jul 89 13:03:36 EST
From: jmberkley
Subject: Uniterm Kermit and 8th bit quoting negotiation

I'm having trouble with Uniterm and 8th bit quoting.  When Uniterm and
Ckermit negotiate, the transfer does not correctly go into 8th bit
quoting.  I asked Frank da Cruz for advice and debugging assistance.
A summary of his reply is printed below.

The problem seems to be that Uniterm says '&' for 8th bit quoting, and
Ckermit replies with 'Y' (meaning yes I'll do it).  But Uniterm takes
the 'Y' to be the 8th bit quoting character (!).  The 'Y' reply by
Ckermit is documented in the kermit protocol manual from Columbia.

If I set the 8th bit quoting character to be 'Y' in Uniterm, then 8th
bit quoting is properly and successfully performed.

I am using the latest version of Uniterm from cs.orst.edu (sorry, but
I cannot remember the version number right now) and Ckermit 4F(085).

Thank you

 Mike Berkley, University of Waterloo
 PAMI Lab
 jmberkley@watnext.waterloo.edu
 {utai,uunet}!watmath!watnext!jmberkley

-------------------------------------------------------------------------
On Wed, 19 Jul 1989 12:44:01 EDT,Frank da Cruz
<fdc@watsun.cc.columbia.edu> said:

FdC> I checked 8th bit quoting between C-Kermit 4F(085) and MS-Kermit
FdC> 2.32/A.  These two function perfectly together -- 8th-bit
FdC> prefixing is negotiated correctly, and binary files are uploaded
FdC> from the PC to Unix correctly.

FdC> I looked at the packet log.  There are only a few "&" characters
FdC> inside the data packets (well under 50), whereas the file is
FdC> about 14K long.  In an average binary file, you would expect to
FdC> find 50% of the characters with their 8th bits on, in this case
FdC> about 7000.  This would indicate to me that Uniterm is not doing
FdC> 8th-bit quoting.

FdC> It appears that although Uniterm is putting the right things
FdC> about negotiating 8th-bit-prefixing in its S-packet, that it is
FdC> not following through with this during the data transfer.  The
FdC> protocol says that if one side says "&" (as Uniterm did) and the
FdC> other side says "Y" (yes, as C-Kermit did), then 8th-bit
FdC> prefixing will be used.  Apparently, it was not.