Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!TGV.COM!adelman
From: adelman@TGV.COM (Kenneth Adelman)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP "STRU VMS" extension
Message-ID: <890224180532.202@TGV.COM>
Date: 25 Feb 89 02:06:10 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Adelman@TGV.COM (Kenneth Adelman)
Organization: The Internet
Lines: 30

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

    DECnet over IP isn't a replacement for STRU VMS in the Internet
environment. Phase IV DECnet is routing-braindead, limiting the size
of DECnet networks, and requiring great administrative pains to get
large networks to work.

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

    After all the flames I've received about the proposed STRU VMS
extension to FTP, I'm not going to propose our DECnet over IP
encapsulation as a standard. However, I would be more than happy to
share the encapsulation specification with anyone interested in
developing complementary or competing products to MultiNet.

    TGV does not believe that protocols of this nature are
trade-secrets, only the code and associated technology used to
implement them.  This applies to STRU VMS, IP over DECnet, DECnet over
IP, and potentially others.

					      Kenneth Adelman
					      TGV, Incorporated