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@128.129.130.131? 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.