Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool2.mu.edu!sdd.hp.com!hplabs!hpda!hpcupt1!hpindwa!raj
From: raj@hpindwa.cup.hp.com (Rick Jones)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Re: rfi: VMS TCP/IP products
Message-ID: <36540019@hpindwa.cup.hp.com>
Date: 21 Jan 91 21:20:24 GMT
References: <59700002@hpopd.pwd.hp.com>
Organization: Hewlett-Packard, Cupertino CA
Lines: 42

Since corrections were solicited ;-)

>HP's NS/VAX is not recommended for TCP/IP networking requirements.  
>It provided NS and telnet between VMS and HP using an HP proprietary 
>networking protocol (not TCP/IP).

This is incorrect - TCP/IP *IS* the protocol used by NS/VAX and NS
anything else HP. What *is* nonstandard about it is its use of the
Probe protocol for NAME->IP and IP->LAN address resolution. At the
time of its introduction, Probe was the only thing going on HP3000s.
The other point of non-standardness is it's use (to the 3K's at least)
of what is sometimes refered to as 802.HP encapsulation for IP
packets. NS pre-dates the birth of SNAP, and uses the IEEE assigned
802.2 sap for IP (it also is really early in the development of ARP,
hence the use of Probe...). The rest of the world went with SNAP, so
our use of a 'standard' standard became percieved as being
non-standard ;-)

more after the signature for those interested...
rick jones
___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | But is IS TCP/IP - Honest! ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply


$further developments

Since MPE/V V-Delta5, and MPE/XL Release 2.2, the 3000s have supported
Ethernet encapsulation in addition to 802.3/HP. ARP has also been
added. 

One other common misconception is that 3000s cannot communicate with
the rest of the world because the interface to TCP is NetIPC. They
forget the meaning of the word "interface" and assume it is the same
as "protocol." There is no reason why a NetIPC application cannot
communicate with a BSD Sockets application. I know of at *least* two
examples of this. The first is FTP/XL (shipped for Release 2.2 and
later). The second I cannot mention here but it is along similiar
lines.

$ return to normal programming