Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!HOGG.CC.UOREGON.EDU!jqj
From: jqj@HOGG.CC.UOREGON.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  FTP "STRU VMS" extension
Message-ID: <8901312003.AA13471@hogg.cc.uoregon.edu>
Date: 31 Jan 89 20:03:12 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 27

Phil Wood suggests that anything other than binary (and network ascii,
but by extension we could even do without that) is unnecessary for FTP
since we can have encode and decode filters in a pipeline at either end
of an FTP transfer.  The problem with this suggestion is that FTP does
not support in any standard fashion the idea of reading from or writing
to a filter.  Without some such mechanism, I'd have to *log in* on the
remote system, encode the file, then log out, run FTP to get it in
binary mode, then run the decode.  But maybe I just have FTP read
access and not login priviliges on the remote system!

One alternative to the STRU VMS suggestion is to bury a set of
permitted filters in the remote filename space supported by a
particular implementation, e.g. something suitably gross like:
	FTP> bin
	FTP> put "|encode foo.bar;3" "|decode foo.bar" 
VMS implementations would then only have to agree on the syntax and
function of the filters they supported (note that "|decode myfile.txt"
is a legal Unix file name, but not a legal VMS file name, so there is
no ambiguity).

Note that the different VMS FTP implementations already have non-null
mappings from the ftp-allowed file specifications to the local file
names.  For example, TWG's FTP server allows pseudo-Unix remote file
names, and translates them into valid VMS filespecs ("|decode foo.bar"
currently becomes "9cdecode$7afoo.bar;1").

I prefer STRU VMS.