Xref: utzoo comp.dcom.lans:1525 comp.protocols.tcp-ip:3942 comp.protocols.iso:110
Path: utzoo!attcan!uunet!husc6!mailrus!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: TLI transport specific addresses
Message-ID: <58781@sun.uucp>
Date: 2 Jul 88 01:22:01 GMT
References: <297@scolex> <1084@nusdhub.UUCP>
Sender: news@sun.uucp
Lines: 41

> It is important to remember that the "addresses" refered to by
> this are the _names_ assigned to the endpoint in question and
> _not_ the physical address/serial_number of the board, to whit:
> the address may be associated with different hardware at different
> times.  As such addresses are arbitrary character strings, usually
> numonic, with several "suggested guidleines" for safe naming.

Guess again.  Check out the manual page for "t_connect":

	In "sndcall", "addr" specifies the protocol address of the destination
	transport user, ...

Protocol addresses are generally NOT names and are generally NOT mnemonic; if I
want to know that "seismo.css.gov" is 192.12.141.25, I have to look it up.
"seismo.css.gov" is the name of the machine; its protocol address in the
Internet protocol family is the byte string represented in printed form as
192.12.141.25.  (The byte string itself would probably contain 4 bytes with the
decimal values 192, 12, 141, and 25.)  The fact that the address is referred to
by a "char *" does not mean it is necessarily a string of printable characters;
it's just a string of bytes ("char" means several things in C, including
"byte").

There may well be protocols in which the protocol address is some form of name
that a human can deal with without too much pain, but neither the Internet
transport/network protocols nor the ISO transport/network protocols have
addresses of that form.

Translating "user-friendly" names to protocol addresses is generally the
responsibility of some layer of software other than the transport-layer or
network-layer protocol implementation.  Some protocol families have protocols
for doing this; the Internet protocol family has the domain name server
protocol, which is implemented atop transport-layer protocols (TCP or UDP).
Other mechanisms can be used, such as searching a file (the "host table") or
making queries to other sorts of name servers (e.g., a Yellow Pages server).

Presumably, if one had, say a procedure that took a host name, a service name,
and a protocols family name, and returned the appropriate byte string for the
address of that service on that host in that protocol family, one could write a
transport-independent program to access that service, assuming the service ran
atop several transport layers and didn't depend on particular features of
specific transports.