Xref: utzoo comp.dcom.lans:1590 comp.protocols.tcp-ip:4129 comp.protocols.iso:120
Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ncar!ico!dougm
From: dougm@ico.ISC.COM (Doug McCallum)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)
Message-ID: <7324@ico.ISC.COM>
Date: 16 Jul 88 19:09:32 GMT
References: <666@cbnews.ATT.COM> <1104@nusdhub.UUCP>
Reply-To: dougm@ico.UUCP (Doug McCallum)
Organization: Interactive Systems Corp., Boulder CO
Lines: 142

In article <1104@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>in article <666@cbnews.ATT.COM>, mark@cbnews.ATT.COM (Mark Horton) says:
>> Xref: nusdhub comp.dcom.lans:345 comp.protocols.tcp-ip:1043 comp.protocols.iso:42
>> 
>> I've used TLI too.  What are you describing above?
>
>I begin to think That I don't know enough about TCP/IP to fully understand
>what you are exactly trying to accomplish, or its spesific problems/
>detils; but here goes...

You have a few things slightly confused.  I'll try to explain where in the
text.

>TLI is (as I deal with it any way) a basic way of providing description
>and contlrol of (aledgedly) any transport media.  It's purpose is to
...
>device on the other end is listening for such data, and applications
>will handle the details from there.

I can agree with this.  TLI provides a set of basic functions for establishing
and maintaining "transport" connections.

>
>TCP/IP is a media protocol which involves addressing and connection
>metenence.  It is inteneded that other protocols would be implemented
>_above_ some or all of TCP/IP.

This is where you are wrong.  Although the mapping of TCP/IP to the
ISO Reference Model isn't perfect, TCP is basically a transport protocol.
It is not a media protocol by any means.  It provides all the reliability
you assume the transport TLI wants will provide.

>
>If my perceptions are correct then trying to write a TCP/IP driver
>over a "TLI device" is a non-sequetor.  The order, top to bottom,
>of the stream should be: TLI over TCP/IP over STREAMS Device; such
>that you have a STREAMS conformant TCP/IP driver for your ethernet
>board, and then you push a custom made TLI-to-TCP/IP STREAMS module
>on the stream before you hand the connection to a TLI conformant
>application.

You wouldn't normally write a TCP/IP driver over a TLI device (but
I can see a case where you might).  All the previous discussion seemed
to be saying that a TCP/IP device would support TLI directly.  That is,
it conforms to the AT&T "Transport Provider Interface" specification which
the TLI library and modules expect.  Since TCP can be implemented to the 
TPI specification, no special conversion module is required.
>
>Were you to put TCP/IP _above_ the TLI you would already have been
>issued the sub device numbers, and already possess the connection
>(in remote startup) or be insulated form same (originating a call)

Huh?  I missed something.  When did TCP get moved above TLI.
The discussion started out about addressing being a problem with TLI
since it doesn't specify any particular format or even set down guidelines.
In all of this, TCP was below TLI and TLI was being discussed as the
way to write applications that would run over TCP/IP.

>
>The WHOLE POINT of the TLI is to remove the details of the connection
>from the application.  A TLI conformant program only needs know
>two or three things; 1) an address in "plain english" (c.f.
>something that a user could be prompted for at the keyboard);

Nowhere in the TLI specification or documentation does it state
this.  In fact, in the "Network Programmer's Guide", the example
given uses an "integer" and not something a user would normally
want to enter in at a keyboard.

I think you've missed the point of TLI or been biased by the one
transport layer implementation you seem to have used.  TLI provides a
way for an application to establish transport layer connections.
Addressing is specific to the transport protocol being used.

>2) A service code (If and only if the address can provide more than
>one service); and 3) the file-system name of a provider.

In the sense you are referring to them (RFS and the listener service)
service codes are specific to an "application" and not a transport.
The application is the listener service.  Other applications will
work differently.

>The TLI device is "opened" (cloned as necessary); the plain english
>address is passented to the driver for translation; the driver

This is not normally the case.  Look at some of the other transport
providers that AT&T uses.  They don't all work this way.  In any case,
hostname to internal address translation wouldn't be done in the
transport protocol and asking a user to enter a 12-digit hex number or
a 32-digit hex number isn't what I would call plain english.

>translates this to an address which will be useful to the rest
...
>To implement rlogin under TLI you would simply do the following:
>write rlog-serve shuch that:
...
>write rlogin such that:
...
>Add rlog-serve to the listener database on every machine which
>will accept rlogin requests (you need to know the serviec code
>to do this.) while you are doing this you record in the database
>that the listener should i_push the read()/write() module on
>the stream before starting rlog-serve.

And it wouldn't work with systems that weren't based on TLI.  Other
systems won't implement the listener service.  The listener service is
a session layer specific to some of AT&T's applications.  The rest of
the world doesn't work that way and the rest of the world's
applications outnumber the few AT&T applications.

>If you want TCP/IP and TLI stuff on the same media, you would make
>a TCP/IP STREAMS deiver for the media.  The program which oversees

Now you are confusing TLI with the transport itself.  Using TLI
as a program interface should not and must not get in the way of
using the transport protocol.  Once you get on the media, TLI is
totally irrelevant.  If it isn't, someone did something wrong.

>the TCP/IP workings establishes a TCP/IP address for the TLI
...
>(deeper) end of the module.  It would also seem that this
>'other' protocol could be anything! (X.25; TCP/IP; STARLAN;
>whatever).
>
>(Or maby not, considering I don't really know the innards
>of TCP/IP.  It may also end up that TCP is on the same
>level as TLI and that IP may be below both of them equally.
>Or TCP and TLI may be available over any media and things
>like TCP/STARLAN and TLI/IP may be possible?????????????

TCP is basically a transport.  IP is basically a network layer.
TLI is neither - it is a program interface for a tranport layer.
The issue that you missed is that TLI doesn't specify how addresses
for a specific transport should look.  Actually, TLI shouldn't
do this, there should be an address format registry that says
how to format addresses for a specific transport.

You should also be aware that Starlan is the media in you examples.
There is a transport protocol called URP sitting above the media
dependent part.  

Sorry to be so verbose, but the article prompted a comment since
it was so confused.