Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!amdcad!sun!aeras!elxsi!beatnix!mre
From: mre@beatnix.UUCP (Mike Eisler)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TLI transport specific addresses
Message-ID: <852@elxsi.UUCP>
Date: 25 Jul 88 20:24:33 GMT
References: <843@elxsi.UUCP> <1111@nusdhub.UUCP>
Sender: news@elxsi.UUCP
Reply-To: mre@beatnix.UUCP (Mike Eisler)
Organization: ELXSI Super Computers, San Jose
Lines: 62

In article <1111@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>in article <843@elxsi.UUCP>, mre@beatnix.UUCP (Mike Eisler) says:
>>>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!
>> 

I said:

>> 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.

Rob says:
>
>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.
>

Rob,
	Try to follow this analogy: Suppose my phone number is
	234-5678.  234 is analagous to an IP machine address. 5678 is
analagous to a port number. In the telephone world, I walk up to a
phone, enter 234, then 5678, and expect things to work as expected.
What we have been trying to tell you, is that in the underspecified
TCP/TLI world, we don't know how to enter the digits. On vendor A's
implementation we might enter 2345678, on B's 5678234, and on crazy Z's
it might be something as silly as 8 3 5 6 3 4 2 1. So how can I write
an application to lookup your name, R. White in the phone book, and
send that name to the protocol driver via TLI, and expect it to be
portable to all implementations of TCP/IP. The application either has
to know the various ways of encoding digits, or there has to be an
encoding agreement, or each machine has it's own version of the phone
book that matches the enconding used by its TCP/IP implementation.  And,
I don't really care if you encode in ASCII or binary. It's still a
problem.

>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...

I got onto it because it is an example of something that runs on TLI,
independent of the *type* of protocol, uses a central name servicer,
and doesn't work when interoperating between different vendor
*implementations* of a protocol. It is an empirical demonstration that
your reasoning over the past few weeks is 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 address structure is only universal in that it is opaque. The
individual may have said the above, but what he really meant is that
AT&T should have defined a standard address format for TCP, for SNA,
for ISO/OSI, for DECNET, etc., just has they did for their own protocol,
starlan.

	-Mike Eisler