Friday, June 20, 2008

Last stretch before ICANN

Well that was a long week of final touches on our website before ICANN (and that's why I didn't update the blog). It will be released at this weekend, with everything a registrar would ever want to know about how to gear up for .tel.

Next up, the ICANN conference, then the release of our NSP software and all the goodies for developers!


Ellie said...

Somewhere in the FAQ you should mention that because the technology is based on DNS it's compatible with any IP-enabled OS (such as MacOS, Linux, etc.) as individual users will wonder about that.

Also there should be a clear explanation of whether or not individual domains can be delegated to non-Telnic servers. I'm guessing from my past experience with the project that this will be possible, but for many users this will be significant in deciding whether to adopt dotTel or go with a more proprietary web-based solution.

Apart from these minor niggles it's a good site which does an excellent job of getting the proposition across. I'm particularly pleased to see the clear commitment to a developer community, a project which was very close to the heart of Julian Rose.

Good luck with the ICANN conference!

anonymous said...

Will .tel support OpenID?

Rik said...

OpenID is a shared identity service, fundamentally different from .tel which is a communications convergence and discovery platform.

Now OpenID and .tel can interoperate in multiple ways:

1- publishing one's OpenID URL on one's .tel:

This is possible and encouraged, and could ultimately simplify the openid urls: an application can discover your openid url by simply requesting the relevant naptr records in your .tel.

2- Using OpenID to log in to the .tel management console (otherwise called the "provisioning system")

I can't guarantee the feasibility of this because a registrar or reseller can elect to host his own management console, and therefore elect to use (or not) OpenID independently.

3- Using OpenID to log in to the .tel friending system

This is currently not possible in our internal betas, and we're looking into this option, but there are issues when logging in through our API: how does one pass through an API request to an OpenID provider for identification?