Hello Bj”rn.

30 Mar 06 12:17, you wrote to me:

 MvdV>> I concentrated on the main issue: configuring a system as to
 MvdV>> make this possible. As for accidentally setting the crash
 MvdV>> attribute; it happens. We all have seen numerous examples, even
 MvdV>> from those that should be a long way from the starting point of
 MvdV>> the learning curve.

 BF>    Ah, c'mon now Michiel! Surely you really don't believe that?

No I do not believe it, I *know* it!

 BF> To be able to get a nodenumber you have to prove (for a reason!) that
 BF> you can send a crash mail to your host.

Yes....

 BF> That alone should prove that you know all about a simple thing like
 BF> configuring your mailer to properly process the phone number field.

No, it just poves that the new sysop can send a crash message to his host.
It does not prove that he knows how to NOT send a message crash.

And you forget points. They too use the nodelist and can send (inadvertent)
crash messages. It *has* happened. Denying is useless.


 BF>>>    I think it was brilliant in all it's logic. IP-numbers are
 BF>>> phone numbers on the internet and what country code would be
 BF>>> more logical for internet than 000?

 MvdV>> It may have looked liked a good idea at the time,

 BF>    Only a "good" idea?

Indeed, no more.

 BF> Where's that logically thinking, technically versed friend of mine,
 BF> that I thought I knew? Surely you must admitthat this is the most
 BF> logical way to put internet connection data into our nodelist?

I admit nothing of the kind. On the contrary, I say it goes against all
logic. IP numbers should NOT be in the telephone number field for the
simple reason that they are NOT telephone numbers.

 MvdV>> the results are unpredictable. As for 000, the logical
 MvdV>> assigment for that is the access code for out of planet
 MvdV>> dialling.

 BF>    I take it then, that your InterMail never had JoHo's '000-
 BF> internet' conversation incorporated in it,

No, why should it? It is a POTS mailer, designed to make connection via
classic modem.


 MvdV>> Indeed. When experimenting to find new and better ways one
 MvdV>> should however also be prepaired to drop methods that on
 MvdV>> investigation turn out to be not such a good idEa after all
 MvdV>> instead of foolhardedly insisting on it.

 BF>    If the only reason for an idea to be judged as "not
good" is that
 BF> some ignorant Aussie sysop,

It is not the only reason.

 MvdV>> Because developers and programmers arent clearvoyant. When they
 MvdV>> developed those mailers, they expected *dialable* phone numbers
 MvdV>> in the phone number field, except for the string -Unpublished-.
 MvdV>> They never expected someone to put non dialable numbers in
 MvdV>> there and so they did not take measures to see tha it is
 MvdV>> handled properly.

 BF>    So when someone comes up with a method, that fits perfectly well
 BF> into what those old developers designed,

It does NOT fit perfectly well into what those old developeres designed. On
the contary , it *conflicts* with it.

 BF>  don't you think this should be encouraged rather than rejected for

No, I do not think that methods that conflict with existing practise should
be encouraged.

 BF>    Using 000 to indicate IP numbers *does* work with several of those
 BF> old mailers,

It conflicts with existing practise.


 MvdV>> 1) There are mailers out there that have no documented way of
 MvdV>> stopPing

 MvdV>> 2) There is only room in the phone number field for ONE entry.
 MvdV>> That

 BF>    Jeezzz, man! 1) all mailers convert the raw phone number data from
 BF> the nodelist,

You conveniently ignore the essence of my argument. Converting the number
does not stop the mailer from attempting to dial *something*.

 BF>  and 2) do you really think that having dual entries for
 BF> POTS and IP is that a big issue?

Yes I think it is. Again you ignore the gist of my argument. having
individual dual entries for POTS and IP forces the user to manually
intervene in choosing to which nodenumber to reroute the message instead of
letting the software decide. I consider that a MAJOR inconvience.

Your own situation is a good example. You write from 203/2. If ai want to
sent you a private crash message in response and hit the appropritae
button, my software will address it to 203/2 getting the address from the
origin line. But that node number is not binkp adressable. I manually have
to search the nodelist for an aks of yours that supports Binkp and manulaly
readdress it. a MAJOR inconvienense!

 BF>  At least *I* think there are much more obvious garbage in our
 BF> nodelist than that. Including flags, so many and so long, that some
 BF> people even suggest that we must extend the present line length
 BF> limitation of the nodelist to accommodate them.

Two wrongs dont make a right.

Michiel

--- GoldED+/W32 1.1.5-0613