Is Bluetooth already too long in the tooth?

Lately, my e-mail inbox has been resembling a bulletin board, thanks to a weeks-old raging thread that started with Bob Frankston's objection to my Bluetooth advocacy.

Frankston, and his Software Arts co-founder Dan Bricklin are best known as the co-creators of Visicalc, one of two software innovations (the other being MicroPro's WordStar) that put the "P" in PC.

So, when an e-mail from Frankston asked me to reconsider my enthusiasm for Bluetooth, I dropped what I was doing, listened, and asked questions. Eventually, others were pulled into the thread, including industry pioneer David Reed and, Bluetooth Special Interest Group board chairman Mike Foley. Foley is also a wireless architect at Microsoft, playing a key role in the company's Bluetooth strategy.

The thread tackles a conundrum that has burdened this industry for as long as I can remember: the risks of immediate gratification in functionality versus the need for the creation, support, and deployment of widely accepted and interoperable standards. Bluetooth happens to be the poster-child du jour for this conundrum.

On the side of instant gratification is Bluetooth's most compelling (and current) selling proposition as a non-line-of-site (as opposed to InfraRed) cable replacement technology. Bluetooth's availability has already given rise to the wireless interconnection of devices such as computers, keyboards, printers, audio headsets, PDAs and mobile phones. Bluetooth is facilitating applications where PDAs like HP's Bluetooth-enabled iPaq can wirelessly use an Ericsson T68i Bluetooth-enabled cell phone as a modem for reaching the Internet, and, in the case of business applications, for reaching corporate networks via VPN technology. Other users are enjoying hands-free wireless headsets that work with their cell phones and computers. In short, Bluetooth is solving real problems today and users are taking advantage of those solutions.

The Bluetooth SIG developed application-specific profiles that hardware vendors are supporting in order for their devices to not only comply (for market acceptance), but for them to actually work in the scenario to which they're suited. Depending on which type of Bluetooth device you're looking at, the hardware inside usually consists of a profile that's inextricably married to the Bluetooth radio.

Meanwhile, on the creation, support, and deployment of standards side, strong arguments and working models (LANs and the Internet) exist for a layered approach that cleanly separates "physical" connection methods like Bluetooth from the applications that use them. In the wired world, a great example of this clean separation is Ethernet and security.

Ethernet has experienced significant changes over the last 20 years. Not only has the wire itself been physically changed (or removed), but so have the speeds. The result: physical incompatibilities from one generation to the next have been easily resolved with a bridge or a router. Had the world been relying on security built into Ethernet, resolving security incompatibilities between generations would have been more complicated.

Even if the security was compatible from one generation of Ethernet to the next, what would happen to Internet-enabled applications that depend on security, but whose traffic invariably crosses non-Ethernet media once it heads off for its destination?

Without a layered environment, where applications and the security they need are sufficiently insulated from the network's physical medium, most network-enabled applications would end up in one of two situations. Either they would routinely break upon the replacement of some segment of the network they rely on, or they would be stuck in the cul-de-sac of their host network because it would take forever to bridge the security protocol of that network to the security protocols of the other, newer faster ones.

It's exactly this slippery slope that Frankston says Bluetooth is headed for if it continues marrying application-specific profiles to its physical layers, and if vendors follow that up with devices that are destined to end up in their own cul-de-sacs.

Frankston insists there's no excuse for marrying what belongs in the transport, session, or applications layers to the physical or data-link layers. "[Doing this] ignores the Internet's theory of moving function out of the network and into the client applications," Frankston says. "Bluetooth tries to embed much too much application function, despite the fact that those applications are not well understood, and are better served by the Internet's protocols." He's right. Anything that's not well understood has no business being embedded in the infrastructure, where it can only have a destabilizing effect.

Once again, consider security as an example. Instead of building security into Bluetooth's medium, why not force Bluetooth solutions to rely on security found at either the Internet security protocol (IPsec) or application layers? This could ensure greater interoperability not only among Bluetooth-enabled solutions, but also between Bluetooth-connected solutions and non-Bluetooth-connected solutions.

For example, what if I needed to connect a Java application in my cell phone to a corporate database, and the only hotspot available to me was a Bluetooth one? The preferred choice would be to let the phone and the database talk to each other over IP and let IPSec handle the cryptographic security between the two. In this case, the application doesn't know or care about the Bluetooth network I'm crossing on my side or the Ethernet that's being crossed on the corporate side.

This is where the conundrum comes in. Relying on an encryption standard like IPSec to secure all Bluetooth connections, especially for consumer applications, means that all Bluetooth devices would have to be enabled for IP.

Although that day appears to be coming (especially because Microsoft is an advocate for supporting IPsec), few if any of today's devices will be ready for it. Even if they were, it's not just any old Internet protocol that they'd have to be enabled for. It's IPv6, which, unlike the more prevalent IPv4 that most of us use today, mandates the support of IPSec, while also greatly simplifying the ad-hoc deployment of, and participation in, IP-based networks.

So, what are we supposed to do? Should we forgo the conveniences that a bleeding edge technology like Bluetooth can deliver to us today in order to avoid getting trapped in a cul-de-sac tomorrow?

The financial risk is that we'll have to spend more money to get out of that cul-de-sac later. Or do we pay the premiums (money, battery-life, size, etc.) for a wireless technology that fits better into the layered model now (like 802.11/WiFi)? Plenty of people won't even consider swallowing that bitter pill.

Adopting a cul-de-sac-like technology today increases the odds that the technology will develop some irreversible momentum we'll later regret. This could result in the same enduring and expensive vicious circle in which proprietary technologies tend to trap us. (Think Microsoft and licensing fees.)

Cellular providers, for example, would love to trap us with a "proprietary" technology that addicts us to the phone we bought from them, and thus, their networks for all of our voice and data needs. They live in fear of the day that you're able to wander around with a voice-over-IPv6-enabled headset that bypasses the cell phone they gave you (and that their network its attached to) by connecting directly to the local hotspot that Starbucks or Hilton provides as a free courtesy to their customers. Why do you think it's so difficult to roam now? Even worse, is some conspiracy afoot? Did the cellular carriers conspire to keep Bluetooth from evolving down the same open path that 802.11 has taken?

My advice: Given Bluetooth's potential to replace a lot of messy and often proprietary cables and connectors that people have in place today, I can't imagine not having it. Bluetooth really is the best thing going since the other wireless cul-de-sac (InfraRed) came along. Had Bluetooth been a standard part of my Palm devices, I'm relatively certain that Palm's decision to change the cradle socket between generations of its PDAs wouldn't have forced me to throw out the Minstrel Modem I bought for my Palm V--and wanted to use with my Palm 505.

I'm also not certain that every Bluetooth-enabled device needs IPv6 support. Your mouse may not require it. But then again, maybe not. It depends on what the mice of the future get used for.

I'll also stand by my recommendation to avoid buying devices like cell phones or PDAs unless they have Bluetooth in them. But now, I'd also recommend staying on the lookout for IPv6 support. It will be a while before the IPv6 infrastructure is completely in place anyway, and the bleeding edge (self-indulgent as it is) is where I like to hang out. I don't mind cul-de-sacs as long as I keep reminding myself that the word "cul-de-sac" is just a fancy way of saying "dead end." Sooner or later, I know I'll have to put it in reverse. But that's a price I'm willing to pay to get what I want now.

How do you respond to the conundrum? Are you the type that needs to be instantly gratified or do you prefer to wait for the dust to settle? Let me know. TalkBack below or write to me at david.berlind@cnet.com.