Some binary layers are helpful: TLS, for example, adds a nice generic encryption layer to connections. SPDY, on the other hand, has intimate knowledge of the operation of HTTP (which it needs to do header compression, for example). For example, the header compression dictionary is based on today's usage of HTTP with no provision for it to change over time.

It is a shame that features that are important to HTTP (multiplexing and priority) are not being added within HTTP itself.

I'd like to comment on your statement on the header compression dictionary. Firstly, your statement is only true for the initial header compression dictionary. Most of the improvement is achieved strictly through the use of compression at all, with very marginal gains from different compression algorithms or better initial dictionaries. If your implication is that intimate knowledge of HTTP is required for SPDY compression to work well, that is false. Please note the research at http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf with the following conclusion: "This result suggests that zlib’s adaptive dictionary evolves to roughly an equivalent state after compressing the first header regardless of the content of the initial dictionary."

Can you clarify what you mean about features not being added within HTTP itself? Where are you drawing the line for "HTTP itself"? I'm curious, since the ideas behind SPDY have already been proposed for HTTP/2.0, and indeed the starting point for the HTTP/2.0 proposal used the SPDY draft, so I don't know what it means that important features aren't being added to HTTP itself.

When I think of HTTP I think of a text-based protocol not binary. I fully understand that SPDY has essentially been ratified as HTTP 2.0 given that the charter has been updated to be so close to SPDY itself. Thus at some point what I think if as HTTP will need updating to simply include SPDY and what I currently think of HTTP will be moot.