Xref: utzoo comp.dcom.lans:1616 comp.protocols.tcp-ip:4195 comp.protocols.iso:128
Path: utzoo!attcan!uunet!husc6!rutgers!ucsd!ucsdhub!jack!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: TLI transport specific addresses
Message-ID: <1111@nusdhub.UUCP>
Date: 22 Jul 88 18:56:48 GMT
References: <843@elxsi.UUCP>
Organization: National University, San Diego
Lines: 60

in article <843@elxsi.UUCP>, mre@beatnix.UUCP (Mike Eisler) says:
> Xref: nusdhub comp.dcom.lans:365 comp.protocols.tcp-ip:1120 comp.protocols.iso:49
>>You (the application) don't need to know the addressing format for
>>your provider any more than you need to know the sixteen tones
>>used in DTMF dialing to use a Touch-Tone(r) phone.  You provide
>>the free-form address as a string, and the rest of the system does
>>it's best to make the connection you want, but like the PSTN
>>(Public Switched Telephone Network) if you don't know the number
>>you want, you probably arn't gonna get through!
> 
> Yeah, but regardless of whether I use rotary, or touch tone, and whether
> the party I'm calling uses rotary or touch tone, we both agree on what
> our phone numbers are, and what the order of the digits are. Because of
> this, we can use a common name service called the telephone book.


Mike,

I don't know if you read teh entire thread, but your last comment is
_EXACTLY_ my point in making the telephone analogy.

The whole PURPOSE behind TLI is that you *should* pass any address
you want to use to TLI as a string; and the TLI driver for whatever
the network is, should do all the work of figuring out how the provider
needs the address (in binary) and changing the string to binary.

I don't know why you jumped off on the RFS tangent; who cares about
RFS per se, it was the addressing that was at issue...

The diference between "255.255.255.255" (the string) and 0FFFFFFFFx
(four bytes of binary) is quite essential and obvious.  The difference
between "nusdhub.serve" and the six byte 802.3 serial number/address
of this mahine (which I don't remember, and don't care about because
I have and use TLI) is even more obvious and reasonable.  One can
be included in the UUCP support files, prompted for as input,
supplied as a command argument, and passed around in a non-ambigous
format (between human people); the other can not.  TLI is intended
to use string addresses, and applications which _only_ pass/accept
memory structures are simply broken.

If you look back through thi thread, you will find that all of this
was started when one individual stated that it was stupid that AT&T
didn't invent a universal address structure and build it into TLI.
They did, they call it the string buffer; you know a length and an
offset, also known as a netbuf structure to the TLI library.

The thread was further complicated when this same individual lamented
the fact that he couldn't implement *all* of TCP/IP _over_ TLI.
Even attempting to implement TCP/IP _over_ TLI is stupid.  The
Whole point of TLI is to *dispose* of as many of the internal
issues of things like TCP/IP, in order to create a more simple
and basic programmer interface for the programmer who dosn't
want to specialize in networking.

Implementing TLI _over_ some or all of a TCP/IP transport provider
makes sense, but trying to do it the other way around is dumb.  Remember
the "more-restrictive-shell-above-lesser-restrictive-environment" rule
of systems design and arcitecture?

Rob.