My confusion? I don't remember saying I was confused and I don't care for your condescending tone. So, before someone can solve a problem, they first have to g

My confusion? I don't remember saying I was confused and I don't care for your condescending tone. So, before someone can solve a problem, they first have to go hat-in-hand to a standards body and ask for permission to? Only once a standard's body has created a spec, then they can implement it? Thats a preposterous assertion. How is a standards body going to know what works and what doesn't and what is needed and what isn't if someone hasn't done the experiments to provide that data? Lets look at some examples (I'm going to skip WebRTC, because, honestly, I know the least about that protocol): HTTP2: This started as SPDY at Google. They did implement it in Chrome (my goodness - they implemented a feature in their own browser without permission and then forced no one else to use it - that horror!). After literally years of experimenting with it, they submitted it to IETF for standardization as HTTP2. One of the stated goals of HTTP2 was to maintain HTTP1 semantics - which, the SPDY proposal for the basis of HTTP2 did. Years of standardization later, and now its adoption is soaring. I've ready a bunch of complaints that it didn't solve every problem HTTP1 has - which is true. But, efforts such as XHMLT 2.0 show that trying to solve every problem can sometimes be kryptonite for solving any problem. Outside of that, I'm not aware of any legitimate claim that it took any shortcuts. I'm not aware of any legitimate alternative proposals. Google could have avoided the work to standardize SPDY which is lengthy and expensive - but they didn't, and now we have a standard that is picking up in adoption. QUIC: This started as ... QUIC in Chrome. They also didn't ask for permission to use it, but, they also didn't do anything to force anyone to. They gathered years of data. That data indicated that such a protocol is possible to implement on the wider internet. No, its not SCTP - but, SCTP doesn't solve all the problems that QUIC does. No, its bolted on top of UDP in an awkward way - but, unlike SCTP, its actually used on the internet which SCTP never has been (except tunneled via ... UDP). They then took their work and submitted it to IETF for standardization - again, expensive and long. That work is ongoing. QUIC brings lower latencies than TCP, while also being fully encrypted. There is work planned to support migration of live sessions. It has many of the benefits of SCTP - with the additional benefit that its actually been proved to be workable. Again, outside of SCTP which doesn't do everything that QUIC does and has not been able to get any real adoption, I'm not aware of any competing proposal. I guess they could bash their heads against a wall and insist of using SCTP - but thats just a recipe for getting nothing done - and its silly to suggest that just because SCTP is a standard that no one else can propose something that even somewhat overlaps with it. WebAssembly: Its roots are mostly in ASM.js. Mozilla just implemented it (THE HORROR). Via this effort, they proved the benefits of the idea and built out a bunch of tooling to support it (all available freely). Google also tried something similar - NaCl - which likewise showed the benefits of making a more efficient runtime. The major browser vendors all got together to standardize the effort - taking some of ASM.js and some of NaCl but not all of either. And, now we have a standard that makes certain code smaller and faster and is supported across all major browser. And, there are more future improvements in the pipeline. A lot of the major corporations have issues and things they should be held to task for. But, innovating without permission and then spending years and tons of money to create open standards based on their innovations isn't one of those things.