Path: utzoo!attcan!uunet!bloom-beacon!tut.cis.ohio-state.edu!ucbvax!RT-JQJ.STANFORD.EDU!jqj
From: jqj@RT-JQJ.STANFORD.EDU (JQ Johnson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  XNS / TCP gateway??
Message-ID: <8909241859.AA10391@rt-jqj.Stanford.EDU>
Date: 24 Sep 89 18:59:50 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 29

As Dave Crocker points out, the safest way to get the remote terminal
applications gateway you want is to put 2 terminal servers back to
back.  However, if you can get documentation on the XNS terminal
protocol, you could also consider using a 4.3BSD system as the
applications gateway.

The problem here is that XNS is well defined up through transport, but
above that each vendor has added its own suite of protocols.  Xerox,
for example, has an RPC system called Courier built on SPP (the
reliable transport protocol that is the top of the traditional XNS
stack).  On Courier, Xerox has built many applications including a
remote terminal protocol.  Several years ago at Cornell, I built a
remote terminal applications gateway running on a BSD system that used
the XNS support in 4.3BSD, and hooked together a TCP telnet client
(server) to an xnschat server (client) to provide exactly the kind of
gateway you envisage.  Unfortunately, that's for only *one* flavor of
XNS-based remote terminal protocol, not yours!

Although TCP/IP has not been very successful at being chosen as the
native protocol for LAN operating systems, it has been far more
successful than XNS in achieving multi-vendor interoperability.


JQ Johnson                              voice: 415-723-3078
Manager, Special Projects               Internet: jqj@jessica.stanford.edu
Networking and Communications Systems
Pine Hall Rm 125-A 
Stanford University
Stanford, CA 94305-4122