[12584] 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)
Mon May 23 09:35:38 1994

Date: Mon, 23 May 1994 10:08:15 +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: <199405222042.AA28366@world.std.com>

Barry,

> You don't have to get the grouping RIGHT, the only reason the issue
> comes up is that there exists one and only one case in the entire
> universe that is ambiguous.

Well, if one doesn't need to get the grouping right, then indeed my
objections fall away.  Why doesn't one need to get the grouping right?

What is the one ambiguous case that you referred to two or three times
in your message?

> Have I made myself clear? This is a non-issue, an imaginary tempest in
> an imaginary teapot, a red herring, a straw man.
> 
> So even showing that grouping can vary or whatever proves absolutely
> nothing about the original question/issue.

There's no need to get so angry.  I am not arguing against your
proposal; I don't even know what your proposal is.  I am trying to
address the apparent differences between your and my perceptions of the
international telephone numbering system.  I was under the impression
that your proposal relied on some features that you and I seem to see
differently, so I thought that our difference in perceptions would
impact your proposal; if that is not the case, then there is no problem.

> Perhaps CONVENTIONS FOR WRITING country codes vary, but ISO and CCITT
> recognize one and only one 3-digit set of codes. A common convention
> for writing country codes is +NN as in +44 for the UK but there is no
> "+" on your phone so obviously it's only a visual convention.

I believe that ISO has a set of 3-digit codes, a set of 2-letter codes
and a set of 3-letter codes for countries; and that CCITT has a set
of variable-length digit codes for telephone dialing areas.  I think
that the relevant standards are ISO-3166 and CCITT-E.163, but I don't
have copies of the standards; my source is the files available from
ftp://lcs.mit.edu/telecom-archives/country.codes/.

Does your proposal use the ISO 3-digit codes, or does it use the
CCITT telephone codes, which are different?

> All you have noticed is that leading zeros can be dropped when writing
> them down (and perhaps in dialing), thus you can write 044 (UK) as 44
> or +44.
> It's still 044 and there are good reasons to insist on returning the
> zeros to their proper place in this scheme.

I didn't drop the leading zero; it was never there in the first place.
If you want to insert leading zeros, I believe that that will not
introduce any ambiguity.

The telephone code for UK is 44, without a leading zero, and writing it
as +44 is conventional.  How to dial it varies; from the USA, I believe
it's something like 011-44, and from South Africa it's 09-44.

The ISO 3-digit code for the UK is 826, which is very different from 44
or 044.

> Somewhere there has to be a few rules, all we can hope for are that
> the rules are very simple, very consistent, and easy to understand.
> 
> These rules are very simple, consistent, etc.
> 
> Country codes are 3 digits (add zeros if needed, eg, +44 is entered
> 044, +1 is entered 001, there are no special cases), and if the phone
> number grouping you are accustomed to results in the last part of the
> number ending in 3 digits then coalesce it with the next-to-last
> grouping.
> 
> Period, that's it, that covers all possible ambiguities etc.

Those rules, plus some local conventions to handle difficult cases,
will cover generating the domainised form of a telephone number by
somebody who knows the local conventions, but they don't cover doing so
by somebody who does not know the local conventions.  I have been trying
to show that the local conventions are complex, and difficult for an
outsider to know.

> >> 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.
> 
> Which is equivalent to saying that any grouping will do, other than
> the one ambiguous case.

It seems to me that any grouping will do, provided there is a simple
and unambiguous way of determining what grouping to use.  I have been
trying to explain that I don't think that there is any such simple and
unambiguous way, unless either you know the local conventions that apply
to the digit string you are trying to divide into groups, or you group
each digit separately.

If the lack of a simple way for an outsider to determine what grouping
to use is not a problem for your scheme, whatever it might be, then I
would like to hear why.  Your repeating over and over that what I say is
irrelevant, without explaining why you think that, has not been helpful.

--apb (Alan Barrett)

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