Responding to Dan Tobias
Hi Dan,
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
Telnic Management |