Zu Dokumentationszwecken folgt hier ein Ausschnitt aus der „tcp-group“-Mailingliste. Ende der 1980er Jahre diskutierten Brian Kantor und andere über die Notwendigkeit von Subdomains innerhalb von „ampr.org“:
Date: Thu, 1 Jun 89 09:11:30 PDT
From: brian@ucsd.edu (Brian Kantor)
Message-Id: <8906011611.AA14158@ucsd.edu>
To: pacbell!noe!marc
Subject: Why 'norcal.ampr.org' does not exist. (again)
The problem with 'callsign.norcal.ampr.org' (or any other regional
or organizational subdomain in ampr.org) is that it's both
counterintuitive and unnecessary to name a host that way.
A fully-qualified domain name consists of all parts of a hostname
up to the implied root of the domain tree. Thus 'wombat.ucsd.edu'
is fully qualified and it is unique - there is only one 'wombat'
in the 'ucsd.edu' domain, and there is only one 'ucsd' in the 'edu'
domain, and there is only one 'edu' at the root of the domain tree.
Similarly there is only one 'org' at the root, one 'ampr' in 'org',
and since callsigns are unique worldwide, only one 'wb6cyt' in
'ampr.org'. There is no reason to add in a regional domain name
somewhere along the line; there will NEVER be another 'wb6cyt',
nor another 'u2mir', etc. Thus 'norcal' is unnecessary.
When your hostname is in the same domain as the hostname that you
wish to refer to, you may omit the common parts. Thus here at UCSD
I may refer to 'wombat.ucsd.edu' simply as 'wombat'; the 'ucsd.edu'
part is assumed because it is common to both it and my hostname.
Similarly, I can refer to any amateur station in the world simply
by using its callsign; 'w1aw' is unique, as is 'wn6cum' or 'ua3xyz'.
I do NOT have to specify the country, state, geographical reference,
etc. 'u2mir in earth orbit' isn't necessary to uniquely identify
the station. In fact, were some geographical or organizational
reference required, it would be counterintuitive: when I wanted to
refer to KB1UK, would I have to specify Rhode Island, which my
callbook lists as his mailing address, New Mexico which is where
his permanent station location is, UCSD where he lives when he is
attending classes during the school year, or the South Pole, where
he currently is? And how would I know? To require a geographical
subdomain in order to specify a hostname requires the I have some
way to KNOW what that subdomain is ahead of time - and that is
knowledge that I simply do not have for the majority of stations,
and certainly not when first attempting to contact them. Organizational
references would be worse: would I have to know whether you consider
your primary affilition to be the ARRL, AMSAT, or LuNaTiC before
I could contact you?
And that's why most of us don't support regional or organizational
subdomains within AMPR.ORG.
As for multiple hosts per callsign, that is handled by making a
CALLSIGN subdomain, and placing the hosts within it: pc.wb6cyt.ampr.org,
3b2.wb6cyt, etc, and always providing ONE of them with a nickname
the same as the domain - so that an attempt to contact wb6cyt.ampr.org
becomes a contact with whichever machine I (as wb6cyt) have designated
as the machine to do that. Using MX (Mail eXchanger) records in
the nameserver system, I can even give a LIST of hostnames (in
preference order) for your software to try when making mail deliveries.
Brian Kantor WB6CYT UC San Diego brian@ucsd.edu
------------------------------
Message-Id: <8906020612.AA02531@erendira.arc.nasa.gov>
To: brian@ucsd.edu (Brian Kantor)
Cc: tcp-group@ucsd.edu
Subject: Re: Why 'norcal.ampr.org' does not exist. (again)
In-Reply-To: Your message of Thu, 01 Jun 89 09:11:30 -0700.
<8906011611.AA14158@ucsd.edu>
Date: Thu, 01 Jun 89 23:12:40 -0700
From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
Brian, I agree with the gist of your argument, but in a practical sense,
I think subdomains are needed. Do you really think that you can have one
or 2 nameservers for ampr.org that contain RR's for EVERY station? That's
going to be huge and unwieldy to manage. It's like having all systems
at universities have unique names and be directly in the edu domain.
It's certainly doable, but not practical. Then there is the problem
of having AMPRNET not connected, and thus possibly not being able to reach
top level servers to get such information. Having local regional nameservers
makes it easier to reach them, and easier to deal with all the connectivity
problems we have (Class A net number not helping).
Thanks,
Milo
------------------------------
Date: Fri, 2 Jun 89 08:47:21 PDT
From: brian@ucsd.edu (Brian Kantor)
Message-Id: <8906021547.AA15875@ucsd.edu>
To: tcp-group
Subject: Nameservice for AMPR
The plan is to have a few (two for now) 'master' nameservers, and
lots of regional nameservers. This will work while the network is
small.
The real difficulty is that the design of the DNS doesn't include
the concept of what we need to do - which is to regionalize the
database without having to compartmentalize the namespace by using
subdomains. What we need is the ability to do zone transfers for
pseudo-zones and assemble them into one large zone.
I can solve the problem (after a fashion) by making lots of subdomains
and transferring those to the master server, then analyzing the
data received and creating top-level CNAME RRs for every entry in
the subdomains. Such a solution might well work; it wouldn't work
well, and the concept horrifies me.
I'm open to ideas to solve the problem, but I refuse to bend the human
interface to fit an improper solution - and that's the position you're
suggesting. Remember that the computer is here to solve our problems,
not we its.
- Brian
------------------------------
Date: 4 Jul 91 13:46:12 GMT
From: brian@ucsd.Edu (Brian Kantor)
Subject: Why is the ampr.org namespace flat?
To: mail-tcp-group@ucsd.edu
The AMPR.ORG namespace is flat at the first level so that using it will
be the same as using callsigns. There is NO NEED to make it more complex,
since callsigns are already unique worldwide.
So, you can have
wb6cyt.ampr.org
pc.wb6cyt.ampr.org
Other than typing exercise, why would you want it otherwise?
Remember, names are not routes. Names imply addresses. Addresses are not
routes either.
I'm sorry to report: it's a bad idea. Let's just gently forget about it.
- Brian
------------------------------
Date: 6 Jul 91 05:24:48 GMT
From: brian@ucsd.Edu (Brian Kantor)
Subject: Why is the ampr.org namespace flat?
To: mail-tcp-group@ucsd.edu
Just because we're currently using the hack of routing network 44 as
though it were a bunch of subnets doesn't mean we'll always be doing
that. I believe that routing should be taking place at the transport
(AX.25) level, below the IP level, and that would make the IP address
space flat too. Someday we may be able to do it.
- Brian