to name or not name

Hans-Werner Braun hwb at
Fri Jul 28 17:04:24 UTC 1995

I have an idea. Lets create a .ssn domain. Better yet, lets assume
everything plain numeric is an SSN. As you all know, Vixie's SSN is
123-45-6789. Consider that address to be a middle level. At the bottom you
need something that maps it to where, e.g., he can find his email. When he
wants to hang out in his hotel in Costa Rica tomorrow, he may have to remap
123456789, so things can be found wherever he really wants them. Probably a
host on the hotel's HIPPI switch. Point is, at the identifier-to-location
mapping, things have to be flexible enough to easily and quickly be updated.
Kind of like cellular auto-roaming. May be he can even use his cellular
phone to beacon around where he is *really* located, so the mapper finds
him, and so he may not have to do much explicitly.

I, as someone who may want to send him email, should never ever even have to
know his SSN specifically, because above the unique-person identifier would
be a relational data base that allows my Vixie-{plus-
whatever-other-attributes-I-choose} to be mapped to his ID, perhaps
confirming something back with me if there is not a 1-to-1 mapping between
my request and a response. Besides, it is hard enough to remember my own
SSN, why would I want to remember his?

So, a unique ID would be a funneling point in the middle, that opens up to
both the top and the bottom. Kind of like IP numeric addresses are (or
should be), where the number should not really matter, but can be mapped to
something on the link/physical level (e.g., Ethernet MAC), and is being
utilized (also for mapping purposes) by higher level applications. Really,
when was the last time you sent email to vixie!vixiehome at
You know, you can reach him there, didn't you?

May mean you have to give machines social security numbers as well, as you
may have to address more generic resources (humans are just one
instantiation) before too long.

If such a system were in place, one could consider that there is really no
need for such a thing as a COMPANY.COM. In reality one could send structured
requests to some DB server, similar to what X.500 attempted, but perhaps a
little more arbitrary/dynamic/hierarchical/whatever. Like, I may want to
send email to the teacher of one of my children in grade x of school y,
perhaps with some more attributes, may be I don't know the teacher's name,
though, and somewhere there is some magic in the system that makes it all
work. Or to the company of the laptop I bought a few weeks back, because the
screen is busted already: I know the company name, I know what my problem
is, that should be good enough to get it to the right person with the right
unique ID (or group of IDs/people), and if there are any ambiguities, the
translater/mapper could ask me questions (like, there may  be no company
with the name I gave it, but three choices of similar names; or two of
identical names, but in different countries).

A silly name like ABCDEF.COM is just absolutely meaningless to me, and the
strict binding is going down a dangerous path. If only because people even
bind it into there products and there is no way in hell they will change
things later withough at least a fight (and probably umpteen thousand
lawyers). That system has neither technical nor administrative scaling
properties that will match the real world requirements. There is ways too
much trash and leftovers in the system that nobody is cleaning up, or has
the authority or guts to do so, and  many figures presented  could probably
use a multiplication factor (which may have to include a 0 or more).

Uh, and considering to cover only the 95th percentile of the companies is
just asking for trouble, as viable and defensible as this may be, technically.

I for one would not be suprise that if we continue current practice, 5-10
years down the road, above the 95th percentile of names could be just plain
trash. Whatever system we come up with will have to account for that.

More information about the NANOG mailing list