[12578] in Commercialization & Privatization of the Internet
About the creation of new 3-letter domain(s)
daemon@ATHENA.MIT.EDU (Barry Shein)
Sun May 22 23:37:24 1994
Date: Sun, 22 May 1994 16:42:54 -0400
From: bzs@world.std.com (Barry Shein)
To: barrett@daisy.ee.und.ac.za
Cc: com-priv@psi.com
In-Reply-To: Alan Barrett's message of Sun, 22 May 1994 13:34:53 +0200 (GMT+0200) <Pine.3.89.9405221157.K738-0100000@newdaisy.ee.und.ac.za>
>From: Alan Barrett <barrett@daisy.ee.und.ac.za>
>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.
Once you see a trailing 3-digit grouping you'd know that the answer is
that you need to coalesce the last two groups. That works.
That's a far smaller search space than wondering if Moscow is moscow,
mockba, msk, etc. You have the right digits, you have them in the
right order, the only possible question is the grouping used.
Since the same string of digits will never address two different sites
(that is, 1-234-5678 will never refer to something different than
123-45-678, the grouping alone won't do that) any sensible system
should let you type in any unambiguous grouping (e.g.
joe@011.12345678) and be able to understand that. Any further grouping
is for your own convenience (it's easier, visually, to check shorter
strings of digits), the system should not care.
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.
So this is all a red herring, it's irrelevant, it is not an objection.
It is entirely artificial and for absolutely no rational reason this
one single ambiguity has now been generalized into "but you have to
get the grouping right and that presents the following problems..."
when that's just not true, it's not necessary, there is no problem,
there is no objection, any grouping SAVE THAT ONE AMBIGUOUS CASE works
fine, it's only a human convenience.
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.
Done, period.
I am just cutting this off because perhaps it's an interesting topic
but it's being presented, to the more casual observer, as if this is
an objection that refutes the proposal when in fact it isn't, it's
just a purely tangential chit-chat.
>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.
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.
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. It's not hard to remember
you need three digits so if you want to enter 44 you must enter 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.
Now show me any other scheme for dealing with domain names whose
entire set of possible ambiguities can be reduced to two simple rules
expressible in one sentence like that.
Show me how to even begin to resolve the ambiguity inherent betweeen
moscow, moskva, mockba, msk, etc. for every city and town in the world
by just using a rule as simple as the two I present for resolving
ambiguity in the phone number scheme: Country codes are exactly three
digits padded left with one or two zeros if needed, if the number ends
in three digits then coalesce it with the previous group so it's not
confused with a country code. Thus you can enter them in either order,
the software will (trivially) do the rest.
>> 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.
tpc.int uses ".tpc.int" to unambiguously indicate which order the
number was written and to flag the software that it's this kind of
domain.
I am saying with these two very simple rules you can drop the
extraneous .tpc.int, it's over-kill and awkward and unnecessary, and
write them however you like other than the one ambiguous case.
The fact that they're all digits indicates it's a phone number domain
if we just adopt the already well-established convention that numeric
IP addresses must have [] around them (RFC822 already requires that
numeric IP addresses be expressed as mbox@[IP-NUMBER], just extend
that case to all contexts rather than just email.)
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
