Hi Mark,

 ml> 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. 

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

While that is true, the Telephone no. field was designed BY FIDONET for
PSTN no.'s to be recorded. As it happens, the entire 000-* string is NOT a
phone number at all. Yes, that field is heavily utilised for IP nodes these
days, however ideally Fidonet should not be in this position, but we are...

 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...

And that is the point I am trying to make, by default the string in that
field is taken to hold a Telephone no. for PSTN use, and an IP address is
not exactly a Telephone no., AND the CORRECT use of a 000-* string REQUIRES
a Sysop to know more than they are expected to know about telephone no.'s
in that field.


 ml> i agree that all nodes need to be properly taught and trained in the 
 ml> configuration of their mailer software (at least), 
 ml> yes... i do _not_ believe, however, that we should 
 ml> remove /possible/ obstacles... 

Including the installation of a non-PSTN Phone no. in that field???

 ml> no one removed the 91-1 stuff for any Z1 nodes... 

Well 91-1 is perfectly VALID as a prefix for a Telephone no., it just
happens to conflict with the use of those digits in just ONE part of the
world.

One could compare the action of the Z3C to remove the 000-* issue from the
Z3 version of the Nodelist, with the apparent inaction by the Z1C to do
similar for Z1? The reason (to me) seems fairly logical, it is probably a
more common situation (within Z1) to handle 91-1 as a special case, than it
is for Aus Sysops to handle 000-*, as no "normal" Dialing
directory contains 000-* numbers anywhere (except within Fidonet).


 ml> no one did anything about the 
 ml> first ISDN ONLY nodes that were listed that a POTS 
 ml> system could not connect with... however, once their 
 ml> specifics were known, then folk were taught about them 
 ml> and life went on... 

While it is a similar situation, the ISDN issue is much closer to
conventional POTS use and other "workarounds" (notably a speed of
300) were used to handle that situation.


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

 ml> sorry, no... 

I sort of expected that reply........;-)


 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...

Well it IS a technical problem (mixing PSTN and IP info in the one field),
but it has larger Social ramifications that appears as a "by
product" of its use...


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

 ml> no one is forcing the problem on anyone... as long as 
 ml> they enter the arena with full knowledge, there is 
 ml> nothing being forced... 

I guess we view it quite different then.......;-(

 ml> it is no different than what 
 ml> you and i went thru when we joined the network, is it?

Yes it is different, Fidonet was nothing but PSTN at that stage........;-)
IP entries in the Phone number field are just another classic example of a
Kludge used "to get things working"...


 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. 

 ml> hahaha... if that "minimizing potential for error" is the
main basis, 
 ml> then practically /ALL/ software in fidonet should be 
 ml> banned for cause... 

Careful, I didn't say "eliminate" I said "minimise", to
me there is quite a difference to those words...


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

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

Perhaps I should have used UPPER CASE instead of quotes, because it really
is a problem.......;-)


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

Simple, dont use the Phone number field for IP info, put the IP info in a
valid and acceptable place such as in a FLAG.

 ml> and before ANYone spouts up with "use a shim to 
 ml> translate your nodelist," i want to fully remind them 
 ml> that fidonet was not designed for any system to have to 
 ml> use a shim or anything else to edit their local 
 ml> nodelist so that they could contact any node in the 
 ml> network that they have a compatible method for... 

That happens solely because Fidonet was not DESIGNED to use IP, and the
000-* is a classic "kuldge" to work around that
"issue".



 ml> is pure fecal material and wasn't ever suggested back 
 ml> when ISDN nodes started appearing (thanks to the then 
 ml> Z2C) so why should it start now??

I am not sure even today how it would have been possible to introduce ISDN
without conflict...

Cheers............pk.


--- Maximus/2 3.01