Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!ncrlnk!ncr-sd!crash!simpact!jeh
From: jeh@simpact.com
Newsgroups: comp.mail.uucp
Subject: Re: Zmodem added to UUCP
Message-ID: <682.2522121c@simpact.com>
Date: 28 Sep 89 19:44:11 GMT
References: <3602@escargot.UUCP>
Distribution: usa
Organization: Simpact Associates, San Diego CA
Lines: 55

In article <3602@escargot.UUCP>, chrisb@escargot.UUCP (Chris Bradley) writes:
>    I have spoken briefly with Chuck Forsberg himself, and he says that there
> isn't a Zmodem standard for UUCP. I would like to elect myself as "Head of
> the project", so to speak. I have come up with, what I believe to be, a
> very good extension to Zmodem. Not only is it versatile, it's very simple to
> understand. I would like to open it for debate to the net, therefore, I'm
> posting the protocol description. Please feel free to e-mail or post responses.
> Chances are there is something I have overlooked, but if you find something,
> please let me know.
>  (...)

In article <3217@ccnysci.UUCP>, ciamac@ccnysci.UUCP (Ciamac Moallemi) writes:
> 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...

Others have commented on the merits of the features suggested (bidirectional
transmission, encryption, data compression).  I will briefly add my opinions
that (a) bidirectional transmission would require a major redesign of the 
entire uucp system; (b) the bulk of uucp traffic is news and mail; it is
self-evidently ridiculous to spend a single cpu cycle to encrypt news, and 
mail encryption/decryption belongs in the mail user agent; and (c) the vast 
bulk of uucp traffic is (in my limited experience) news, which is already being 
compressed via modified Lempel-Ziv.  

But my main purpose here is to comment on the general direction of 
Mr. Moallemi's response.  

It is all too easy to listen to someone say, "gee, I'm thinking of doing A", 
and respond with "Well, that isn't really worth doing unless you also do 
A1, A2, and B, C, and D as well."  (I know it's easy, because I've done it 
myself!)  

Such a response has a high probability of discouraging the original
volunteer from doing anything at all.  This is bad.  

It is much better to encourage volunteer efforts, regardless of whether 
they will end with all of the bells and whistles you'd eventually like to
see.  And if you really feel that, for example, ...

> A good alternative would be splay tree Huffman encoding with 64 Markov
> states.  This compresses faster than 16-bit compress, performs just
> slightly worse, and uses much less memory (2k per state, 128k total).
> Systems with more memory could add more states and therefore acheive
> better compression.  Built-in logic could be added to detect
> compressed (.Z), zoo, arc, etc. files and avoid compression.
> These are just off of the top of my head....

... fine -- go forth and implement!  But don't sit back and tell others 
what they really *ought* to be doing.  

	--- Jamie Hanrahan, Simpact Associates, San Diego CA
Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG 
Internet:  jeh@simpact.com, or if that fails, jeh@crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!jeh