Responding to Dan Tobias
You raised interesting points in your correspondence with Tim that I summarize as 'Why do we need DNS?'.
First, the distributed nature of DNS allows the Registrant to control the contact data they want to put into their domain; there is no central database or directory holding this data.
This is all 'under the hood'; there could well be an Application on a web portal to provide all these good directory-style services, but this portal would query the DNS infrastructure to find the data that the Registrants have chosen to make available. Thus the web site is separate from the contacts stored. The former is a 'front end' whilst the latter remains under the control of the Registrant; what I publish is my business, not that of some directory portal. Just ask someone how hard it is to change out of date information on a portal site's database.
Second, performance is the key. In principle one could have 'the mother of all directories' and store all of the contact data in one place. However, if folks start using the directory as a normal way of contacting people, then the query rate will approach that of telephone calls. It *might* be possible to do this with an LDAP cluster, but that would be very exotic technology.
Simply dealing with the number of updates to contacts that subscribers would want would be a massive task, whilst maintaining the query load.
This is the same logic that led ENUM to use DNS as its basis. We know how to handle this level of query load, whilst allowing distributed control of the data. The mechanism of NAPTRs and standard DNS queries and responses is straightforward, even if, for ENUM, the process of mapping between an E.164 number and a domain name is not something that you'd want to do yourself.
The difference is that, in ENUM, a person's 'One Identifier' is tied to an E.164 number. The good news is that just about everything, including a standard telephone, can be used to dial a telephone number. The bad news is that it's not easy to remember someone's phone number, and they are much less 'obvious' than someone's name. Finally, in most jurisdictions, you as an individual don't have a choice of your phone number; these are under the control of your friendly National Regulatory Authority and the Service Providers. With a Telname, you have control over this, regardless of whether or not you have a phone, or whether or not you move across country and have to change your phone number.
Now to the points on vanity domains and use of the 'least significant label'. Ignoring performance issues for a moment, it is possible to use any domain to store contact information; anyone can publish NAPTR RRs in their zone. However, I don't get many queries for NAPTR on my DNS servers, because most folks don't know that I have these NAPTRs there. The goal for this sTLD is to have a single place that people 'know to look'.
It's certainly possible to use a special left-hand domain name to indicate that this is where to look for contact information. However, this could well be used to indicate the kind of 'portal' application that is to be used. It doesn't really reflect the DNS-based protocol scheme used 'under the hood'.
Thus I'd expect something like 'yellow.portal.com' for the web site, whilst the actual contact data that portal collected would be stored in various domains under .tel (for example, the Resource Records holding the contact data would be 'under' Dan.Tobias.tel'). Of course, it would be hard to specify 'yellow' as the label, as this is a trademark, but I hope this explains the difference.
A final point; the target for .tel is not really telephones. It's a place for the owner/user of telephones (and email addresses, and SIP terminals) to put their communications contacts. That registrant would put their contact information into Resource Records in 'their' domain; they wouldn't have a domain for each of their telephones.
Hope this helps