Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!CCY.BBN.COM!cmills
From: cmills@CCY.BBN.COM (Cyndi Mills)
Newsgroups: comp.protocols.tcp-ip
Subject: FTP "STRU VMS" extension
Message-ID: <8902010536.AA12107@ucbvax.Berkeley.EDU>
Date: 31 Jan 89 23:03:29 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 46

> We don't need to add vendor propriatary stuff to FTP.  Binary
> and network ascii seem sufficient to me.  Encoding and decoding before
> and after a binary file transfer can be used ...
> ... (In UNIX terms, encoding == dump, decoding == restore).

In theory, I agree with Phil.  Any type of compression/encryption/encoding
program that includes O/S-specific file information can have as its output a
file.  The contents of the file may be transferred via FTP to another machine
which runs a program to reverse the algorithm to decompress/decrypt/format the
result into a file.

This approach treats FTP as a bulk-transport mechanism, NOT as an intelligent
file-transfer mechanism that converts between file representations, but is
handy for several applications, such as distributing software among like-minded
O/S (the compressed .z files under UNIX come to mind.)

The drawback is that it usually requires a two-step process. How do you
transfer an entire directory tree, for example, within FTP, if a requirement
for that transfer is that the O/S-specific attributes of each file is preserved
across the transfer?  The user must remember to decode each file upon exiting
FTP, but he may not know the names of all the files in the transferred
directory or how many there are.  This can complicate automated procedures.
Also, the intermediate undecoded files can pose problems in naming space and
disk space.

The first purpose of the SITE VMS or STRU VMS command is to allow a
pre-specified two-step process to be performed automatically within the FTP
command to each file AS IT IS TRANSFERRED, where this process is so common that
it might be applied to every file in a directory.  This eliminates the two-step
process, the problems of storing or naming an intermediate file, and the
problems of applying this process in automated scripts or to entire directory
trees.

Second, if you are implementing an O/S-specific command, I applaud the attempt
to have it be the same across multiple TCP/IP implementations, to improve
interoperability.  Since you are trying to specify a useful VMS "protocol
extension" as an ad-hoc standard, you might consider including not only the RMS
headers, but flags to indicate compression and/or encryption that might be
optionally implemented.  Or a field to specify a procedure, command file, or
program to be executed upon completion of each individual file transfer to
perform these and/or other conversions.

Sample command: > SITE VMS ENCRYPT COMPRESS
style		> SENDTREE [LOCALDIR] [REMOTEDIR]

						Cyndi Mills