Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!BU-CS.BU.EDU!bzs
From: bzs@BU-CS.BU.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Tcp/Ip vs a store & forward network
Message-ID: <8703301826.AA14541@bu-cs.bu.edu>
Date: Mon, 30-Mar-87 13:26:11 EST
Article-I.D.: bu-cs.8703301826.AA14541
Posted: Mon Mar 30 13:26:11 1987
Date-Received: Wed, 1-Apr-87 00:56:12 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 46
Approved: tcp-ip@sri-nic.arpa


>Barry,
>
>Which brings me to something I would like to get created:  FTP to spool so that
>no pswds need to make their way around the network.  If Bitnet can transfer
>files to/from Unix, VMS, VM, MVS, CDC, etc machines - WITHOUT passwords
>then Tcp/Ip should be able to send files around to local spool systems so
>that the entire concept of FTP pswds can be eliminated.
>Hank

I'm not sure there's much difference between bitnet's SENDFILE and
just sending a file via mail. Most of the differences between SENDFILE
and Bitnet/Mail (and, actually, SMTP) are simply to accommodate spool
record length restrictions within IBM's filing system. This is not
particularly a problem when an heterogeneous environment is accounted
for and files have to be in some "reasonable" ASCII text format
anyhow.

Even record length restrictions and binary images can be transferred
in more generic ways (eg. UUENCODE/UUDECODE which I've ported to my
3090) than DISKDUMP formats which appear to be limited in function and
very much designed with IBM's filing system in mind. I suppose VMS's
jnet (bitnet) product accommodates this, but I assume only by being
subservient to IBM file formats (and a very, very limited subset at
that, as far as I know there is still no way to send, eg, a PDS
between even two IBM systems via Bitnet without some user hackery.)

The other half of the difference would be accomplished by adopting
some convention that files are sent to, say, user-fxfr@host so it
appears in a different spool or just marking the header so mail user
agents could pluck out "file transfers" from the mail when they start
up. I think this is a minor need, the Subject: line can get you 98% of
the way there without changing anything.

The "entire concept" of FTP passwords is useful in that it allows a
user to get at files either destructively (in a positive sense) or
past normal security (that is, files not publicly readable.) I don't
think getting rid of this feature is a step forward.

There are already passwordless protocols in use (eg. TFTP in the
internet world and transferring via uucppublic in the UUCP world.) For
obvious reasons they seem to have limited acceptance when FTP is
available. They're mostly a security botch, especially when fetching
of files is needed.

	-Barry Shein, Boston University