Xref: utzoo comp.dcom.lans:1634 comp.protocols.tcp-ip:4218
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: <8361@ico.ISC.COM>
Date: 28 Jul 88 18:33:39 GMT
References: <61066@sun.uucp> <1116@nusdhub.UUCP>
Reply-To: dougm@ico.UUCP (Doug McCallum)
Organization: Interactive Systems Corp., Boulder CO
Lines: 158

In article <1116@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>I am begining to suspect that I am exchanging POV with more than one
>other individual.

You are.  There are 3-4 of us.

>For clarity, the thread to date is based on one posters lament about how
>dificult it was (for him) to write a TCP/IP interface which runs under
>TLI.  Please re-read this sentince about a millino times--or at least until
>it soaks in throughly--before proceeding.

Ok, in your sentence, the operative word is "under".  That is, TCP/IP
interface is "under" the TLI.  That's pretty clear.

>Either that, or the postings are not being read, they are being "sampled."

You might follow your own advice.

...
>True; I do understand that.  This relates bact, however, to the "lament"
>that TLI (e.g. AT&T) did not spesify a "universal structure"  (read to mean
>memory structure as in C or assem) which would interface to *every* kind
>of underlying protocol. (and went on to name: X.25, SNA, URP, TCP/IP [sic]
>and a couple of ones I didn't know)  Put simply, such a structure would
>be preposterous and unworkable, therefore the "structure" stteled on was
>the "string."  (e.g. a netbuf structure filled with an "arbitrary" string
>of characters meaningful to the application and the TLI driver.)

No one suggested a "universal structure".  What is needed and was
suggested was  a structure for each address family.  It wasn't worded
exactly that way, but that is what was said.  Who settled on the
"string" as the official form of address?  You may have.  The Starlan
software may have, butI have not found it anywhere in the
documentation.  Please cite volume, chapter and verse so I can be
enlightened.

>To this end, what I wrote was *exactly* as menaingful as I intended.
>We have laready been through the:  "But my address is 198.3.54.6 and
>not nusdhub.serve, so whay should I pass the latter" argument.  I
>therefore, used the "addressing scheme" of choice (to my audience).

Actually, your audience seems to be disagreeing with you.

...
>I KNOW the way is should be done when you have no other constraints.
>What I described conforms to the constraints provided.  READ THE THREAD.

But the constraints are yours and not TLI or AT&T's.  Could you point
me at something that documents how things are supposed to be done?

...
>> is "more complex" than the other, except to say "TLI supports functions TCP
>> doesn't provide" (which is true) or "TCP provides functions TLI doesn't
>> support" (which is also true).
>
>No kidding???!!!???  Of course they are, but the basis of all this was
>someone who wanted to implement TCP/IP *over* TLI (patently dumb)
>and the waters you just re-muddied were almost clear.

Now, if your earlier sentence (included here for context)
    >For clarity, the thread to date is based on one posters lament about how
    >dificult it was (for him) to write a TCP/IP interface which runs under
    >TLI.  Please re-read this sentince about a millino times--or at least until
    >it soaks in throughly--before proceeding.

states what started this, then how do you get TCP/IP being implemented
over TLI from TCP/IP "under" TLI?  Before telling others to "read",
you should do the same.

...
>Yes, I know about address names, verses real addresses.  I am trying to
>keep the examples simple and well defined.

But your examples only work in the simple and well defined universe.
They don't work in the real universe the rest of us have to deal with.

>Once again, If you simply say:  "But I'll just throw away my spesifications
>and the desire of my employer and do it this way" all sorts of things become
>a lot easier.  Similarly, if you just say:  "This example is to basic, it
>allows someone form another environment to _understand_ so I better
>re-muck it up"  you can justify all sorts of "better" things to say.

Are you speaking as the authoritative voice of what AT&T wants people
to do with TLI addressing?  Again I ask, point me at any published
specification that states that "strings" are what is specified.  If
you look on page 3-7 of the "AT&T UNIX(tm) System V Network
Programmer's Guide", you will find a documented counter-example to
your claim of strings being the specified address format.  If you are
interpreting the fact that the netbuf structure defines the "buf"
field to be type "char *", well, "char *" is frequently used as a
pointer to anything.

I should also mention that when I worked on TCP support during the 386
V.3 port, we had to change the address convention used to conform to
what AT&T required.  That address format was a specific format for the
struct sockaddr_in structure, it was not an ASCII string.  Come to
think of it, the "official" port supported ISO protocols with a very
"binary" representation.  This is documented in the "AT&T UNIX System
V/386 System Administrator's Reference Manual"  section tp4(7).

...
>I don't know weather you have read the specs for UUCP as relates to
>a TLI conformant provider.

I have, what is it supposed to tell me that contradicts what the
author said?  You can either put in a phone number (in ASCII) or use
\nnn notation to put in what you need.  In other wrds, where RFS
(which uses a different host file altogether) allows \xABCD, UUCP
would require specifying in octal with the \nnn notation.

...
>No, I am not farmilliar with the internal details of TCP/IP;  my question
>about TCP/IP is mostly how this thread got started.  As far as TLI is
>concerned, I have been through the "porting rules" doccument--which
>contains a description of *all* of the STREAMS requirements and
>functional spesifications necessary to make any STREAM represent a
>'TLI conformant provider'  (this includes state and precidence tables)--
>and know exactly what is and is not required of a system for it to be
>TLI conformant.

I've been through the porting rules as well.  Not everyone ahs access
to them.  It is not supposed to be necessary to have the porting rules
to do a Streams driver which is TLI conformant although it certainly
helps.  Where does it mention how an address is supposed to look?  It
doesn't mention it anywhere where I could find it.

>The essence of the discusion is:

I assume that the A: are your interpretations and may not necessarily
be correct?

>(1) Q: What structure should be passed to TLI?  A: A "human readable"
>	string.

Prove it.  Give document, chapter, page and line.

>(2) Q: How can I [sic] implement a TCP/IP interface over a TLI network?
>	A:  You can't; you don't want to; the whole point of TLI is
>		to allow/create a "simple and uniform" interface
>		which will work with any provider.

This isn't the issue so don't confuse things any further.

>(3) Q: How am I supposed to do address translation under TLI?
>	A:  You don't; the driver writer has built the soft-to-
>		hard address translation into the driver (if it
>		is in fact conformant).

The real answer is that you can't with TLI at all.  You need software
that is not provided with V.3.

Since your the one so insistant on being correct and having
documentation to prove it, please do so.  My documentation does not
seem to have it.  Give published dates also.  Perhaps what an outsider
can get is not the same as an insider.

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