[12574] in Commercialization & Privatization of the Internet

home help back first fref pref prev next nref lref last post

Re: About the creation of new 3-letter domain(s)

daemon@ATHENA.MIT.EDU (Alan Barrett)
Sun May 22 15:07:57 1994

Date: Sun, 22 May 1994 13:34:53 +0200 (GMT+0200)
From: Alan Barrett <barrett@daisy.ee.und.ac.za>
To: Barry Shein <bzs@world.std.com>
Cc: com-priv@psi.com
In-Reply-To: <199405202136.AA12784@world.std.com>

Barry Shein said:
> >The very fact that there's no official standard for grouping digits in a
> >phone number strikes me as a difficulty for your scheme.  Given a phone
> >number, how will anybody know how to choose between the many possible
> >domainised forms?  For example, does the phone number 1234567 map to the
> >domain 4567.123?  67.45.123? something else?
> 
> Again, this is a nit based on a rather rare example that is actually a
> worse problem with other schemes, one has to look at it that way to be
> practical. Remember the .moscow. vs .moskva. vs .msk. vs .mockba.
> example? And that objection arises absolutely everywhere.

Perhaps I don't understand what you want to achieve, but I really don't
see much difference between the problems with choosing between .msk,
.moscow, etc., on the one hand, and the problems with choosing between
4567.123, 67.45.123, etc., on the other hand.  In both cases, if you
live there, you have a fair chance of knowing the local convention; and
in both cases, if you don't live there, you need to look up the local
convention in a database before you can convert an address or phone
number to domainised form.

Even if I tell you that +273152xxxx should be grouped as +27-31-52-xxxx,
you still don't know how to group +273253xxxx.  (This is a genuine
example, and the answer is +27-325-3-xxxx, BTW.)

> I find it a little hard to believe that people actually randomly group
> digits in the location you describe.
> I can believe there is more than one local convention. Maybe two or
> three in actuality?

It's not entirely random, no, but there are several methods.  The
way the telco writes it in the phone directory almost always ends
with a group of 4 digits, but users of the numbers often write them
without any grouping at all, and sometimes write or speak them in their
advertising in a way designed to highlight patterns that make the
number easier to remember (hypothetical examples are 22-33-44 instead
of 22-3344, or 222-333 instead of 22-2333).  Even in the USA, they
advertise 800-COLLECT instead of 800-COL-LECT.

> I also believe grouping, in general, is much stronger and more
> intuitive with phone numbers than any other system anyone has proposed

In the USA, perhaps.  Around here, we recognise strong divisions between
the country code (if any), the area code within the country, and the
local number within the area code; but the divisions (if any) within the
local number are not strong, and the divisions between area code and
local number are not intuitive.  Area codes in South Africa (country
code +27) vary in length between 2 and 7 digits, and some long dialing
codes are extensions of shorter dialing codes (the worst example of this
that I found was +27-15 (Levubu), +27-152 (Lenyenye), +27-1523 (Letaba)
and +27-1523552 (Lenyenye farm lines)).  Numbers within dialing codes in
South Africa vary in length between 1 digit and 7 digits.

> However, other than the 3-digit country code, your suggestion could be
> a fallback for very hard cases tho I think there are easier solutions.

Country codes vary in length from 1 digit (+1 for the USA/Canada and +7
for the ex-USSR) to 7 digits (+3966982 for the Vatican City State), with
most country codes being either 2 or 3 digits.  Some long country codes
are extensions of shorter country codes (Italy is +39 and the Vatican
City State is +3966982; USA/Canada is +1 and Jamaica is +1809; France is
+33 and Monaco is +3393; etc.).  The long country codes could probably
be handled as if they were area codes within a country with a shorter
code, but things appear complicated.

> When you dial a telephone there is no grouping

Exactly.  I believe that that's one of the reasons why tpc.int chose not
to use grouping.

--apb (Alan Barrett)

home help back first fref pref prev next nref lref last post