[12594] in Commercialization & Privatization of the Internet
About the creation of new 3-letter domain(s)
daemon@ATHENA.MIT.EDU (Barry Shein)
Mon May 23 21:31:59 1994
Date: Mon, 23 May 1994 14:24:50 -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 Mon, 23 May 1994 10:08:15 +0200 (GMT+0200) <Pine.3.89.9405230855.L738-0100000@newdaisy.ee.und.ac.za>
>From: Alan Barrett <barrett@daisy.ee.und.ac.za>
>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?
You don't group digits when you dial a telephone, right? The system
can understand them. The only distinction is that they are entered in
exactly one order.
The ambiguity arises only when you want to allow people to type them
in either order (since DNS would tend to want the groupings reversed
from the natural order we would type a phone number it would be nice
if software could always reverse them for us, trivially. That is,
without having to know anything about the semantics of the number.)
>What is the one ambiguous case that you referred to two or three times
>in your message?
Where the grouping on the "low" end (rightmost in typical phone number
usage) would naturally be three digits and thus you can't tell the
order because either end might be the country code, for example:
001.232.7774.044
is that a US (001) or a UK (044) number?
I am saying that this is fairly uncommon in practice (tho not
non-existant) but can be solved by just grouping the last two
together:
001.232.7774044
there, unambiguously a US number, either way it is entered
(7774044.232.001 being the other possibility.)
Another possibility is to introduce a pad character such as:
001.232.7774.#044
where '#' is defined to be ignored except when taking the length of
the first or last field to resolve the order. Because there is a # in
the last field it is "four digits long", thus cannot be mistaken for a
country code which must be 3 digits long, so we know immediately this
is a US number. Whoever is responsible for final resolution will know
to ignore the #.
I think we're down into the aesthetics. Both of these rules could
co-exist and leave it to people's tastes.
>> 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.
Sorry. I wasn't angry, I was being repetitive is all, take it more in
the monty pythian sense of hyperbolic exagerration of a point (it's a
dead, dead, dead, ex-parrot.)
>Does your proposal use the ISO 3-digit codes, or does it use the
>CCITT telephone codes, which are different?
I'd tend towards the CCITT codes, the ones we use when we make
international phone calls, since the ISO codes are not as familiar.
>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.
If I (the DNS software) know where the country code is (i.e. the order
the numbers are being presented in) then I can re-group to suit. No
string of numbers is ambiguous once I know the order.
001.6177390202
001.617.739.0202
etc.
Only the most local domain server cares about the ultimate grouping,
for example say I am in the UK and enter:
001.6177390202
the local UK server says "001"? Ok, that's a US number, pass it all to
the US server.
The US server presumably says: "001"? Yes, one of mine, what are the
next three digits to give me the area code? "617", ok that is in
massachussetts, pass it to the massachussetts server.
The Mass. server says, 001 (US, ok), 617 (yes, one of mine), ok we
have 7390202 remaining, give me the next three (because it's local and
knows the convention it wants), 739? That's a town of Brookline
number, pass it to the Brookline domain server (who looks up 0202 and
returns the IP address.)
Of course it doesn't have to be so simple-minded (the Mass server
might have the entire state's database) but the knowledge requirements
are satisfyingly localized; the UK server doesn't need to know or care
about local grouping conventions, the US server only needs to know the
next three digits are the area code and doesn't care about the rest,
the Mass server only the 3 digit exchange, finally the Brookline
server has to know how to break out the final digits but that's ok
it's an expert on Brookline.
So no matter how it's presented (but the ambiguous case) it works.
But this is why telephones work, we don't group when we enter phone
numbers either.
>Your repeating over and over that what I say is
>irrelevant, without explaining why you think that, has not been helpful.
I hope I have now made it clear and apologize for any
misunderstandings.
Consider the act of dialing a phone number, you don't group. Grouping
is only an ergonomic convenience save one case so we can figure out
which end the country code is on (if we want to allow the numbers be
entered in either order.)
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD