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: <602892098.0.KASHTAN@IU.AI.SRI.COM>
Date: 7 Feb 89 22:01:38 GMT
References: <8902061636.AA13703@pinocchio.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 62

>What I don't understand is why this isn't taken care of extra-FTP by
>some sort of archiving utility like tar.

That has, in fact, been the solution for a LONG time.  Make a program that
can PACK/UNPACK VMS Backup Savesets using files that can be transferred in
FTP IMAGE mode.  Aside from various the system administration problems that
have already been enumerated there is also a psychological implication.  The
fewer steps you have to go through to get a file transfered the happier you
are (witness the preference of "rcp" over FTP when available).  There have
been many times that I have used slower file transfer methods just because
it was less work for me (the difference in transfer times has to be pretty
significant for me to prefer the more laborious method).  There is also the
issue of ensuring that EVERYBODY you might want to exchange VMS files with
has all the appropriate tools (isn't this what standards are for?).  As a
TCP vendor we are very concerned about providing MAXIMUM functionality to our
customers -- and this issue is of pretty serious concern to us.  So, rather
than just DO something so that machines running our software can communicate
in this fashion we have asked the TCP community to discuss the best way to set
a standard so that we can interoperate with other VMS TCPs for this "extended"
service yet still interoperate with the rest of the TCPs in the world.  I
feel that Ken's suggestions are a good solution to the problem (but I am
obviously biased).

>It wouldn't really occur to me to ask for an extension to FTP to
>transfer an arbitrary file tree between Unix's (for example), I'd just
>bundle it up with tar and send *that* (possibly compressing and/or
>uuencoding if need be.) In fact, that's SOP.

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.

>At best I could imagine some sugar in the VMS server/clients which
>might say "Hmm, that's a MUMBLE file, I'll spawn off a FROTZ command,
>send the result of that, and if the other side is a VMS site he'll
>recognize the header and automatically do the opposite", but none of
>that needs a change in the protocol spec since it only affects the OS
>interface, not the network interface (the file would just be xferred
>binary I'd guess.) Personally I hate that kind of magic.

AHA - but now you have implied some "standard" in the FTP protocol that
would allow both sides to recognize that they can do this.  In fact, this
is really what Ken's suggestion amounts to.

>No FTP extensions should be needed (eg. something like embedding UNIX
>magic numbers should do it.) And again, if the other side wasn't a VMS
>site it would work also (that is, would store the file image but make
>no attempt to unpack it.) A good example of the utility of this
>approach is putting VMS files for Anonymous FTP onto a non-VMS system.

But you would still need to know what "mode" the other side is in to
correctly interoperate with it.  What if you assumed that you were in
"include-the-magic-number-and-transfer-the-file-transparently" mode and
were talking to a "standard" FTP on the other side.  What if you were
transferring an ASCII file.  In this case, the correct thing to do is
to use the standard ASCII transfer mode.  How do you recognize automagically
that you should do this.  Once again -- we need some sort of "standard"
specified to allow the recognition that the other side can do what you
want it to.

David
-------