Subject: [Ltru] Re: regionalisation

From: "Doug Ewell" <[email-masked]>
Date: Mon, 2 May 2005 21:44:11 -0700

JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

> We obviously have a problem of stability. I tend to think E.164 is by
> nature more stable than ISO 3166 and it is all numeric. Main area
> codes stability is actually to consider: a part from adjustments like
> in the US due to the scarcity of number in some zones, or the
> reorganisation of the French system adding a regional layer, I tend to
> think it is more stable than ISO-3166-2 which keeps fixed location,
> while area code and exchanges tend to follow the population (what
> interests us in term of language).

Sorry, I have to go a little OT here.  Apologies in advance.

About fourteen years ago, our customer base outside North America began
growing rapidly, and we had to adopt a country coding scheme.  I didn't
know anything about ISO 3166, but I knew E.164 calling codes, and chose
that as the basis for our system.  We already stored customer telephone
numbers, so the country code seemed to fit right in.

Of course, there was that nasty problem with the U.S. and Canada having
the same code (1).  I got around that by adopting the convention
Microsoft had used in MS-DOS (remember COUNTRY.SYS?), assigning 2 to
Canada.  I wonder how well it would go over in this WG to adopt a
Microsoft-specific kludge like that.

Then there were all the Caribbean island nations that were (and are)
also part of the NANP, and also used 1 as their dialing code.  Microsoft
didn't have a kludge for them, and yes, we did end up having customers
in Bermuda and the Dominican Republic.  I invented a "clever" scheme for
these that incorporated *part* of each country's area code.  (Later it
turned out that another company, which had chosen a similar E.164-based
coding scheme, randomly assigned 101, 102, 103... to these countries.)

Of course, the same problem (one code for multiple countries) also
existed for a while in the former Soviet Union.  Eventually, one by one,
most of the CIS countries broke away from 7 and were assigned their own
dialing code, although to this day Kazakhstan still shares 7 with
Russia.

Meanwhile, Czechoslovakia (42) split up into the Czech Republic (420)
and Slovakia (421), ending hopes for code stability in that area.  Our
coding system, which needed the stability, broke ranks with the external
standard and retained 42 for the Czech Republic.  Sound familiar?

The bottom line is that both systems have areas of stability and areas
of instability, and neither shows a clear advantage in that respect.
The ITU codes indeed are all numeric, as Jefsey said, but I'm not so
sure that's a good thing; they have almost no mnemonic value except to
people who often make international calls to those countries.  Many
people who have worked with our coding scheme had no other knowledge of
E.164 and thought I invented the whole thing (another "czar" syndrome).

To be perfectly honest, the more I think about the telephone-code-based
system I did devise, the more I wish I had known about ISO 3166 and used
that instead.

Area codes are another matter.  Jefsey touched briefly on the issue of
splits and overlays and area code reforms, but it is a serious
stability-breaker.  Here in Southern California, I live within 100 km of
about 11 different area codes.  Fifteen years ago there were fewer than
half.  And as far as comparisons with ISO 3166-2 are concerned, the two
systems have the same faults: very fine granularity for some countries
and very coarse for others; good stability for some and terrible
stability for others.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
(also a subscriber to TELNUM-L)

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 03 May 2005 08:16:04 +0200

Doug Ewell wrote:

> I got around that by adopting the convention Microsoft had
> used in MS-DOS (remember COUNTRY.SYS?), assigning 2 to
> Canada.

Sure, PC DOS used the same kludge, OS/2 too, in my CONFIG.SYS:

CODEPAGE=850,1004
COUNTRY=049,c:\COUNTRY.SYS

When I once asked "somebody" (now a WG member ;-) about this
bad case of "1004" (which is actually 1252, and the "850" is
actually 858) he reacted like I'm an alien.  Very embarassing.

> I wonder how well it would go over in this WG to adopt a

Very badly, probably they have patented it.  And we know that
it doesn't work as expected.  Not much worse than ISO 3166-1.

> Our coding system, which needed the stability, broke ranks
> with the external standard and retained 42 for the Czech
> Republic.  Sound familiar?

Yes.  Moral, don't abuse external sources if you don't know
how they are maintained.

> the more I think about the telephone-code-based system I did
> devise, the more I wish I had known about ISO 3166 and used
> that instead.

You'd have almost the same problems with 3166-1 alpha-2 codes,
we have discussed each and every problem in the past 30 years
with this approach.

I hope that you're all very sure about these UN numbers.  Bye.

---

From: Marion Gunn <[email-masked]>
Date: Tue, 03 May 2005 10:26:50 +0100

Scríobh Doug Ewell:
> ...
> that instead...

It was a good decision at the time, Doug, especially since the mystique
surrounding Standards and their construction/application is hardly less
now than then (at least from the point of view of the busy practitioner,
as distinct from their sometimes inexperienced compilers). 

And again, to be perfectly honest, don't most of us still think
instantly of the telephone code for the countries we most visit/contact?
I know, I still do.

Best,
mg

-- 

Marion Gunn * EGTeo (Estab.1991)
27 Páirc an Fhéithlinn, Baile an 
Bhóthair, Co. Átha Cliath, Éire.
* [email-masked] * [email-masked] *

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 03 May 2005 11:51:10 +0200

The problem is what you want to document. If people have different systems 
it is because they have different needs.

Basically you have two systems: geography and people. And a compromise 
which is countries as one think that same people assemble themselves on a 
territory. However even in periods of stability these two basis and their 
compromise tend to change.

There are therefore two problems: stability and proper granularity for the 
currently discussed issue.

1. stability when proceeding from instable tables is a common problem which 
is usually addressed in a simple manner: in associating the reference dates 
of changes. 110/1998 (21-21219)-2002(21-65439) meaning 110 was created in 
1998 with meaning 21-21219 and changed meaning to 21-65439) in 2002. 
Everyone and languages having the possibility to document 21-21219 and 
21-65439 in the way they want. To do that there is a need for an accepted 
universal tag numbering scheme. If IETF does not provide it, we will and 
support the handle system for its documentation. No big deal.

This is a simple system to maintain (it forgets nothing, it just keeps 
adding date and meanings at incremented addresses; and rebuild what 
everyone can do and compare) and to read (a few extra bytes in querry 
telling the considered year).

2.  The telephone numbering system is the oldest numbering system routing 
into Telex and ISO 3166 alpha-2 is the telex code. ITU and ISO tend to 
consider it quite stabilized in its principle. Its advantage is that it 
covers everyone down to every individual. It is necessarily related to 
populations evolution (subscribers) who tend to have a very good knowledge 
of it. In this it is better than post codes (which also are good candidates 
except the Bristish alphanumeric system and the geography oriented US 
system [you have many post codes with no population]). E.164 interest is 
also that it serves populations wich cannot use the Internet without it, 
and will therefore adapt to their changes.

The problems you rise come from an equivalent ignorance of E.164 and of ISO 
3166 and probably of X.121 at that time, and from a non-network point of 
view.  You want to cover languages issues, while we here are to cover 
network and people issues. People do not think for the world in ASCII as 
you do, they think for themselves in their own language, with their own 
needs, and their own numbers they know (usually telephone number and 
post-code, plus whatever universal number anyone could give them they would 
really use - experience and studies show that people can collectively 
remember at least 3 figures, average 5, never more than seven - same for 
names).

This WG has a charter and belongs to the IETF, not to UNICODE nor to W3C. 
It has to propose Internet standard process solutions which can scale to 
the whole Internet standard process. Regionalisation is a general need. It 
must be addressed along with the charter guidelines and with scalability, 
simplicity and network relevance in mind. Our Charter is here to protect 
consistency with the other Internet documents. We therefore need first to 
get a very good command of it, of its requirements and of its possible 
lacks we would discover and we would have to report: IESG is not God the 
Father, but we collectively are. Applying for the 11th or 12th time some 
paint on the W3C rust will neither provide a goo framework for the W3C, 
will neither make a Last Call and even if the IESG accepted it out of 
boredom would never make the market call.

Our problem is the network consistency with digital and human protocols 
(languages). This problem is not simple. Infrastructure is fixed and 
related to geography, market is related to providers and users are mobiles 
and related to registries, while numbering is in a way related to States 
which may change. Internet up to now has two responses: RFC 1591 and 
current ISO 3166 (inherited from Telex and Radio). We face a complex 
additional issue as languages develop separately with some adherence to 
geography, policy, market, etc. and have to organise this into an ASCII 
prototype structure lacking the basic network architectural tools for that.

The first work is to establish a chronological correspondance table between 
all these systems. This is needed in different areas.
- universal telephone directory (which is to be multilingual)
- same about whois and their convergence
- some digital protocol with human protocols implications
- multilingual internet or multilingual NGN or whatever avatar IETF/ITU and 
others may come with
- CRC and contexts
- applications (operating systems: locales, DNS: mlnames, network 
control/statistics, mails, web, opes/ones, etc.)

This is precisely why ICANN has been admitted in the ISO 3166 committee to 
represent us. The problem is not with not appropriate standards, the 
problem is with the fact we do not participate to these standards, but 
shout at them. Or we should ask ICANN to give its seat to IETF. Or IANA at 
least to designate a person in charge.
jfc