hi Spencer, Toerless, To address this point in particular: >> I can not believe that WebSockets is seen as a bad but unavoidable >> protocol approach. I rather think a lot of APP area folks in the IETF >> would state exactly the opposite: It is a pretty good coalescion of >> higher layer needed functionality (during conn setup), fits snugly into >> the web centric app layer framework (browsers, http), and manages to minimize >> messy network layer midpoint problems (eg: flow state problems in midpoints). >> And WebSocket effectively is also meant to kill a lot of the protocols >> that where really badly built on top of HTTP, aka: it solves a lot more >> BCP 56 problems than that negatives of BCP 56 apply to it. Absolutely. However, it's constrained to run atop TCP, which means that as an application you have no control over the _transport_ characteristics of a WebSockets connection. You get SOCK_STREAM, end of discussion, with whatever global parameters your kernel has decided are good for you. That's the situation we're looking to improve. And +1 to "thanks, Toerless, for the comments". Hope to see you at the charter discussion on Monday. Cheers, Brian