.tel management app for iPhone: My.tel version 2

It's high time I updated the My.tel iPhone app for managing .tel domains.
I've been working on it heavily in the past couple of weeks, and it's shaping up well. I still have a lot of work to do (especially graphics work) but I've already achieved most of my goals. In fact, version 2 is going to be so powerful that I'm worried regular .tel owners will not want that kind of app. I'll probably publish a 'lite' and a 'pro' version.
Among the new features:

• support for multiple .tel accounts at multiple registrars (in process)
• support for domain display title (done)
• much more intuitive profile handling (done)
• native Google Maps instead of OpenStreetMaps (done)
• rewritten keywords section (in process)
• support for the latest record types (done)
• profile renaming (done)
• subdomain renaming (in progress)

That's about what I can remember off the top of my head. Feel free to comment and ask for other features. I can't promise anything, but you may get lucky.

Note that this will be for iPhone OS 3.0 and above unfortunately, due to a number of reasons including Google Maps support and certain other functions.

Mobile Advertising

Considering that mobile handsets are quite probably over 4 billion today, v.s. computers at 800 million pieces, mobile advertising is something of a hot potato.

But mobile advertising is much trickier than regular Web advertising for a number of reasons, most notably:

- Not all mobiles have data access
Mobiles that don't have GPRS/EDGE/3G are restricted to phone and SMS.

- Extremely varied screen sizes
Some motorola handsets have screens of 128x160 pixels. The iPhone has a touchscreen of 320x480 pixels. And there's all sorts of sizes in between and outside that range.

- Random Web support
It is so difficult to know how (if at all) the handsets will display web pages that the .mobi registry has created a specific product called Device Atlas to help developers understand the features and limitations of each device.

- Cost and speed of data access
There are now more and more "all-you-can-eat" data plans thanks to the advent of the iPhone, but this is by no means the majority. Furthermore, roaming data access remains prohibitively expensive. On a recent trip to Canada, over a period of 6 days with relatively little roaming data access, I managed to accrue a Euro 450 bill on my French SFR mobile. Talk about forgetting to acquire a local SIM card and switch my .tel domain to it (I won't make that mistake again)! Also speed is a concern, even with the latest 3G technologies that favor larger files over smaller ones: the cost of initiating a connection is high, which will happen for every ad.

A new paradigm

As we were designing the specifications for advertising on .tel domains, we decided from the start that one of the requirements would be that ads should be available directly inside the domain itself, and not just as an add-on to the web interface. Doing so would allow any native application the ability to display those ads without resorting to HTTP requests.

Beyond the obvious efficiencies in a small and fast DNS query, an additional benefit of storing the ads in the DNS (or providing a DNS interface to an ad server) is that the ads are structured data, much like an XML API for ads. So you can easily determine how you wish to display them in a native application, removing all issues of matching advert size to handset screen size at the server level.

An ad in some.domain.tel domains is a TXT record, generally stored in _ad.some.domain.tel, with the following structure:

TXT ".tad" "Version" "DisplayPreference" "Preference" "Title" "Label" "URI" "Description"

where "URI" and "Description" can be multiple consecutive key/value pairs, ensuring that both can be as long as necessary.
Specific information can be found in the full spec for ad serving in a .tel domain.

I am looking forward to seeing ad servers implement a DNS interface to their ads, and in the process making them even more suited to mobile applications of any type.

RSSCloud

(The below post is relatively technical)

Over at Dave Winer's scripting.com blog there's work being done to determine how to best discover RSS feeds and keep them up-to-date.

Mr. Winer has defined a solution which consists of the following:

- Create a web service with an HTTP-to-DNS API
- Use the above to enter in a unique subdomain a TXT record into a whose sole string is the url for the feed
- Also create an HTTP proxy service that exposes the TXT record to a web browser, when such browser is requests the subdomain

This works, except that TXT records are definitely sub-optimal for this. One should use other types of records more suitable for this, such as NAPTR records. Furthermore, if you have a .tel domain, whether the final implementation uses TXT or NAPTR records, you're already in great shape because you've already got all the tools necessary to support this.

Regarding TXT vs. NAPTR, I suggest using NAPTR records of type 'x-rss' (and also 'x-opml') such that a DNS query to (for example) rss.asseily.tel will look like this:

100 100 "u" "E2U+x-rss:http" "!^.*$!http://rikkles.blogspot.com/feeds/posts/default!" .

The DNS query to get the above is:

dig +short rss.asseily.tel naptr

A NAPTR record has the following advantages over a TXT record:

- It's got an enumservice type ('x-rss:http') which allows clients to understand what it is ('x-rss') and how to access it ('http'). TXT records don't have any of that, which can lead to much confusion unless you structure them accordingly (i.e. have multiple strings, the first one being the type).

- It's got an order and a preference (both 100 in the above case), which allows you to specify multiple ordered URLs for the same feed, and allows you to have multiple feeds in the same subdomain: each unique feed has the same unique order number, and for each unique feed you can have multiple urls ordered by preference. Note that I didn't invent this usage, it's standard for NAPTR records

- The URL that you see in the NAPTR record is actually called a 'replacement', because that's what it is. It 'replaces' the request made, and is in fact a fully qualified regular expression. In the above case, we're saying "please replace the whole query with 'http://rikkles.blogspot.com/feeds/posts/default'. The actual request made was for 'rss.asseily.tel'. That request is now replaced with the give URL. Because this is a regular expression, you could have been a lot more specific with the replacement if you wanted to

Since I'm using a .tel domain, I've got access to an API. The PHP code to create this RSS entry in the DNS is below:

include('Telhosting_Client.php');

$naptr1 = array(
'order' => '100',
'preference' => '100',
'services' => 'E2U+x-rss:http',
'flags' => 'u',
'regexp' => '!^.*$!http://rikkles.blogspot.com/feeds/posts/default!',
'owner' => '@',
'profiles' => '_all_',
);

$config = array();
$config['login'] = '****';
$config['password'] = '****';
$config['wsdl'] = 'my.wsdl';
$domain = 'rss.asseily.tel';

$client = new Telhosting_client($config);
$client->store_record($domain, 'naptr', $naptr1);

Can't be much simpler than that...

Apologies to my iPhone users

Well I'd like to apologize to the users of my iPhone apps, My.tel and Superbook.
I know that there's a critical crashing bug in My.tel version 1.0.1 as it currently stands on the app store. I'm sorry that I missed that bug when testing the app. It triggers when you're updating a contact record and change its type (say from "Skype IM" to "Skype Voice").
As soon as I was told of the crash, I fixed it. It's a simple 3-line change. I re-uploaded a new version, 1.0.2, to the app store right away. At that time Apple added a new feature when uploading apps, called "Keywords". You can now add keywords to your apps for better searching on the app store (that's assuming search works properly, but it doesn't). Well, I added a few keywords like ".tel, telnic, unified messaging, AIM, Skype". Things that I thought were relevant.

Fast forward to today, which is 21 days after I submitted my 3-line change. The app still isn't approved. Of course I had zero feedback from Apple. I sent emails, and I know that some of my users sent emails as well. So now I have to figure out why in the nine hells it's taking so long, without any feedback. Welcome to the world of the Apple AppStore.

I also have a big update to Superbook will a bunch of new features that's also in limbo. That one has been lingering for over two weeks. So I decided today to reject my uploaded binaries, get rid of the keywords, and re-upload them. This also reset the clock for approval time, so in the best of cases, it will have been one month to get a 3-line change through the Apple process.

Lovely.

Sorry my dear users, but all I can say is "it's out of my hands".

Update sept 5 2009: Less than 24 hours after I wiped the keywords and resubmitted a new binary, Apple approved My.tel. But Superbook is still in the process.

Moral of the story: Don't even try to guess what Apple is doing, I don't think Apple even knows itself.

Idiot's guide to Webfinger and .tel

Webfinger:



.tel: