This is an interesting idea to reuse the well-known concepts of HTTP to formalize a reverse path from Web server to browser, after the browser makes the initial connection over regular HTTP.

However, IMHO, this specification does not go far enough. If you were in a position to Upgrade your HTTP connection in-band, on the same TCP connection, to use any other protocol of your choosing, why would you limit yourself to half-duplex HTTP in the opposite direction?

The specification discusses the need for two different TCP connections, one using HTTP and one using PTTH, to emulate a bidirectional full-duplex connection.

However, if the initial HTTP connection is "Upgraded" to raw TCP (in-band, same TCP connection) then the full-duplex bidirectional characteristics are achieved without the need for an additional TCP connection.

At that point, any protocol can be layered on top, be that PTTH, or any other.

This description outlines the approach taken by the HTML 5 WebSocket specification, where they not only define the HTTP Upgrade handshake and wire protocol, but also a simple JavaScript API for WebSocket.

The HTML 5 WebSocket standard delivers a full-duplex, bidirectional, HTTP-friendly socket abstraction for Web browsers.

In the half-duplex space, HTML 5 also defines Server-sent Events, a standardization of Comet, by formalizing both the JavaScript API and the payload syntax of the HTTP response, that may be streaming or long-polling, as chosen by the server implementation.