Xref: utzoo comp.dcom.lans:1621 comp.protocols.tcp-ip:4204 comp.protocols.iso:129
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!amdcad!sun!aeras!elxsi!beatnix!mre
From: mre@beatnix.UUCP (Mike Eisler)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)
Message-ID: <851@elxsi.UUCP>
Date: 25 Jul 88 19:56:46 GMT
References: <60781@sun.uucp> <1110@nusdhub.UUCP>
Sender: news@elxsi.UUCP
Reply-To: mre@beatnix.UUCP (Mike Eisler)
Organization: ELXSI Super Computers, San Jose
Lines: 99

In article <1110@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>The fact that all you have ever seen of TCP/IP drivers written as
>TLI conformant functions pass the four byte addresses as actual
>bytes instead of a string like "109.90.42.6" is simply sad.  In

First of all, it is NOT adequate to pass 4 bytes. You need the Internet
address plus the 2 bytes of port number that TCP service is listening.
I'll agree that 109.90.42.6 is a commonly used, standard, clean way to
pass an address to a driver.  But I know of no commonly used form
concatenates port numbers and "dot" addresses.

>essence this breaks the aledged uniformity.  To implement the

What unformity? Where is there a standard written for specifying addresses
to TCP/IP TLI conformant streams drivers? 

>TCP/IP and TLI over the same media, the primitive kernel driver
>should be TCP/IP, and then a streams module which can convert
>TLI requests into TCP/IP should be written.  TCP/IP _is more_
>complex, and therefore, to implement both TLI should be an
>optional addition onto the TCP/IP.  Then you place 109.90.42.6

What does complexity of TCP/IP have to do with whether TLI should be an
option. What's complex, the protocol implementation, or the interface?
If starlan and TCP/IP can both use the same interface, TLI, then they
their interfaces are equally complex, and so by your logic all TLI
compliant protocols should be implemented as two halves, your symbolic
"uniforum half" and the half that everybody currently implements. Bye, bye
performance.

>As I said, doing TCP/IP _over_ TLI is stupid.  They are *comprable*

By this statement, I think you mean that to implement a TCP/IP
protocol in user-land on top of some TLI compliant media driver (eg.
X.25, ethernet, etc.) is stupid. I'm not so sure I agree. Somebody
may want to proto-type a TCP/IP implementation first on a particular
computer, before investing in the increased costs of kernel
development and debugging, especially on a 3b2. :-)

>in form and purpose, and TLI _is_ designed to be more "elementary"
>than TCP/IP.  Trying to squese TCP/IP through TLI is like hooking

Hey what exactly are you talking about anyway? TLI is comparable to TCP/IP?
TLI is an interface. TCP/IP is a protocol. TCP/IP under TLI
is an implementation.

>The *purpose* of TLI _is_ to insulate you form the uglies ...

>... Depending on what is required, you might
>need to set an address like "109.94.60.2:rlogin" to properly implement

You are assuming that this is the standard address representation for
the login service residing on 109.94.60.2. I've never seen this format
before. Vendors could implement infinite, incompatible variations of
this ascii string format, eg: rlogin:109.94.60.2, 513.109.94.60.2,
2.1.109.94.60.1, 109.95.60.1:2.1, etc.

>TLI through TCP/IP, or perhaps place something similar in the Dialers
>spec, but I don't really know because I have not expended any energy on
>the topic outside this conversation.
>
>All of this is much the purpose of the "adm" program which assembles
>the STREAMS modules which eventually make /dev/starlan operate
>the STARLAN product.  I would assume the correct "adm" program
>for an ethernet and/or internet support would activate two STREAMS
>multiplexers like /dev/ether.tcp and /dev/ether.tli or some such.

First you said that the *purpose* of TLI is to insulate you from
"uglies" than you say that it is the purpose of the of "adm" program.
Which is it?  The "adm" program isn't on my copy of 5.3 source, so I
assume it is something specific to starlan that assembles streams
drivers and modules, and/or does name resolution. The various STREAMS
TCP packages have similar tools and services to do the same, but
difference is that Starlan has virtually one manufacturer and is
proprietary to AT&T.  AT&T can therefore enforce a standard address
encoding that will be recognizable to all applications that use it on
all machines that use those applications, eg. RFS. And I guess it is
the "adm" program that embodies this enforcement.

TCP has perhaps a half dozen or so suppliers of STREAMS
implementations, each with their own "adm" thing and address encoding
formats. The point is that without a well-defined, agreed upon
standard, regardless of whether the encoding uses nice ASCII strings,
or binary strings, each implementer is going to use his own encoding
mechanism, resulting in incomptabilities.

Telling me that TLI has solved this problem for me, because it solves
it for the protocol you use (starlan), doesn't cut it. I'm using an
open protocol that others are free to implement.  If AT&T wants TLI to
be the standard, then they should enhance it to define specifics for
commonly used protocols (TCP, ISO/OSI/ X.25, SNA, DECNET). AT&T did
this for starlan, why can't they do it for TLI?

Sockets, for all the trashing people have done on them, do define and
enforce address encodings for at least two protocols (XNS, TCP). Hence,
everybody can rlogin, telnet, rcp, ftp, smtp, NFS, RPC, etc. to each
other, as long as these things are built on sockets. That's not the
case for RFS built on TLI over TCP.

	-Mike Eisler