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