Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!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: <602233186.0.KASHTAN@IU.AI.SRI.COM>
Date: 31 Jan 89 06:59:45 GMT
References: <8901301937.AA00273@braden.isi.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 50

Just to throw a little more fuel on the STRU VMS fire:

I think you make a valid (though orthogonal) point about interoperability
in the face of "non-traditional" files.  At the moment we have interoperable
ways of moving ASCII text, raw BINARY bytes and (at least in some FTP
implementations) BINARY variable length records.  It would also be nice
to be able to interoperably move files such as ISAM and TEXT with non-imbeded
print-control but we don't even have any standards for the interoperable
representation of the data.

In the meantime, there are 2 issues that the VAX/VMS FTP world needs to deal
with:
	1) The ability to transfer, in a transparent fashion, arbitrary
	   VAX/VMS files to/from other cooperating machines.

	2) The ability to take advantage of the knowledge that both sides in
	   the FTP transfer are VAX/VMS machines to maximize the FTP
	   throughput by not having to do any data conversion before putting
	   the file data "on-the-wire".

The suggestion of a STRU VMS was consistent with semantics of the STRU
command.  Interoperability is not sacrificed as long as non-VAX/VMS
sites continue to (correctly) reject the STRU VMS command. All the
VAX/VMS clients that will adhere to this standard will attempt to use
STRU VMS when first communicating with the server but upon the rejection
of the STRU VMS command will revert to the interoperable behavior.  The
result we have is that clients that support STRU VMS will initially ask
servers for STRU VMS.  If they receive a success, then this "enhanced-VMS"
FTP communication mode will be used.  If they receive a failure, well then
we are back to the current situation (where STRU VMS doesn't exist).

There have been suggestions that the SITE command be used for this extension.
I am not overly enthusiastic about this -- the transfer mode implied by
STRU VMS is really exclusive of STRU [F, R or P] and not something orthogonal.
When you are no longer in STRU VMS then you want to explictly be in
STRU [F, R or P].

There has also been a suggestion of using STRU P for this extension.
Semantically it feels better to me than using the SITE command but, as
Ken Adelman has already pointed out, in conforming to the FTP STRU P
specification we lose a considerable amount of efficiency.

In conclusion, what we are asking for here is NOT anything intended to
be interoperable with non-VMS sites (although the way VMS clients need
to be written will ensure interoperability with non-VMS sites).  We need
some way of allowing consenting sites (I would assume these to be exclusively
VAX/VMS sites) to dynamically "upgrade" their class of FTP service.

David
-------