Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!swrinde!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news
From: help@kendra.kew.com (Drew Derbyshire - UUPC/extended Help Desk)
Newsgroups: comp.mail.uucp
Subject: A Description - But is it right? (was Re: Needed: Description of UUCP "g" protocol)
Message-ID: <1990Sep7.023857.1974@sun.soe.clarkson.edu>
Date: 7 Sep 90 02:38:57 GMT
References: <1990Sep6.120027.15972@sun.soe.clarkson.edu>
Sender: ahd@clutx.clarkson.edu (Drew Derbyshire)
Reply-To: help@kendra.kew.com (Drew Derbyshire - UUPC/extended Help Desk)
Organization: Clarkson University, Potsdam, NY
Lines: 23

From article <1990Sep6.120027.15972@sun.soe.clarkson.edu>, by help@kendra.kew.com (Drew Derbyshire - UUPC/extended Help Desk):
> The title says it all; I have to hunt bugs in the UUPC/extended file
> transfer code, and I have NO idea of how the "g" protocol works after
> the exchange of host names.

I received within a minutes the old posting of the description of the
initial handshake description and G.L. Chesson's Bell Labs paper on the
"g" protocol.  (Thanks Mark!)

However, in reading it and comparing it to UUCP (and UUPC, which I don't
trust as much), the initial description of the six byte control packet
looks wrong (it says the third byte should be the same as fifth byte,
and the fourth byte should be zero, which is clearly not the case for
the systems I connect to).  This, alas, makes entire paper suspect.

Any suggestions as who or what would be wrong?


Drew Derbyshire

Internet:  help@kendra.kew.com           Snail mail:  108 Decatur St, Apt 9
Voice:     617-641-3739                               Arlington, MA 02174