Top-Level Domains in Danger of Veering Off Course


Start with a wonderful invention: an elegant idea that works well and stands the test of time because of its original clarity of purpose. Then open it up to a hall full of well-trained elephants armed with screwdrivers, and ask them to improve the invention however they see fit.

The web is just such a wonderful invention; a visionary collection of well-designed and well-conceived protocols sitting atop the Internet, another visionary collection of well-designed and well-conceived protocols. Collectively, these protocols (and the way in which they’re put together) are the product of a highly intelligent, relatively small group of scientists.

Nowadays, however, commercial interests are overtaking good sense. Everyone and their pet elephant can propose a change to the way the net operates, and whether or not the proposal is implemented depends on whether companies can make a fast buck, not on whether it makes long-term sense. The ill-conceived .mobi top-level domain (TLD) springs to mind.

Although it's backed by a heavyweight herd of mobile phone manufacturers and operators, .mobi makes little or no sense because it demonstrates a basic misunderstanding of what TLDs were originally all about. A quick glance at the other TLDs (.com = commercial, .edu = educational, .gov = government, etc) shows that .mobi just doesn’t fit in. It’s marrying both the transport mechanism and the client platform to the TLD, which is just plain wrong.

Here’s another example – this one not driven so much by commercial interests, but by what appears to be too much “thinking” time while waiting at the Toronto airport.

Bob Zurek, IBM’s Director of Advanced Technologies with IBM Information Integration Solutions (or DOATWIIIS for short, I assume), produced an intriguing thinking-out-loud postulation and then posted it on his blog as an “informed comment”. His thought (paraphrased here): here I am sitting in the airport with my laptop connected to Verizon via my Blackberry, looking at but wouldn’t it be so much nicer if it offered a text-only version for when you’re accessing the web via a bandwidth-strangled connection? And… wouldn’t it make sense, therefore, for there to be a .txt TLD?

The requirement behind the idea isn’t bad (although as wireless “pipes” get fatter, we’re seeing less and less need for special, low-bandwidth solutions). But his proposed solution is a shockingly bad idea, and worrying for someone who fills the noteworthy role of DOATWIIIS at IBM. Perhaps someone should get their pet elephant to sit on him for a while, until he sees sense.

.txt would marry the content type to the TLD, which - just like with .mobi - is just the wrong solution, plain and simple. You’d then also need .pdf, .flash etc.

As the commenters on Bob’s blog are quick to point out, the solution to his "text-only web" woes already exists: for example; or use RSS; or even just set your browser to only accept text. (Or as another commenter pointed out, use Gopher - have fun looking for salient up-to-date content, though).

Let's pause for a moment to look at what a URL is:

<inet protocol>://<subdomain><>/<filename>.<filetype>

If you introduce a TLD only for dogs, say, then the .dog is the legal domain - i.e. which country manages the domain name. If you want a txt domain, the files should end in .txt (not the TLD). Then if you want .txt files to come up by default, you'll need to set up the welcome file list to do this. Easily achievable using today's net.

Sadly, though, I could still see domain registrars jumping on the .txt idea, because it represents a mildly plausible new source of income; a new TLD land-grab, as companies fall over each other to preserve their existing trademarked brands.

About the Author

Matt Stephens is a senior architect, programmer and project leader based in Central London. He co-wrote Agile Development with ICONIX Process, Extreme Programming Refactored, and Use Case Driven Object Modeling with UML - Theory and Practice.


Upcoming Events


Sign up for our newsletter.

I agree to this site's Privacy Policy.