SuitWatch/Thursday, April 18, 2002
The Protocol Problem
About a thousand years ago in tech time, somewhere in the mid to late Eighties, I did a bunch of work with a big networking company of that time called Ungermann-Bass. One of U-B's many innovations back then was its support for a factory networking standard called MAP, for Manufacturing Automation Protocol. MAP, also known as MAP/TOP after it was mooshed together with Boeing's Technical Office Protocol, was started in 1982 as an effort by General Motors to standardize networking within factories and manufacturing facilities. It was conceived around IEEE 802.4, which defined networks in bus layouts, although it distributed data with a token in the manner of IBM's Token Ring (802.5) networks (which also required special wiring).
Long story short, UB's efforts were well-meaning and highly valued at the time, but undermined by the success in factories of Ethernet (802.3). Not only was EtherNet relatively cheap, but it integrated very nicely with networked PCs, which by default used Ethernet as well. All due credit to UB, there was no way of knowing that MAP wouldn't cause a lot of business to happen, or that even General Motors and Boeing together couldn't swing enough weight to make 802.4 a standard. And there was even less reason to believe that TCP/IP, of all things, would emerge as the protocol platform for the most universal network ever created: the Internet.
What's amazing to me now, looking back over the years, is how long it takes to establish (or obsolete) a protocol. We're accustomed to thinking of "Internet time" as something that moves very fast, and to crediting Moore's Law with improving new computers while obsoleting old ones in less time than it takes to grow a crop of asparagus. But protocols change in about the time it takes to grow a mature fruit tree.
This is why the Internet is both so successful and so limited.
Look at the core protocols that enable the Net's basic services: HTTP, FTP, LDAP, SMTP, POP3, IMAP and SNMP. These are in effect the Net's true infrastructure, because they govern the services the Net can universally support. Yet these services are few and rudimentary compared to what, say, an ordinary enterprise LAN supported ten years ago. The Net grew around these protocols precisely because they were simple and easily ubiquitized. Just as Ethernet aced out Token Ring and Token Bus, SMTP and POP3 aced out X.400 as the infrastructure for mail service. But no Internet protocols even begin to support the rich and complex file, print and directory services that come standard with Novell's NetWare.
Many Internet services remain undeployed (or underdeployed) for lack of enabling protocols. Instant messaging (IM) is one example. The fact that any of us can download an IM client from AOL or Microsoft doesn't mean that the Net itself possesses any kind of IM standard. AOL, Microsoft, Yahoo and Lotus all have IM systems that use arcane, proprietary and closed protocols that restrict their own clients to their own servers. Thus each client is like a browser that can only visit one Web site. That's why today there is still no universal IM server that does for IM what Apache for Web service and Sendmail does for mail service. That's because there is no HTTP or SMTP for IM. The best candidate at this point in history is Jabber <http://www.jabber.org>; but Jabber is still new as protocols go. It might be a fruit tree some day, but for now it is barely flowering, in spite of widespread adoption. With the Internet standards aren't standards until they become universal. Meanwhile the Net lacks an infrastructure for IM.
Or look at security. Even today we still think about security almost entirely in terms of firewalls. Conceptually, firewalls are a medieval "solution" to a 21st century problem. The result, says Craig Burton, CEO of JanusLogix, is what he calls "Web noir -- a technological Dark Age obscured by the apparent brilliance of the Internet, as we know it. The dark -- that noir -- is what we don't see, what we don't know because it doesn't yet exist." <http://www.craigburton.com/stories/storyReader$19>
The first bright hope for a Renaissance, Burton says, is XML (eXtensible Markup Language). With the recent development of SOAP, WSDL, WSIL, UDDI and WSIL, XML makes "Web services" possible. Some of these services look so promising that major vendors such as Microsoft, IBM and Sun are pushing their own Web service frameworks: .Net, J2EE, and SunOne, to name three.
Yet all these frameworks have an exclusive effect: they tend to lock in customers and lock out competitors. If the Net has proven anything, it is that exclusive "architectures," "frameworks" and "environments" all fail as universal infrastructure. Just this morning the Seattle Times reported that the White House's technology czar is considering a trip into the same delusional cul-de-sac:
Forget about a national ID card. Instead, the federal government might use Microsoft's Passport technology to verify the online identity of America's citizens, federal employees and businesses, according to the White House technology czar.
On Sept. 30, the government plans to begin testing Web sites where businesses can pay taxes and citizens can learn about benefits and social services. It's also exploring how to verify the identity of users so the sites can share private information.
<http://seattletimes.nwsource.com/html/businesstechnology/134438173_passport18.html>
Passport will fail the government for the same reason AOL's and Microsoft's instant messaging systems will ultimately fail as universal standards: they're owned by people with vested interests in keeping their properties closed and exclusive.
Identity should be another of those fundamental Web services. Your self, your car, and a drill press on a factory floor will all have unique identities that make sense in the universal context of the Net. Someday. But how will that happen? Will it depend on yet another protocol, or set of protocols? By what decade?
So let's look at a question: If we can't speed the evolution of protocols, can we at least find a way to make them irrelevant?
Craig Burton thinks the answer will be an "Application Protocol Framework" that subordinates protocols to a role that doesn't gate progress. If such a framework emerges, he says, it will be as transformative as the discovery of calculus, which significantly accelerated the scientific revolutions that brought on the Renaissance and everything that followed.
But his is just one answer. Surely there are others. Meanwhile, progress will continue to move no faster than the protocols that limit it.