Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!dptg!ulysses!atti07!mjm
From: mjm@atti07.ATT.COM (Michael Matthews x7776)
Newsgroups: comp.mail.uucp
Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP)
Summary: uucp protocol implementation
Message-ID: <280@atti07.ATT.COM>
Date: 2 Oct 89 20:05:31 GMT
References: <3217@ccnysci.UUCP> <240@tabbs.UUCP> <1024@faatcrl.UUCP>
Organization: AT&T International, Basking Ridge, NJ
Lines: 32

In article <1024@faatcrl.UUCP>, jimb@faatcrl.UUCP (Jim Burwell) writes:
> aris@tabbs.UUCP (Aris Stathakis) writes:
> 
> >From article <3217@ccnysci.UUCP>, by ciamac@ccnysci.UUCP (Ciamac Moallemi):
> >> Why use Zmodem?  A protocol that is a superset of Zmodem would
> >> probably be better (maybe Zmodem itself needs to be revised).  A few
> >> extra features that I can think of:
> >> 
> 
> >I think it's about time someone made a new UUCP protocol with some of these
> >features.  Especially Bi-directional transmission.  It has been done before
> 
We are using a beta uucp variant with G protocol ( ability to set block sizes to
utilized over ACCUNET, X.25 ).
It seems what is needed before uucp gets inundated with compiled in
protocols is a plug-in protocol capabilty.

Ex:
uucico -p ....

Or something to that effect, where uucp passes off actual data-passing
to another module. The hand-off would have to be spec-ed out thoroughly
and be restricted to data passing only or else security would be
compromized. Something similar to the lp spooler subsystem print dest
interface.

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.

Mike Matthews
ATT International