Xref: utzoo comp.dcom.lans:1635 comp.protocols.tcp-ip:4220
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!ncar!ico!dougm
From: dougm@ico.ISC.COM (Doug McCallum)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)
Message-ID: <8362@ico.ISC.COM>
Date: 28 Jul 88 19:22:53 GMT
References: <61066@sun.uucp> <1116@nusdhub.UUCP> <8361@ico.ISC.COM>
Reply-To: dougm@ico.UUCP (Doug McCallum)
Organization: Interactive Systems Corp., Boulder CO
Lines: 35


In an earlier article I mentioned that there should be a name server
to do the conversion.  I didn't intend to imply a single name server
to handle "all" address formats or that only a single format should be
allowed, rather, I feel that a name server functional interface should
be specified.  Each protocol implementation would then provide an
appropriate name server that the standard interface could access.
Each application woudl be implemented using the standard interface.

Finding which name server isn't difficult since you have to specify
the protocol via the first parameter to "t_open" anyway.  That would
be enough information to provide a standard way of finding and
accessing a specific name server.  It would also be possible to query
each resident name server and see if it could resolve the address or
not.

When a name is resolved, the resolver function would return a possible
list of opaque addresses.  It would also have to return the size of
the address to provide a way to determine end of an address and a
count of how many addresses were returned.  Some protocols might not
support or need multiple addresses while something like TCP/IP does.

A universal functional interface need not return a single fixed size
standard format object.  The application does not need to know how to
parse the address.  Some applications might, but then they would not
be particularly portable in any event.  Most applications would just
hand the address to t_connect and wait for a connect or fail.  This
would not be that hard to specify or even very difficult to implement.

You would have thought that AT&T would have understood the need of
name servers and related tools that become an absolute necessity with
large networks.

      			Doug McCallum
			Interactive Systems Corp.
			dougm@ico.isc.com