PK> The issue ONLY appears for INCORRECTLY CONFIGURED mailers, and it
 PK> is only the NEW SYSOP within Fidonet Aus that is likely to miss the
 PK> point and can be stung by this issue, and New Sysops are exactly
 PK> the ones that NEED protecting, not the experienced Sysop.

 ml> errrmmm... this same problem exists for every entry in 
 ml> the nodelist, 

 PK> No it does not, and don't try and sweep it under the rug that way.

i'm not trying to trivialize this particular situation... please don't take
me that way...

 PK> If a new sysop in North America tries to dial a Node in India and
 PK> ends up dialing the PSTN no. 911 repeatedly, then I am pretty sure
 PK> he may be in a spot of bother over this error, so YES a different
 PK> version of the SAME issue can happen there was well. 

exactly... and the india situation was the FIRST one back in the day...

 PK> The DIFFERENCE between these 2 scenarios that I am trying to point
 PK> out is that the North American issue is as a result of PUBLISHED
 PK> and KNOWN standards, whereas the Aussi issue only happens because
 PK> of the stuffing of an INVALID country dial-code into the Nodelist. 

remember, the nodelist is not governed by telcos and their numbering
plans... the nodelist is governed by fidonet and fidonet standards...

 ml> then... not the specific problem of dialing emergency services but 
 ml> there is still the same basic problem if one does not have their 
 ml> dialing tables set up properly...

 PK> So you agree that we should do all things possible to minimise the
 PK> impact of incorrectly configred nodes? 

i agree that all nodes need to be properly taught and trained in the
configuration of their mailer software (at least), yes... i do _not_
believe, however, that we should remove /possible/ obstacles... no one
removed the 91-1 stuff for any Z1 nodes... no one did anything about the
first ISDN ONLY nodes that were listed that a POTS system could not connect
with... however, once their specifics were known, then folk were taught
about them and life went on... before then, some folk did get bit and a few
rather hard but no one helped them repair that wound they suffered...

 PK> Great, get rid of 000 in the Nodelist. 

sorry, no... that is the =one= main thing that my mailer's POTS side uses
to determine if it should hold mail for a system or not... my mailer's IP
side uses 000- and the ITN and IVM flags to determine if the IP side can
connect to a remote system or not...

 ml> so.... what it _really_ comes down to is that it is /not/ a 
 ml> *technical* problem but a social problem where one hasn't been 
 ml> taught or learned to completely configure their software before 
 ml> using it as well as a second social problem of letting the machine 
 ml> have its head without sufficient monitoring...

 PK> Absolutely, that has never been denied. 

some would have others believe differently... some are sticklers for
technical situations and are backing this to the hilt for various
reasons... none of those reasons are technical, though... but they'd like
"you" to believe it...

 PK> So rather than force the problem back on the new Sysop, 

no one is forcing the problem on anyone... as long as they enter the arena
with full knowledge, there is nothing being forced... it is no different
than what you and i went thru when we joined the network, is it?

 PK> Fidonet should do all it can to minimise the potential for 
 PK> error, the best way to do that is to remove all INVALID 
 PK> ISTD codes in the Nodelist. 

hahaha... if that "minimizing potential for error" is the main
basis, then practically /ALL/ software in fidonet should be banned for
cause... i'm not even going to try to start naming any particular packages
but everyone knows about the message base regurgitations that occured
regularly when new versions of certain packages were released... everyone
already knows about the problems with messages larger than 8k... no, umm...
16k... no... hummm... 32k... wait a minnit! what is the largest message
allowed by the standards?? [/me scratchs his head] should i even broach the
incessant netmail routing problems that have plagued this network for
almost as long as it has existed??

 PK> I am glad you recognise that this non-technical "problem" can be
 PK> minimised by some logcal thinking.

i'm glad you put the word "problem" in its respective place...
between quotes to show that it is not truely a problem ;)

now, tell me something... my mailer doesn't have to use 000- as a country
code indicator for IP nodes... it is a fully configurable option... so that
i and others who run mailers of similar setup to mine, do not have to
kludge things together, what would you propose we, fidonet, use in the
phone number field, since that is the *ONLY* place that my system can get
the POTS number, the IP number or the IP domain name from, to indicate that
the system is POTS or IP based???

and before ANYone spouts up with "use a shim to translate your
nodelist," i want to fully remind them that fidonet was not designed
for any system to have to use a shim or anything else to edit their local
nodelist so that they could contact any node in the network that they have
a compatible method for... that is pure fecal material and wasn't ever
suggested back when ISDN nodes started appearing (thanks to the then Z2C)
so why should it start now??

)\/(ark