Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)


Scott Schoenthal (pyramid!sas@hplabs.hp.com)
28 Jul 88 16:57:03 GMT


[ I have removed comp.protocols.iso from the Newsgroup distribution -- sas ]

In article <In article <1116@nusdhub.UUCP> In article <1116@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>The essence of the discusion is:
>
>(1) Q: What structure should be passed to TLI? A: A "human readable"
> string.

I have tried to follow your "thread" and I must take exception to this
statement. The point (as I see it) of the addressing discussion is that
the structure of the address (in ISO jingo, the TSAP) that is passed
to TLI is opaque. It is up to the implementation of the TLI-conformant
transport provider as to how this is interpreted. Mike Eisler raised the
point that different transport provider implementations that support
the same protocol (he used TCP/IP addressing as an example) could interpret
the address in different, arbitrary manners.

What is lacking is the definition of an addressing structure (be it
packed BCD, hexadecimal arrays, or ASCII strings) to be used for different
communication protocol families (e.g., OSI, XNS, TCP/IP, etc) within the TLI
framework.

That, sir, is the point.

>(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 question itself is a non sequitur. A more reasonable way of stating what
I think you mean is:

        "How does an application programmer form address structures
        to pass to a TLI conformant provider while using the TLI
        user-library functions?"

And the answer is (once again) that the format of the structure depends on the
implementation of the provider. The provider renders the
address structure passed to it (which is defined as part of the implementation
of the provider) into whatever internal formats or uses it requires.

Rob, I suggest that, if possible, you should somehow get access to System V
source code. I think that the points made by Guy, Mike, and others will
become more obvious. It is unfortunate that the publically available
documentation does not make these issues more clear.

sas
----
Scott Schoenthal sas@pyrps5.pyramid.com
Pyramid Technology Corp. {sun,hplabs,decwrl}!pyramid!sas



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:42:52 GMT