Netcentric View:

Do EMBedded devices need their own Top Level Domain?

By Bernard Cole
iApplianceWeb
(11/26/04, 03:10:52 PM GMT)

There’s been a lot of activity on the World Wide Web about the subject of top level domain names.  And this has made me think about the usefulness of a top level domain designation for connected embedded devices -- .emb perhaps?  

However, the critical assessments given to such proposals by ICANN, WW3, and other Web authorities means there must be very good reasons for granting such a status. 

Beyond the original .com, .gov, .edu, .org and .net there is now .pw, .name, .pro, .aero, .biz, .coop, .info, .int, .mil and .museum with several others in various stages of the approval process, including .asia, .cat, .jobs, .mail, .post, .travel, .xxx, and two competing .tel domains. 

Also, a group of mobile phone and wireless converged appliance makers and vendors, led by Nokia, Microsoft, HP and Sun have proposed a new .mobi TLD  for all things mobile. In addition, Saipan Datacom, acting as domain administrator and registrar for the U.S. Commonwealth  of the Northern Mariana Islands, has proposed using its country code --.mp – as a mobile phone device top level domain. 

The main technical argument that the .mobi activists propose in its favor is that mobile devices will ultimately be used as personal Web servers and other repositories of Internet documents, replacing traditional stationary desktops and servers. 

And because they are mobile, the argument goes, the way domain name server (DNS) architecture works for domains like .com and .net is unsuitable, since it takes up to 48 hours for IP address changes to propagate on the Internet.

However, mobile devices, by definition, move. So, if one is designated as a server, its IP address  would be changing on a regular basis, such as when it is turned off, when it moves through a tunnel or is in some situation where connectivity is lost, requiring almost real time updates of IP addresses.  

As pointed out by WWW-originator Tim Berners-Lee in a recent article, other than this, the major reasons proposed by the consortium for approving the .mobi TLD are largely non-technical.  

While there are a modicum of benefits to the end user,  he says, virtually all benefits accrue to mobile content and service providers, mobile operators, mobile device manufacturers and vendors, and IT technology and software vendors who serve the mobile community.  

Nor is there anything in the technical reasons they advance to justify the TLD, he believes, that could not be achieved in some other way. 

“The success of the Web stems from its universality as do most of the architectural constraints,” he says. “The Web must operate independently of the hardware, software or network used to access it....”  

I am not an expert, but I believe that a .emb TLD might be an exception to this rule, precisely because the way connected embedded microcontroller devices interact with the Web seems to me to be so fundamentally different.  

For one thing, there is the relationship between the server and the device. In a sense, the server is now a client to the embedded device, which in turn is providing content to the server.

In a normal desktop/mobile transaction with a server, the assumption is made that the time frame is a one or two second human interval at the very least. And the negotiation process usually involves the client browser requesting some sort of action from the server, usually in the form of some HTML presentation.  

In a connected embedded device context, the negotiation is exactly the opposite. The request can come from either the embedded device or from the server. If the first, it is the controller requesting access so that it can deliver information to the server.

If the server, it is requesting that the controller present data to it in the proper format. If the embedded developer has incorporated a minimalist servlet program on the device, information collected is organized into an HTML format for delivery to the server where it is acted upon, either at the time of the request, afterwards, or in anticipation of the request. 

Even at its slowest non-real time, non-deterministic, an embedded microcontroller will still require actions from the server that are anywhere from ten to 100 times as fast as the 2-3 second response time built into most human-interaction Web activities.  

But with the proliferation of RFID, ID tags will be embedded in virtually every piece of goods shipped. And wireless protocols such as Zigbee will eventually link millions of embedded controllers to the network. In such an environment, servers will also have special responsibilities not only for those specialized transactions, but as well for security, identification and status. 

With IPv6, and the 340 billion billion billion billion unique URLs it makes available, the sheer numbers of connected and uniquely identified embedded devices presents special issues that dictate the servers responsible for them -- and possibly the TLD in which they reside -- have special characteristics.

For one thing, given the real time, deterministic nature of embedded controllers, the servers would have to take care to map their location as completely and as often as is possible. That implies, an absolute requirement for servers with 64 bit CPUs with some special modifications to their multithreading, multitasking structure.  

In the present IPv4 environment, the latency time for a server that must map much of the URL universe in DRAM as possible is limited because 32 bit servers have a theoretical limit of 2³² bits of directly accessible DRAM. Therefore, they must use disk based virtual memory and suffer the latencies that involves. The 2⁶⁴ bits of directly addressable memory of 64 bit servers would do much to eliminate such latencies.  

Another factor that might dictate a shift to a special .emb TLD is the nature of the server to server negotiations that must support any device/server transaction.   

Let’s be conservatively realistic and assume there is a company which has deployed 1,000,000 refrigerators with microcontrollers that have Internet access. Suppose that 1 percent of them, or 100,000, reported a problem and each expects a response within a tenth of a second. That's 100 -1000 times slower than a microcontroller's normal response time.

It seems to me that the dynamics of such an environment are vastly different that the normal client/server transaction. 

Even more so in a Web services environment where the server will have to maintain specialized business to business linkages with other servers, calling for services in a time frame that is short enough to either download a new fix, or direct that an automated call be sent to the home telling the owner that the refrigerator is not working, that it is being fixed, or when it will be fixed.  

Perhaps some of the alternatives proposed by Berners-Lee might solve the problems of client-side server/server-side client interactions that seem to me to be so unique.  

For example, there are the CC/PP specifications, which provide a framework for a client device to describe its capabilities in great detail to a server. Another alternative that could be adapted might be the UAPROF (User Agent Profile) specifications developed by the mobile phone industry. Also, the HTTP specification has a content negotiation mechanism which allows a device to give a simple profile of its capabilities whenever it asks for some information. 

But it seems to me that there is more than enough about this new kind of device/server interaction to warrant some further investigation.

I understand the need to focus on maintaining the universality of the Web and Internet by making them as hardware- and software-independent as possible. And that sort of discipline should always be uppermost in any decisions related to modifying the Internet and Web standards.

But given the sheer size of the coming IPv6 Web/Internet, that should only be a goal to work for, not an absolute. After all, the Internet began as an "inter-network" -- a grid of cooperating proprietary networks for which the common set of protocols was developed to allow dissimilar networks and systems to talk to each other when necessary.

By and large most of the devices and systems on the Internet and Web now speak the same "language." But not all. And in an IPv6 future with 340 x 10³⁶ unique URLs, not all will. There will always be special cases, and accommodations will have to be made.

What do you think? I'd like to get your feedback.

Bernard Cole is site leader and editor of iApplianceweb and an independent high technology editorial services consultant. He welcomes your feedback. Call him at or send an email to .

For more information about topics, issues and technologies mentioned in this story go to the flashing icon in the upper left corner on this page or go to the iAppliance Web Views page and call up the associatively-linked Java/XML-based Web map of the iApplianceWeb site.

Enter the appropriate key word, product or company name to list instantly every news and product story, product review and product database entry relating to the topic since the beginning of the 2002.