[12500] in Commercialization & Privatization of the Internet
Re:About the creation of new 3-letter domain(s)
daemon@ATHENA.MIT.EDU (Barry Shein)
Thu May 19 19:27:38 1994
Date: Wed, 18 May 1994 02:11:24 -0400
From: bzs@world.std.com (Barry Shein)
To: dcrocker@mordor.stanford.edu
Cc: dfazio@mr.net, com-priv@psi.com
In-Reply-To: Dave Crocker's message of Tue, 17 May 1994 21:08:16 -0700 <a9ff429110021011f95e@[128.102.17.23]>
>From: dcrocker@mordor.stanford.edu (Dave Crocker)
>No, I'm afraid it's not. If you are going to suggest use of an existing
>labeling scheme, then familiarity of that scheme is part of its strength.
>If you start changing it, the benefit from the familiarity is vastly
>reduced.
I accept your conservatism implicitly and agree in principle 100%.
Ok, let's consider using phone numbers backwards to preserve DNS
hierarchical order, within DNS, WITH THE ADDED GOAL that a design
should strive to make it as simple as possible for software that deals
with humans to let them type them and read them in either order.
Thus we have saved current DNS practice and the idea stands with only
one remaining design problem:
How to indicate how tuple order is being presented so it can be
DNS-normalized if needed (i.e. reversed.)
Not a horrid problem I don't think, pick a lexical hook:
Only exactly one of the leftmost or rightmost tuple may be exactly
three digits in length (i.e. the country code, US=001.)
Perhaps that doesn't quite do it but it's a start. We need a pad
character for phone numbers that really do end (least significant
part) in three digits. Does this case actually come up (it's not like
the world's phone systems are a vast unknown)? Does anyone believe
this is an insoluble nit?
Further:
Any address presented as all digits is henceforth presumed to be a
phone-number-domain unless enclosed in square brackets (in which case
it is presumed to be a numeric IP address.)
>>None of that seems daunting to me when compared with changes that
>>would be necessitated by other proposed schemes.
>
>Ummm. Please describe the 'changes' that are required by the
>geographic/postal scheme.
"Changes" was a poor choice of word (or I have forgotten why I used
that word.) It would seem to require a much more complex set of rules
for choosing an address properly than "just pick a phone number and
present it thusly".
The basic rules are immediately intuitive to anyone who knows their
own phone system or the phone system of the country code. You replace
all runs of one or more non-digit characters each with a dot. Thus:
+1 408-246-8253 -> 011.408.246.8253
+44 071-935 9191 -> 044.071.935.9191
etc. Or, in DNS-normal order:
+1 408-246-8253 -> 8253.246.408.011
+44 071-935 9191 -> 9191.935.071.044
Also, as AT&T et al no doubt have noticed:
Strings of digits are far more internationalized than postal
addresses.
Even where a nation does not natively use "arabic" numerals (what we
use, Arabic countries use something else) they are generally familiar
anyhow, or trivially mapped onto locally known glyphs digit for digit
(is that true? I suspect it is but I'll defer to others for comment.)
For example, why *is* Algeria ".dz" (ISO two-letter)? I assume there's
some good explanation, perhaps it involves a knowledge of Arabic? Do I
need to negotiate that at every level in a geographic address? Will we
insist on English? Is there any int'l standard for geographic naming
we can appeal to? Is it .moscow. or .moskva. or do we allow both? What
about glyphs in geographic names that don't map well onto Latin-1 or
some such?
Use digits. Use phone numbers. Let human interface software provide
other presentations like we all do now with phone number files.
Let's admit it, the phone companies over the past 100 years basically
got it right. Or as right as we're likely to ever get it.
And, once again, it lets us use the phone company's directory services
for name space management and discovery. And they don't even need to
know they are involved (tho that could get interesting.)
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
