Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!pasteur!ucbvax!TGV.COM!adelman
From: adelman@TGV.COM (Kenneth Adelman)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP "STRU VMS" extension
Message-ID: <890201000051.5f@TGV.COM>
Date: 1 Feb 89 08:00:51 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Adelman@TGV.COM (Kenneth Adelman)
Organization: The Internet
Lines: 54

> > ... (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 problem is that the market recognizes a need to an intelligent
file-transfer mechanism which isn't any harder to use than FTP.

> 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.

    Understand that 'building' the 'filter' program into FTP isn't enough.
We need a way of determining if the receiving FTP will decode the file before
we encode it. Yes, the "SITE" command could be used for this.

> 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.

    Actualy ENCRYPTION and COMPRESSION should probably be a MODE command.
There is already defined a standard for run-length data compression
(MODE C) which the server on IU.AI.SRI.COM implements for those would
would like to test it against their implementations. Our FTP also has
the Unix 'comress' LZ-compression built in as a non-standard extension
called "MODE LZ" (try picking up a file in MODE LZ from IU.AI.SRI.COM
and uncompressing it on your Unix machine; actually, this will only work
in TYPE I, because otherwise the transfermation LF->CRLF->compressed(CFLF)->
network->decompress(CRLF)->CRLF->LF won't work).

    Note MODE LZ does not conflict with STRU VMS, and they can be used together
to increase performance over most slower-than-ethernet speed lines.

    No flames, I'm not arguing for a standard for this. But, we
implemented it because our customers asked for it.

								Ken