FAQ

A typical top-level domain (TLD) stores IP addresses in the DNS and returns them when queried. The .tel DNS prohibits storage of A-records (address records) and operates with other record types: NAPTR, TXT and LOC to enable direct storage of contact data; see Record Types.

Shortly and in connection with .tel domains: NAPTR records are communications-specific type/value pairs that can be ordered. For example, you could have a phone number (one NAPTR of type "voice:tel" with value "+13105551212"), followed by an email address (another NAPTR of type "email:mailto" and value "a@b.com"). You can also label each NAPTR record, for example the phone number could be labeled "my home".

Another key benefit of NAPTR records is their extensibility. New NAPTR types can be created as new means of communications are developed, making the .tel solution a very powerful long-term communications hub.

The full definition of a NAPTR record, in the Wiki.

No. All you need to know is how to interpret the DNS query results, and we will provide you with libraries and sample code for that. You surely do not need to know the complexities of the DNS infrastructure, but it may be generally a good idea to learn how things work at some point, and that includes DNS basics. For a list of useful materials about the DNS, see External Links.

There is no restriction as to what DNS server software to use. However, some older DNS servers may be incompatible with the EDNS0 standard necessary for proper hosting of a .tel zone file. If your DNS server is relatively up-to-date (within the past few years), it supports EDNS0. If your DNS server is older than that, you probably have major security holes that need patching!

Owners of .tel domains may not want to share their data with every Internet user; to restrict data access, the .tel platform includes a "friending" mechanism based on data encryption. Please see a high-level explanation at the Security page and more in the blog entry about the privacy model by Telnic Ltd. CTO, Henri Asseily.

.tel puts you in control of your communications and allows you to centrally manage and securely publish all your means of communications. OpenID solves a totally different problem, which is cross-site authentication, otherwise called "single sign-on". See the Wikipedia article on OpenID for more information.

The TelHosting Software application is responsible for managing the content of a user's domain. Registrars maintaining .tel domains need this application to support additional .tel functionality.

The TelHosting Software is written in cross-platform Java and uses Apache Tomcat application server, JAX-WS security module, and other open-source Java components. The TelHosting Software is provided in its entirety in an Open Source license as well.

TelHosting Software has a web interface for accessing .tel domain data directly via a web browser. Client applications interact with the TelHosting software via a standardized SOAP API.

Yes, the API reference is available online and for download for all developer community members.

Everybody is welcome to join the community. To sign up, fill in the simple registration form. Your account is created immediately. You can specify an email address, time zone, and other preferences for your account.

Signing up for the community is totally free and instantenous. An account at the community website enables you to write to the forums, edit Wiki pages, and submit tickets to the tracker. You can also create custom ticket reports and subscribe to your customized RSS feeds.

All community members are contributors and have access to all community resources, including source code, APIs, samples, and test harness.

Based on the principle of meritocracy, an active contributor who makes stable and valuable contributions through the forum and bug tracker can be elected committer. Committers are just like any other contributor, but they have write access to SVN and are generally highly respected in the community.

A committer is an honorary title, not an official job or role. If you have been contributing to .tel application development, have demonstrated dedication to the project and regularity of contributions, you are sure to be elected committer. If you feel that despite your efforts, your contributions are not properly rewarded, please speak up at the forum. The committers group is willing to see new members join and can help you up your path.

For a complete list of currently available applications, please see the .tel applications page. To get a plug-in or client, click the button at the bottom of the page describing the plug-in. Read the description of the application for installation and configuration instructions.
More applicaitons may be under development; please check the forum for latest news.

Please use the services in the Developers Area to report the issue via the forum or as an issue ticket. The community will be glad to help you. For questions on obtaining .tel domains, please refer to Telnic Support Team.

You are very welcome to edit any client application you fancy, expand its functionality or change the way it works. For that, check out the source code from our public SVN as described on our wiki. When you are ready to share your code with us, please submit a ticket through the bug tracker.

Yes, all client applications will be published in binary and source code format. Some of the applications may not have reached the release stage, but we plan to share whatever code and ideas we have for all our .tel applications. In addition, SDKs, custom libs and other tools will be provided in binary and source formats.

All available applications are supported by the developer community, and new applications may become available as we progress with launching the .tel domain. For the latest news on upcoming releases, please see the developer forums.

You can write your .tel apps in any language. However, some of them are more suited to the network-centric environment of .tel: your job will be much easier with a modern DNS library for reading .tel info, and a HTTP(S) + SOAP library to access the TelHosting API and friending system.

Our open-sourced applications are written in C#/.Net for the Outlook plug-in and Windows Mobile, C++ for the Blackberry, and Java for the TelHosting platform. Check back often in the developer area for more sample code in other languages (some iPhone Objective-C code is on the way).

There are three main components to the .tel ecosystem:

1. A published .tel zone on the DNS cloud
2. A TelHosting web service to edit .tel data
3. A friending system web service to edit friend relationships

The first component is accessed via DNS, while the other two via HTTP+SOAP. You can integrate any one of those components independently with your own web services.

No. Any application that has network access can take advantage of .tel.

Simply store your customers' .tel domain names in your CRM. Then whenever you need to contact them, have the CRM backend make a DNS call to the .tel domain and grab the latest updated contact information. You'll never have obsolete contact information again. See the downloadable Outlook plug-in for an in-depth integration example.

Another interesting integration point is to communicate via SOAP with the TelHosting platform and friending system to have your CRM users manage their own .tel from within the CRM software.

Computer telephony integration is similar to CRM applications: since a DNS call is very quick, instead of retrieving someone's potentially incorrect phone number from your internal database, retrieve a correct one from his or her .tel.

No, .tel client applications are released under the Telnic license, which is not modeled after GPL. Please read the license agreement for details.

Complete these three steps:
- Add the HTTP basic authentication header of the format
"Authorization: Basic ZnJlZDp0aGF0cyBtZQ==" Where the encrypted string is Base64 encoded version of username+':'+password
- Create your SOAP string and put it in as a POST variable in your request
- Make the URL of the request be a POST request to the SOAP action you want

Use DIG/nslookup commands and query _soap._nspapi.yourTelDomain.tel.
The returned records should point to the addresses of the endpoint, such as http://MyTelProvider:80/client

• https://soap.telfriends.tel/member?wsdl
• https://soap.telfriends.tel/init?wsdl
• For VIP.tel domains: http://members-soap.vip.tel/member?wsdl, http://members-soap.vip.tel/init?wsdl

The TelHosting platform uses SOAP 1.2, the official SOAP 1.2 HTTP binding is "http://www.w3.org/2003/05/soap/bindings/HTTP/", see http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp.
If your environment is using SOAP 1.1, it may prompt to change to "http://schemas.xmlsoap.org/soap/http/", which is the SOAP 1.1 HTTP binding. Operation of SOAP interfaces with 1.1 binding is not guaranteed.

In addition to current applications that you can re-use, the following tools are available:

• Perl to HTML
• Amended OpenSSL
• iPhone SDK with a sample application
• C/C++ lib for DNS lookups (.tel utils)
• Java lib for DNS lookups

See full details at http://dev.telnic.org/pages/tools.html.

Credentials required for the web interface and the SOAP API init operations (Client Initialization) are the user's web credentials (web username and web password).

Credentials required for Tel User Management (http://members-soap.vip.tel:80/member) are the API credentials (SO ID and API password). These are determined using the Client Inialization operations.

See Telnic Developers Manual, http://dev.telnic.org/docs/devguide.pdf section 6.1, "SO Authentication" for details. The "API credentials" are also required for Key Store, Message Store and Publisher Store operations.

Call the login method, then use the returned cookie for all subsequent methods.

Store the credentials in the HTTP Headers using BasicAuth. Credentials should be always sent on every SOAP query.

In SOAP, use exportData() and importData(). JSON does not have support for bulk import/export.

As the attribute in the element naptr id="", not in storerecordrequest.

Rkey, see details in the SO API reference, http://dev.telnic.org/api/so-soap/public_private.html.

No set limit, except FQDN must be 253 bytes.

Use _all_, not all.

Set owner="@" for root, otherwise, sub-domain name.

In a secret subdomain created for each Reader of private data. A DNS lookup command for that sub-domain returns encrypted NAPTRs that the client needs to decode using the appropriate key. The subdomain and key are retrieved via the TelFriends SOAP API. See more details in the Developer Guide, page 14, section 5.3 and the Privacy whitepaper.

For the moment no, even when a telfriends account is deleted, the username remains in the system and cannot be re-used. This may change in the future.