Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!ginosko!usc!bloom-beacon!eru!luth!sunic!mcsun!ukc!reading!cf-cm!cybaswan!iiitsh
From: iiitsh@cybaswan.UUCP (Steve Hosgood)
Newsgroups: comp.mail.uucp
Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP)
Message-ID: <754@cybaswan.UUCP>
Date: 9 Oct 89 09:52:31 GMT
References: <3217@ccnysci.UUCP> <240@tabbs.UUCP> <1024@faatcrl.UUCP> <280@atti07.ATT.COM> <9745@chinet.chi.il.us>
Reply-To: iiitsh@cybaswan.UUCP (Steve Hosgood)
Organization: Institute for Industrial Information Technology
Lines: 40

In article <9745@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>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.
>>
>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.
>

I prefer Mike's plug-in approach. It would make it much easier for new improved
protocols to be designed and circulated (in this newsgroup for instance). Even
users with no source licence could pick them up and add them to his system if
it was done correctly.

A single-program-that-handles-everything is an Algol-68 style answer, in other
words a program so complex that no-one ever gets around to implementing the
whole thing - only subsets. That's what we've got now with UUCP, and we all
know the limitations. For one thing, the bigger it gets, the buggier it gets,
and in an age of network worms, that's the last thing you want!

There's no 'one way' to transfer files. It's a compromise between many
requirements, and complicated by the different types of transport medium
available. Look at (say) the different assumptions made by the 'f' and 'g'
protocols. The first assumes a pretty well error-free 7-bit transmission
medium, the second assumes only that there's 8-bit transparency, and allows
for error recovery.

There seems to be no equivalent of the 'g' protocol for 7-bit links.
Why doesn't someone go and write one? Answer - because it's
not possible to get it passed around to all the other interested UUCP users.
With a plug-together UUCP this would be much easier.  Similarly, those recent
posters suggesting protocols that do compression could be catered for with
a such a system. Just allow for a selection of plug-in compressors (separate
from the protocol managers).

Steve