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