But one note--from ZDNet reader Frank Beier Jr.--stuck out as a call to action for me to explain what this controversy means to you. As my colleague David Coursey noted in "Microsoft-IBM Web conspiracy? I don't think so," "There are some things customers probably don't need to watch being made: The one we know about is sausage. The other is standards." Indeed, the issue of standards-setting seems esoteric to most of us.

But standards-setting affects everyone-consumers, IT managers, CxO's, companies large and small that provide technology products today (or are thinking of doing so tomorrow), and even the global community of nations. Here's why.

[an error occurred while processing this directive]

Consider the Web applications you've deployed in support of your business' bottom line. Most companies support simple applications, such as allowing customers to come browse their sites. Browsing is one example of an Internet application where all the protocols needed to make it work are freely available. To run your Web site, you can rely on a set of standard protocols like HTTP, HTML and TCP/IP, without any financial encumbrances from royalty seekers. That set of protocols is called a stack. Other Internet applications rely on other freely available protocol stacks. Examples include FTP for file transfer, NNTP for newsgroups, and SMTP for e-mail. Each application relies on a slightly different stack (usually with the same protocols like TCP/IP at the bottom). Today those stacks, from top to bottom, are royalty-free.

Will future applications be royalty-free?
But these rudimentary applications barely scratch the surface of the Internet's potential capabilities. The question is: Can you see yourself tapping into the more advanced applications that will emerge in the next decade? If so, there is an increasing possibility that those applications will rely on protocol stacks that are not entirely royalty-free. For example, royalty-free protocols such as TCP/IP and HTTP may still be at the bottom of the stack, but the new protocols that ride on top of them, such as WS-security may not be royalty-free.

Those royalties could reach into your pocketbook any number of ways. If you are hosting or supporting some of those next-generation applications on your Web site, the owners of the non-royalty-free parts might try to bill you. It's been tried before by Unisys, and currently by British Telecom.

Or perhaps those IP owners will charge the software vendors that make products that support the protocols. One category of software that could be affected is Web application development tools such as those from Borland or Macromedia. Another vulnerable category: application servers and Web servers. Examples of application servers are Oracle's 9iAS and BEA's WebLogic. Web servers are available from outfits like ef="http://techupdate.cnet.com/enterprise/0-9500-721-235588.html">Netscape and Apache.

There's a degree of device independence built into these protocols, too. For example, they will make it easy for the manufacturers of handheld wireless devices and Net-enabled gaming consoles to build in capabilities for retrieving data and content available via Web services protocols. However, the manufacturers of those devices may also be subject to royalties and would no doubt pass that cost on to consumers.

Likewise, if the software vendor wants to build those new stacks into the next version of their software (the version that you might update to), that vendor may have to pay a royalty to the patent holders and then pass that cost on to you. But if the vendor can't afford those royalties, they may choose not to include the new stacks in their software. The same goes for device manufacturers.

As a result, you may have to turn to someone who does. You could turn to a third-party that offers the protocol stacks as an add-on. But that increases the number of products you have to keep track of and puts the burden on you to integrate them. (Continued on next page.)

1 2	| Next page

[an error occurred while processing this directive]

[an error occurred while processing this directive]