Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!IU.AI.SRI.COM!KASHTAN
From: KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP "STRU VMS" extension
Message-ID: <603089521.0.KASHTAN@IU.AI.SRI.COM>
Date: 10 Feb 89 04:52:01 GMT
References: <8902082217.AA08143@pinocchio.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 72

>If it's a matter of saving steps why not just build a DCL wrapper
>which does the job? Heck, Interlisp-D had what amounted to a very good
>NFS based on vanilla FTP, required no changes to the server (eg. UNIX
>or VMS) system as I remember.
  This is a solution -- though not a pretty one.  It loses on several
  fronts:
	1) It doesn't address the issues of system management and disk
	   quotas.   It is definitely not a selling point for the software
	   if you are required to have 2 times the disk space available
	   in order to transparently transfer the files

	2) It is considerably slower than just transferring the files

	3) Even with the wrapping (though I guess we could make the FTP
	   client do it behind your back) it is not as convenient to use
	   as directly using FTP.

	4) What about the destination site where you don't have login
	   access to invoke the wrapping.

>>>It wouldn't really occur to me to ask for an extension to FTP to
>>>transfer an arbitrary file tree between Unix's
>>>	.
>>>	.
>>
>>But that is just the point -- UNIX files and FTP IMAGE transfer are a good
>>match (i.e. they give you the functionality that you need).  We are looking
>>to do something equivalent for VMS, where IMAGE transfers are not sufficient.
>
>You missed my point. Unix directory trees and FTP IMAGE are *not* a
>good match. You have to bundle it up with tar (or equivalent) first.

IMAGE mode exactly matches the transfer characterstics you need for the UNIX
file data.  The LIST/NLST FTP commands provide "almost" everything you need
to implement directory tree copying (in fact -- you just need an extension to
the UNIX wildcard syntax to make that possible).  And the current FTP spec.
is most definitely well suited to copying whole UNIX directories (MGET/MPUT).
So in many cases "tar" is not needed -- and the facilities are already there
for a vendor to implement a full UNIX directory tree copy without having to
resort to an FTP protocol extension.  We are just trying to arrange for the
same situation for VAX/VMS.

>Maybe this gets closer to the heart of the matter, perhaps what VMS
>really needs is an analog of Unix's RCP which can transfer directory
>trees and preserve file modes. Why not a separate VMSCP utility for
>VMS? At least that idea extrapolates cleanly to any number of OS's and
>we can leave FTP alone to do what it was designed to, zap the bytes
>from point A to point B with a minimum of interpretation (I'd be more
>in favor of dropping TENEX mode from FTP.)

I wouldn't argue of this one much -- a VMS equivalent to UNIX's RCP is
a good idea (and we will probably by supplying one sometime in the future)
but it will be even more difficult to get all the VMS TCP vendors to agree
on a whole NEW application protocol than for them to agree to an extension
to an existing protocol (an extension which, by the way, requires very little
effort for VMS TCP vendors to implement -- this goes a LONG way towards
ensuring that all VMS TCP's can interoperate).

>Just out of curiosity, how does DECNET handle all this

DECNET uses a file data transfer protocol called DAP -- which was designed
to address exactly these issues of sharing different "format" files between
heterogeneous DEC systems (and, although the implementations are a bit slow
for my taste, DAP managed to do a pretty decent job of allowing transparent
file transfers between not just VAX/VMS systems but also to/from most other
systems sold by DEC over the years -- like TOPS-20, RSX ...etc).  I would
point out that DAP is complicated enough that few people would WANT to adopt
it as any kind of standard.

Still battling for a "STRU O xxx" standard,
David
-------