Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!IU.AI.SRI.COM!KASHTAN
From: KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP "STRU VMS" extension
Message-ID: <604375880.0.KASHTAN@IU.AI.SRI.COM>
Date: 25 Feb 89 02:11:20 GMT
References: <8902241549.AA08799@multimax.encore.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 53

>Ok, I can live with this but...VMS is a proprietary operating system
>managed by exactly one corporation. I hear DEC is supporting or soon
>to support TCP on VMS, do they have any proposals in this realm?

  My impression of things is that TCP is very low priority within DEC
  and that they have a long long way to go before they start worrying
  about this kind of problem.

>If DECNET solves this problem then DECNET over IP might be a better
>way to deal with this issue as it simply provides a lower layer for
>transport and any changes in the file attributes etc by DEC can be
>punted to DECNET support, it can be the only layer aware of such
>things and as long as the DECNET packets flow all should be well.

  Yuck!  Now to solve a very straightforward problem you need to ensure
  that all VMS TCP sites:
	1) Buy DECNET (it is NOT cheap!)
	2) Arrange to be connected (DECNET-wise) into a single accessable
	   DECNET network (even if it IS using IP as the transport).
  Not to mention that the users (who might be transferring some files from
  UNIX workstations and some files from other VMS machines) will have to do
  2 completely different things when they want to transfer VAX/VMS files
  with attributes intact vs moving files to/from hosts running any other
  O/S.

>We *are* talking VMS<->VMS communications here, right? And at least
>one vendor already offers DECNET over IP, so the only real question is
>whether this combination already or could in the near future solve the
>problem. I could see an encapsulation standard (RFC) for DECNET/IP as
>a way to acheive this in a uniform manner among vendors.

  I think that an RFC for DECNET over IP (actually UDP) is a good idea, and
  since we are (as far as I can tell) the only ones who have implemented this
  I guess we should get an RFC out right away.  Note that this DOES NOT
  solve the original problem -- extending FTP to transfer O/S-dependent
  files between cooperating systems in a way that still interoperates
  correctly with OTHER systems.  To this end I think that extending the
  proposed STRU VMS to STRU OS xxx (i.e. STRU OS VMS is a particular
  instantiation) is a valuable contribution to the FTP spec.  The SITE command
  might be more appropriate for this extension -- but the semantics entailed
  in this transfer mode most closely mesh with the semantics of the STRU
  command.

>At least that model could lead to dealing with other proprietary
>systems and network protocols, as it has in the past (eg. RSCS over
>IP, CHAOS over IP, XNS over IP, etc.)
  Again -- tunneling through IP is a most worthwhile thing (and we do this
  quite a bit with our software) but it does NOT address the issue we are
  currently arguing.

					David Kashtan
					TGV Inc.
-------