Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!INFOODS.MIT.EDU!KLENSIN
From: KLENSIN@INFOODS.MIT.EDU.UUCP
Newsgroups: mod.computers.vax
Subject: FTP and save sets
Message-ID: <870316121253.000003EB0D1@INFOODS.MIT.EDU>
Date: Mon, 16-Mar-87 12:12:53 EST
Article-I.D.: INFOODS.870316121253.000003EB0D1
Posted: Mon Mar 16 12:12:53 1987
Date-Received: Wed, 18-Mar-87 03:19:30 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 47
Approved: info-vax@sri-kl.arpa

Apologies, in advance, to the UUCP and BITNET readers of this list: this
is specifically a TCP/IP inquiry, but this seems to be the right place to
send it.

There seem to be considerable difficulties in FTPing VMS save sets, at
least without explicitly converting to and from encoded forms at each end.
Better conversion tools keep coming along, but are clearly an inelegant
solution.  Given this, has anyone considered defining and RFC-ing an
extension to STRU, possibly with the use of SYST, to permit agreement
between the server and user FTP programs that a save set is coming and
should be handled accordingly?  

It should be possible to reach agreement, either to define a special
character for the save set type (disadvantageous because it would
immediately lead to a request for similar things for other systems) or to
allocate a few extra STRU characters for, say, type A and B "sending
system archives".  This latter convention would be general enough to
accommodate a variety of special operating system formats that don't FTP
and reconstruct easily (IBM NETDATA comes to mind).  An (even-slightly)
intelligent FTP program could then request the operating system type of
the server with SYST and then either refuse the transfer or make the user
assert that it was ok anyway if the operating system types did not match. 

I think this could be done as a sufficiently clean extension that hosts
that did not support the facility at all would simply return a 504 "not
implemented for that parameter", presumably what they do now if the
character is not F, R, or P.

Note that none of this contemplates any conversion of intrinsically
internal formats from one operating system to another -- just figuring out
a way that two systems that are known to be using the same operating
system and compatible host types can transfer file organizations that are
heavily used and highly supported in that operating system.

At present, the number of VMS implementation of TCP/IP and FTP is small
enough that they can be counted on the fingers of one hand and, to my
knowledge, none have made explicit arrangements for save sets.  Unless
this type of feature is less important than I think it is, it would be
wise to try to standardize something before we end up with several
incompatible solutions.

If people want to send comments directly to me, I'll be happy to summarize
after a week or so.
   John C Klensin, MIT
   ARPANET:   Klensin@INFOODS.MIT.EDU
   BITNET/EARN/etc (if you have a working MAILER): as above
                   (if you don't):  JCK@MITVMA