Path: utzoo!attcan!uunet!oddjob!gargoyle!att!cbnews!mark
From: mark@cbnews.ATT.COM (Mark Horton)
Newsgroups: comp.mail.uucp
Subject: Re: UUCP Over TCP/IP (why?)
Message-ID: <687@cbnews.ATT.COM>
Date: 19 Jul 88 17:04:59 GMT
References: <908@dsacg3.UUCP> <387@comdesign.UUCP>
Reply-To: mark@cbnews.ATT.COM (Mark Horton)
Distribution: all
Organization: AT&T Bell Laboratories, Columbus
Lines: 33

In article <387@comdesign.UUCP> pst@comdesign.uucp (Paul Traina) writes:
>Pardon my ignorance,  but I'm confused about running uucp over TCP links.
>
>My question is why?

UUCP, for all its faults, does offer some features that are not in the
standard TCP/IP protocol suite.

One feature is queueing.  The ftp/rcp/rsh stuff is interactive (although
SMTP is queued.)  If the remote machine is down, ftp/rcp/rsh aren't
going to do you any good.  The uucp or uux commands allow you to just
queue the transfer and let it go over later when everything is up.

Another is sending files to somebody else.  If user a on machine x
wants to send file m to user b on machine y, with UUCP a can type
	uuto m y!b
and sometime later b will be notified by mail that a gift has arrived.
By contrast, with TCP/IP you use either FTP or rcp to transfer the file.
FTP requires that you log into the remote system, normally with a password.
Some systems set up an "anonymous" login, but that's designed for retrieving
a file from an archive, not for sending a file to somebody that asked for it.
rcp is even more restrictive; it won't work unless you have a login on
the remote machine with blanket no-password authorization.  In both cases,
the file shows up owned by the remote user for whom the local user has the
password, not the destination user.

Another issue is email.  Some users, for various reasons including upward
compatibility and lowest common denominator, really want to send their
email via a bang path a!b!c!d.  SMTP doesn't do this without a fair amount
of munging into and out of 822 format.  By using UUCP/TCP/IP you have a
quick and dirty way to give users what they expect.

	Mark