Received: by maskin (mbox dlanor)
 (with Cubic Circle's cucipop (v1.31 1998/05/13) Sun Apr  4 14:38:12 1999)
X-From_: owner-stik-beta-testers@list.zetnet.co.uk Sun Apr  4 06:58:22 1999
Received: (from uucp@localhost)
	by maskin.ettnet.se (8.9.1a/8.8.8) id GAA09832
	for <dlanor@oden.se>; Sun, 4 Apr 1999 06:58:22 +0200 (MET DST)
Received: from UNKNOWN(194.247.47.34), claiming to be "spodden.zetnet.co.uk"
 via SMTP by maskin, id smtpdAAAa002Pa; Sun Apr  4 06:58:20 1999
Received: from majordom by spodden.zetnet.co.uk with local (Exim 2.05 #1 (Debian))
	id 10TezD-0000fP-00; Sun, 4 Apr 1999 05:58:19 +0100
Received: from dilbert.netset.com [206.183.227.13] (baldrick)
	by spodden.zetnet.co.uk with esmtp (Exim 2.05 #1 (Debian))
	id 10TezC-0000fG-00; Sun, 4 Apr 1999 05:58:18 +0100
Received: from localhost (baldrick@localhost) by dilbert.netset.com (8.8.8/+dilbert+) with ESMTP id XAA11209 for <stik-beta-testers@list.zetnet.co.uk>; Sat, 3 Apr 1999 23:58:17 -0500
Date: Sat, 3 Apr 1999 23:58:17 -0500 (EST)
From: Dan Ackerman <baldrick@netset.com>
To: stik-beta-testers@list.zetnet.co.uk
Subject: Re: Question about CNgetinfo under STiNG
In-Reply-To: <199904031342.PAA19145@maskin.ettnet.se>
Message-ID: <Pine.LNX.4.10.9904032331140.10968-100000@dilbert.netset.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-stik-beta-testers@list.zetnet.co.uk
X-Loop: stik-beta-testers@list.zetnet.co.uk
Precedence: bulk
Reply-To: stik-beta-testers@list.zetnet.co.uk


	I generally cut your messages as I hate 24k emails floating down
the pike.  I'm not the only one,  that's why this list has shrunk to the
size it is. lp and others left because they got sick of downloading huge
messages arguing about how many angles can dance on the head of a pin.

	Now you get in a huff about multiple IP addresses.  But under any
normal applications, clients only see one IP address on a machine.
Whether it's implicit or broght back from the resolution of an ip address.
It's possible to look at the other IP address, but in general for a client
it's not necessary or worthwhile to do so.

	I originally typed in a very long message quoting large sections
from Wright/Stevens and the actual BSD code.  Then I stoped myself.  Why
it's not of interest to most of the people on this list and frankly I
don't care.  If you don't want to fix something in STiNG, then don't fix
it.  Just don't complain when something doesn't run on it.  Many
programmers that we have on this API don't program for either STiK or
STiNG they program for GlueSTiK.  They don't care what super slick options
you put into STiNG.

	In the past several of us suggested you consult linux et al, on
the functioning of your masquerade.stx.  Your reply was they did it wrong.
I still have the message in my mailbox here if you want me to refresh your
memory.   All I can suggest is that you do that.  'Masquerading' if you
want to call it that, existed on other stacks before you wrote your own
layer,and they don't require special modifications to the clients.

	I really hate arguing with you, in general it's been pointless.
I pointed out an initial problem with the CNgetinfo call, to which I was
told it was done for internal functions  STiNG.  Well if it was internal
then why didn't you just do a wrapper call?  It would't have added much
code and would have remained compatible with the STiK API.  I think it was
modified to become incompatible with the STiK API.  But it backfired.
This is the reason that AtarIRC has problems with STiNG.  Peter didn't
bother telling anyone.  He put it into a HYP that many of us have never
downloaded let alone read.   When I pointed it out to him, he was pretty
hot.  And you know what?  He doesn't plan on changing it.  If you read his
doc file, you will find that it warns that AtarIRC is not STiNG
compatible.  This is not the only application that this problem comes in.

	I know there are work arounds, but frankly the market is so small
anymore I really don't care.  I know that sounds really sad, but it's
true.  

	All I can say is if you don't want to look at any of the other
implementations of masquerading, then at least look at RFC 1631.  It's not
the best RFC in the world, but it at least describes some of the steps
that are necessary in the route you have taken.

	And if you don't want to fix the CIB, then I guess thats ok to.
I'll just start putting qualifiers on projects.  It's not a threat, it's
just a basic statement.  Right now I have to scan for Peter's name and
implement code specifically for getting the info in STinG.  The recent
scare of peter, stressed the fact, that it's not a good plan to do that.

	Sorry if I caused any distress or unhappiness.  I'll go back to
reading this list on rare occasions and not participating;)

	Dan



---------------------------------------------------------------------------
To unsubscribe from this list, e-mail Majordomo@list.zetnet.co.uk
with the body of the message containing "unsubscribe Stik-Beta-Testers"
---------------------------------------------------------------------------

.
