"Google's efforts to improve Internet efficiency through the development of the SPDY (pronounced 'speedy') protocol got a major boost today when the chairman of the HTTP Working Group (HTTPbis), Mark Nottingham, called for it to be included in the HTTP 2.0 standard. SPDY is a protocol that's already used to a certain degree online; formal incorporation into the next-generation standard would improve its chances of being generally adopted."

I read the spec, and to be honest I don't like some of the design choices they made. Some of the datatypes are fixed size, some strings are zero terminated, others have a length prefix, yet another has both a length prefix and is zero terminated (I haven't the foggiest idea why?).

Problem 1: Application specific datatypes don't deserve special treatment in a generic transport protocol. Why is SHA not present? What about RSA keys? What about a JPEG datatype?

Problem 2: The *meaning* of a variable is implicitly known by the code which uses it. If it's *expecting* the MD5 field to contain an MD5 hash, there's no need for the transport protocol to tell it that the raw bytes are an MD5 datatype. JSON/XML work fine this way, I can't think of many applications that would benefit from overloading the MD5 field into different datatypes, which is probably always going to be an error.

So in my opinion, BSON is not a good model for a binary HTTP protocol. But I do think a simple binary name/value collection could work nicely.

Edit: it has occurred to me that you didn't actually propose BSON would be suitable for HTTP, but merely used it as an example of a binary container. So maybe my reply is out of context to what you were thinking, but I'll leave my comments anyway.