Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!romain
From: romain@pyramid.pyramid.com (Romain Kang)
Newsgroups: comp.org.usenix
Subject: Re: USENIX Board Studies UUCP
Keywords: protocols
Message-ID: <92074@pyramid.pyramid.com>
Date: 22 Nov 89 18:08:07 GMT
References: <287@usenix.UUCP> <1624@crdos1.crd.ge.COM> <1989Nov16.182104.23746@utzoo.uucp>
Reply-To: romain@pyramid.pyramid.com (Romain Kang)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 21

Questions of cost aside, before anyone seriously considers ACSNet, they
should ask the Australians what they think of it.  Certainly it has
technical merit, but the sample of 1 that I have taken considers ACSNet
administration even more inscrutable than pre-Nutshell-documented UUCP,
and an order of magnitude more time-consuming.  (Incidentally, I do not
believe a judicious fee will deter users if they gain clearly superior
service; witness UUNET.)

If someone actually writes something from scratch, it would be best to
offer a protocol that is a) robust, and b) utilizes maximum bandwidth
over both full and half duplex links.  'g' protocol looses on both
counts.  (There's supposedly a BTL memo somewhere that explains why 'g'
happens to work as well as it does in the real world; if anyone can
tell me where to find it, I'm sure it would make great bedtime
reading).  Likewise, SLIP is not engineered for hostile environments,
and it has been already pointed out that the traditional TCP suite
(SMTP, FTP, and NNTP) requires unacceptable dead time.

Do we agree that backward compatibility with UUCP is merely a frill?
After all, most people will continue to receive it as part of their
UNIX systems for the foreseeable future.