Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!ucsd!rutgers!dptg!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.uucp
Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP)
Message-ID: <9745@chinet.chi.il.us>
Date: 4 Oct 89 19:04:54 GMT
References: <3217@ccnysci.UUCP> <240@tabbs.UUCP> <1024@faatcrl.UUCP> <280@atti07.ATT.COM>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 27

In article <280@atti07.ATT.COM> mjm@atti07.ATT.COM (Michael Matthews x7776) writes:

>It seems what is needed before uucp gets inundated with compiled in
>protocols is a plug-in protocol capabilty.
>
>Ex:
>uucico -p<my-protocol-pathname> ....

IMHO, this is exactly the *wrong* thing to do.  What we need is exactly
one protocol, but with handshake on the details of the transfer. i.e.
the first packet should contain the details of the max packet size,
max window size, required padding, legal character set for the link,
and perhaps status about where the transfer ended the last time these
machines connected.  

>I think it's pretty obvious that uucp protocol capabilty must be
>expanded but let's introduce *real* flexability instead of hacking
>the way thru a problem.

How many ways are there to transfer files?  The answer must be pretty
well known by now.  We just need a single program that handles all of
them well.  Kermit comes close, but it makes some unnesessary assumptions
that limit efficiency.  These assumptions could be avoided if the first
packet were forced into a kermit-style (printable character) exchange and
described the limitations of the link.

Les Mikesell