Hello Carol.

29 Oct 02 19:07, you wrote to me:

 MG>> It's time to drop this "solution" that is a
non-solution, and look
 MG>> for better ways to solve the problem.

 CS> Ok, come up with one.  I'm all ears!  Find a way to update 9,000 or so
 CS> sysops with a new program without losing most of them.  Meantime, the
 CS> advancement has been in keeping them all able to function for now
 CS> without problem while allowing the newer set a way to play.

I've already suggested a solution. A new nodelist compiler, that will allow
IP based mailers to take advantage of all their capabilities, yet will also
make translations for older POTS based mailers. Such a program will allow
us to make any changes we want to the nodelist, yet will still keep
compatibility with the older POTS mailers, and it will easily do away with
the need to use a Pvt kludge for full time IP based nodes. It needs to be a
two-pronged program, one part for *C's, and another for end nodes, but it
is a /real/ solution that can work.

I lack the programming skill, otherwise I would be attempting to write such
a program already.

 MG>>> worse. The PVT kludg is /unacceptable/, and a much better
 MG>>> solution needs to be found.

 CS> Then make one.

First, attitudes have to change (which is what I'm attempting to do right
now); mainly the attitude of "do nothing, there is no problem with IP
listings", which is /absolutely/ false, and is designed to keep IP
nodes' concerns subjugated to the concerns of POTS nodes, creating a class
structure whereby POTS nodes are first-class nodes, and IP nodes are
second-class nodes.(*All* nodes /MUST/ be treated equally!!) Secondly, a
committee should be formed to decide on what changes will be made to the
nodelist, and a group of developers needs to work together with that
committee to acheive the solution. IMO, in the best interests of Fidonet,
it should be an open source development.

 MG>> they ought not to be running a mailer. Any cost incurred by
 MG>> their mis- is their /own fault/, and is /not/ the fault of any
 MG>> listing. To push t a that anything else is true is to shirk the
 MG>> individual's responsibili

 CS> The listings need to be compliant enough that everyone world-wide
 CS> knows what to block at need.  Sofar, that is 000- and whatever else
 CS> might be needed for one's local area.

I started out intending to use 000-000-0000, but people screamed that it
wasn't correct, then I looked in the nodelist and saw that many RC's were
using 1-000- for RIN's and that it had been going on for quite some time,
and I'd seen no complaints, so I used that. Only recently, have people
started making a big issue out of it. What about before? No one seemed to
have any problems for months and months before, when they didn't notice it.
It's only those who wish to stomp on any attempt by IP based nodes to find
a half-decent solution who seem to have a problem with it; I've yet to hear
from /any/ single individual that claims my listing has directly affected
him or her; if I had, I'd have changed my listing long ago.

I will go back to 000-000-0000, but I will /NOT/ use a Pvt flag with my IP
listing, because my system is /not/ Pvt. There /is/ a difference between
Pvt IP nodes and full-time IP nodes, and lumping them all into the Pvt flag
is *dead* wrong.

--- GoldED/386 3.0.1-dam3