|
Thank you for your questions. These are subtle
points, so are addressed in turn.
1) Restricted use for Telname sTLD?
Yes - Telnic believes that there is a business case
for a Telname (name-based) mechanism to store contacts in DNS. We believe that
in this case the behaviour of the Telname system will be different from that of
a 'normal' gTLD.
The performance requirements for resolving personal
contacts can be different from 'finding' a machine IP address, and an individual
may not have a machine 'visible' on the Internet and still have personal
contacts to store in their Telname.
In many ways, resolving personal contacts in
Telnames is similar to the ENUM scheme. Both allow contacts to be stored and
queried using 'standard' DNS messages, and both are restricted in some
way.
However, there are several
differences:
(i) We believe that there should be a separation
between storage of personal contacts and machine addresses - one holds
information on me, the other holds information on my machine(s).
(ii) Performance issues are different from a
'normal' gTLD and similar to ENUM; personal lookups are likely to follow
Telephone network patterns, but machine address resolution is going to follow
normal Internet patterns. Current ENUM schemes do not have this restriction - we
believe that mixing the two is a mistake.
(iii) Phone numbers are useful NOW as an
identifier, but we expect that there will be a move towards using personal names
as identifiers - most times, people want to talk to a person, not whoever
happens to be addressed by a particular phone number. For a company, this isn't
a real issue, but for an individual, in most places you only are allowed to
register a domain in ENUM while you have a telephone service from a service
provider - that is a problem if you move and cannot take your phone number with
you.
2) No address records allowed?
We would expect that 'standard' Address records
used to map to IP addresses would be stored elsewhere from their contacts -
these are fundamentally different uses. As stated, we believe that the
traffic patterns used for DNS queries on .tel will be different in the short to
medium term from those used to lookup the IP address for a machine.
In the short term, most people will be called by
telephone numbers. We expect queries on a registrant's Telname for NAPTR, and
for most, this would result in a phone call being placed (e.g. over the existing
wireline or cellular service). A Telname lookup is a 'hybrid', with a short
Internet query, followed by a normal voice call.
Queries for A records will be done, as needed, in
other TLDs - we expect cacheing to behave differently for these lookups,
particularly with 'vanity' domains for a personal web server or for a mail
server address. Similarly, as they are introduced, SIP 'addresses of record'
would be in a NAPTR stored in a Telname, but the 'contact address' for the SIP
phone would not, nor would the IP address of that SIP phone. There are good
reasons for suggesting that such 'dynamic' information should not be published
in DNS at all; it is certainly excluded from the Telname model.
3) SRV/MX records allowed?
From the above, we expect that MX and SRV records
may be placed in Telnames, as long as the target for these records is in another
TLD.
4) Policing .tel domains?
We do not intend to scan all domains under .tel,
but will react to a complaint from an individual that a .tel domain is used
incorrectly. As just mentioned, we do this for performance concerns as well as
general principle. In the case of Telnames, the check can be done by anyone
automatically, and will be simple (and so will be quick and with low cost); it
just involves a check on the kind of resource records returned in a normal DNS
query. Note that we do not restrict the kind of content that can be provided by
a server that is referenced in a Telname - any such restriction is related to
the TLD in which the A records are stored.
We hope we have answered your
questions.
Telnic Management
|