Protocols and Structured Communication

My company builds software called InterComm. It looks at first blush like an Instant Messaging client, and in fact it is. But it's built on top of a brand new protocol that is rich and wonderful, not SIMPLE and limited. We call our protocol XSIP, and it's intended not just for chat, but for truly structured communication.

Network traffic all observes some protocol or another; that's the way networks function. A protocol is much like a human language: the software at each end of the wire needs to understand what language is being spoken in order to make sense of it. There are protocols for everything: IM, email (the protocol is SMTP, which stands for Simple Mail Transport Protocol), FTP (File Transfer Protocol), HTTP (HyperText Transfer Protocol) and hundreds more. Usually protocols are special-purpose, created to get one particular job done. Even HTTP, upon which the entire World Wide Web was created, is an extremely simple protocol that for the most part boils down to a single command: GET filename. If an entire multi-billion dollar industry can be built on top of a single command in a new protocol, just imagine what a rich structured protocol that has over 50 carefully crafted commands can do. That's what keeps me up late at night: imagining that very thing.

My career goes back to the beginnings of Adobe Systems and the PostScript programming language, in 1985. I've written two books on PostScript, in fact. PostScript was a protocol for printing pages, but unlike its predecessors, it was not a limited command set that controlled just the functions of a single printer. It was an over-arching protocol for all printers, even those that might be conceived into the future. Very ambitious, and very powerful. It was not a printer driver, it was a page description language.

We have done the same thing with InterComm and our network, though nobody can see it yet. We have an underlying structured protocol that can represent all kinds of interactions between computers, both human-to-human, which encompassess voice, video, and chat, but more importantly, human-to-computer and even computer-to-computer conversations. Filling out a web form is basically human-to-computer communication, since I knew you were wondering about that.

All of the competing IM networks offer just human-to-human conversations. Video and voice over IP seem amazing at first until you realize you're still talking to the same person, over the same channel, and although it's useful, it's not exactly revolutionary—just pick up the phone, if you know the other person is there. Works better than shouting at your computer.

Anyway, where we're going is into interesting ways for computers and people to interact with each other. We'll include lots of kinds of assets, files, calendar items, web links—the building blocks of the internet, and of communication.

If you think that the SIMPLE protocol in use by AOL and Yahoo is providing great service to our industry, consider these two small facts:

• Video, and voice, and web cams, are in fact not supported in the protocol, which is why none of that stuff interoperates between, say, YIM and AIM and iChat. All the interesting stuff is done with application-specific proprietary protocols.

• There is a 256-character limit for each message. Just try pasting something moderately-sized into AIM and see for yourself. The last time I saw a limit of 256 limit on anything of importance was in about 1986 when the Macintosh fontID range ran out (they thought nobody would ever have more than 256 fonts).

I realize that this is a bit overly technical and out in right field but I actually get excited about this stuff, and I can't believe how primitive it all is, and how much power is still untapped in the internet. I just can't believe it!

And if you think Jabber is the answer to all the world's problems, just go to their web site and try to figure it out. I dare you. Besides, XMPP is the wrong way around. It is a protocol with a lot of angle brackets, which don't help that much, but no rules (semantics) about what should be said over the network. This makes for a lot of one-off features that work between some clients, but overall it's no better than SIMPLE as a protocol; just less efficient, because of all the XML overhead.