The point of any standardization is to allow interoperation between moving parts in a system. At this moment we have application developers who want to create Comet applications. We have server developers who want to create Comet servers that are responsible for all kinds of data encoding and transportation. But the application developer doesn’t actually care how data departs the server and arrives in the browser. So a Comet protocol should clearly define where these disparate components should meet, and how.
Many servers will likely want to use a shared communication protocol similar to the current Bayeux proposal. But others will be able to push the envelope and experiment with all manner of server/client interactions. For instance, a server could use the same interaction model that Bayeux proposes now, but completely change the encoding of all the information so as to cut the bandwidth down significantly. We wouldn’t want this to be the “standard” because it’s hard to implement, but we would want it to be possible by defining a looser standard.
The only real reason for defining a communication protocol is to allow non-browser clients to connect. But we should just face the fact that Bayeux is a browser-based standard, and define an alternate spec for non-browsers.
There’s no point in making a developer first choose a Bayeux server, and then choose a Bayeux client. The various Comet server developers can get together and collaborate on interaction models or client implementations, but in the end, all we really want is for application A to run on Bayeux server B, C, or D.