Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-lcc!lll-winken!gauss.llnl.gov!casey
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP "STRU VMS" extension
Message-ID: <20377@lll-winken.LLNL.GOV>
Date: 14 Feb 89 19:39:54 GMT
References: <8902131453.AA04179@sneezy.lanl.gov> <20330@lll-winken.LLNL.GOV>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@lll-crg.llnl.gov.UUCP (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 29


  I don't mind the idea of per vendor extensions to ftp just as long as
they're not part of the official FTP RFC standard.  And I don't mind the
idea of the InterNet community serving as a host for vendor
standardization efforts.  I think that a separate RFC for each separate
vendor extension (using a standard FTP escape mechanism) is the way to go.

  I think that more than enough evidence has been presented to justify
such extensions and their standardization.  But, that evidence also
suggests that, barring AI extensions to FTP, these facilities are totally
vendor specific with no known bound on the number of such.  Therefore in
order to promote standardization within vendor communities but also avoid
rewriting the FTP RFC every time a vendor extension is thought up, it's
fairly clear that each such extension should be described in a separate
RFC.

  Given the InterNet's traditional desire to achieve and enhance
interoperability, I think we should be receptive to hosting vendor
standardization efforts in this manner.  Part of the InterNet's role is
as a standards body after all.

  But, aside from these thoughts, I think Chris is right: you VMS TCP/IP
suppliers ought to get together on your own in a private meeting and
agree on a standard between yourselves.  I think you've received more
than enough commentary about usage of both "SITE" and "STRU".  My
personal choice is "SITE" because it was explicitly put in for such
non-standard extensions, but that's just me.

Casey