There are some forces that just cannot be stopped. Block the path, and they’ll just go round some other way.
The classic 7-layer network model has served us well, and continues to do so. Each network interface has an IP address and a lot of ports, some of them allocated by policy to specific network services, others unused. The purpose of having lots of different ports is that different services, having different architectures and semantics for different applications, can use different ports. That way they run independent of each other and without interference on the same network. Simple, secure and elegant.
But nowadays we have firewalls. Packet-filtering firewalls, very simple to understand and deploy. Just shut off every port you don’t explicitly need. You can configure that on consumer-devices such as ADSL routers, and protect the unwashed masses from a significant part of their own ignorance. This is a Good Thing.
But like many good things, it has a downside. It’s so simple and useful that it gets into company policies, where it is misused. A typical policy goes something like “This is a webserver. We open ports 80 and 443, and firewall everything else”. This is a good policy up to a point, but no further. The point in question being where you have a legitimate need to run a service for which HTTP is not well-suited.
Like, for example, symmetric, stateful two-way communication over a persistent connection. OK, it can be done over HTTP. There are many ways to deal with state, at the cost of modest complexity. Server-driven communication goes back to Netscape’s Server Push in 1995, and lives on in pseudo-protocols such as “Comet” today. But it’s completely contradictory to the HTTP Request-Response model, and implementing it on top of HTTP implies significant extra complexity over running a dedicated service on a different port.
A Comet application is a Heath-Robinson construction to drive a non-HTTP network application over HTTP. In a sensible world it would run over its own port, independent of the HTTP server. But security policies stand in the way of that: getting authorisation to open a port for it is more trouble than it’s worth. So the world routes around the firewall using Comet instead. And in doing so, introduces more complexity, more scope for bugs and security vulnerabilities.
This is a Bad Thing. And there’s a whole culture of it: the demand is such that we’re getting generic tools and a name. How long will it be before there are off-the-shelf applications that only support Comet, so that even a company with a pragmatic and informed firewall policy is driven to use it? From a browser point of view it’s just another potentially-useful capability they’ll want to support in an AJAX world.
Arguably yet more bizarre are the clutch of XML-over-HTTP protocols in and around “web services”. The simpler protocols such as XMTP, XMLRPC or SPARQL are straightforward wrappers on some kind of exchange, putting everything into an HTTP payload at a cost in complexity and performance. Once again, their raison d’être is to work around a firewall to provide services that could more simply run on their own port (and sometimes do).
In the case of webservices, routing through HTTP does serve a useful purpose. The webserver becomes an application firewall (e.g. with mod_security), and can become part of the application (e.g. with mod_publisher). Additionally, it can be used to enforce things like access control policies and bandwidth management. In short, the application gets the benefit of Apache’s modular framework. Or whatever benefits another server may offer.
Still, the bottom line is that when a traditional path gets closed, the world will route around it. On balance, it’s hard to call this a Good Thing or a Bad Thing: it’s just inevitable. Dangerous, because any vulnerabilities in your applications won’t go away just because access is tunneled over HTTP. But anyone who tries to make a distinction between good and bad uses of the breach in the firewall becomes a Cassandra.
 What do you call something that looks like an embryonic protocol but lacks things like an RFC or other published spec?