Pretty much. Looking at it, there's a lot of things that need to be fleshed out before it's actually ready. EDIT: The main concern I have over this is that it

Pretty much. Looking at it, there's a lot of things that need to be fleshed out before it's actually ready. EDIT: The main concern I have over this is that it basically forces a state into an already stateless protocol. Streams need to be established, which means that they need a state(up/down/in-between), and both the server and client(browser, in this case) needs to maintain it. For example: 1. Should the protocol allow browsers to combine streams? I.e. if a user is accessing 3 different youtube videos in HTML5 mode, can the browser do 1 stream for the various static elements on the page, and 3 or more streams for the video and other content? This can make the browser feel faster even when loading non-cached pages, so it's definitely desirable. However, it's a lot more work on both the browser and the server to maintain it. 2. What rules are there for streams? The draft states that 1 HTTP request and response should be used per stream, but would it make sense to allow the browser and server to assign streams? How are browser-instantiated streams different from server instantiated ones? Do those need any additional rules? 3. Should SPDY be content agnostic(where a stream is a stream), or would it make sense to have several QoS levels assigned to them(i.e. high for video or other streaming data, medium for control, low for static elements)? 4.(related to 3) Does HTML, CGI, etc. need to be extended to handle this, or should it be left up to the server/browsers to implement it?