mark@cbosgd.UUCP (01/25/84)
This is in response to a discussion trying to form in net.bugs.uucp
and net.unix-wizards in which it is advocated that the subdomain of
UUCP should be structured by telephone area codes. The discussion
belongs here in net.mail.
This whole subject was hashed out at UniForum. One thing we learned is
that the more people you get involved, the more flaming you get and the
less you get accomplished. Thus, we do not consider the subject open
to debate on Usenet. If someone has what they feel is a wonderful
technical solution which is different than what is currently planned,
they should send us mail (there will be a mailing list on cbosgd shortly
for those participating - send me mail for the name). If you are
interested in volunteering time to work on the effort, please let me
know.
The domain structure that has been decided upon is "ad-hoc". This basically
means that we structure the first layer of domains (20 or so - the exact
number is flexible) any way that seems appropriate, and each one
structures its subdomains as that domain sees fit. In practice, what
will probably occur is that each large cluster of UUCP hosts that
want to band together as a subdomain will set up a registry, pick a
domain name, meet whatever requirements their parent domain establish,
and they are a subdomain. The subdomains of UUCP are likely to be
structured around major hosts, e.g. decvax, ihnp4, whatever, with
names which are somehow significant of the area, e.g. ne (New England)
or att (AT&T).
Obviously, if a subdomain wants to declare that they represent area
code 617 and call themselves the 617 domain, (e.g. 617.UUCP), as long
as they meet the requirements of their parent domain, they can do this.
However, I'm not about to force all subdomains to number themselves.
There are too many situations where it's downright inappropriate.
Consider:
(a) The usual argument that people remember names better than numbers.
(b) There are too many area codes, creating too many regions for top level.
Most area codes have nothing in them. Many have only a few sites, not
enough for a responsible person or subdomain. A few may have too many
sites (e.g. 201) and want a few subdomains.
(c) The notion of area code does not extend past North America. Indeed, if
this scheme were to be used, it would have to be a 2nd level subdomain,
using country codes above them, and possibly even continent codes above
the country codes. And of course Europe would not be forced to use
area codes since they don't have them and since our subdomain can't
force some other subdomain to conform to our weird rules.
(d) There are many situations where you want a domain that does not fit
in one area code, e.g. AT&T will want to be a domain, so will DEC,
Subdomains will no doubt include Interactive Systems, Sun, HP, and
lots of other geographically distributed organizations. (Of course,
a site or subdomain can have more than one parent, allowing it to
appear as a subdomain to more than one domain, but requiring
everyone to use area codes precludes any other possibilities.)
Another example is Colorado, which has one area code, but AT&T IS
in Denver is completely separate from (and will not talk to) the
other Colorado hosts.
(e) We want a scheme that at least approximates the physical connections,
so that heuristic mail routing software will do a reasonable job if
it just goes up and down the domain tree. Area codes have poor
correlation with typical physical links - for example, Silicon Valley
is best kept together, but part is in 415 and part in 408.
(f) People are poo-poo-ing the notion of having a responsible person and
a nameserver, as if these were not hard and fast requirements. I'd
like to point out that we have to meet the requirements of OUR parent
domain (ARPA) which requires both.
(g) Finally, the syntax (213)vortex would never work. Not only is it
incompatible with the word.word.word domain syntax specified in RFC819,
but the UNIX shell would go nuts when it saw the parentheses.
Finally, I am not the "powers that be". We do have project, manned by
volunteers willing to put in time and effort, which will produce a map
and mail software to use it. If you are interested in participating,
great, please send me mail. If not, your comments are appreciated but
the members of the project will decide what to actually do. If you don't
like what the project comes up with, you are welcome to produce something
you feel is better and put it into the public domain. However, it would
be more productive to cooperate with one effort.
Mark Horton