Microsoft goes its own way with Web audio/video spec, despite W3C rebuff

Redmond is showcasing its alternative protocol with a plugin for Chrome and IE.

Microsoft has published a working prototype of CU-RTC-Web, its proposed specification for enabling browser-based, plugin-free, real-time audio and video communication.

CU-RTC-Web isn't the only proposal for such a specification. In fact, it's not even the main one. The World Wide Web Consortium (W3C), the group that formalizes the development and specification of Web-related standards, has its own group working on a plugin-free, real-time audio and video communication specification called WebRTC. Preliminary—and somewhat rudimentary—support for WebRTC is found in current versions of Chrome and Firefox.

This support certainly isn't finished yet, and interoperability between the browsers remains troublesome—many of the online WebRTC demos are built for Chrome alone and won't work with Firefox at all—but in theory they're on track to support the same specification in a manner that will eventually be compatible.

Redmond first announced CU-RTC-Web in August. Along with the specification itself, the company produced a rationale; a list of reasons why it felt that WebRTC was a bad fit for the problem at hand, and why CU-RTC-Web was a superior solution. Perhaps the most specific complaint was that WebRTC was quite deeply linked to a specification called SDP, an open industry standard used extensively for VoIP and video conferencing systems in conjunction with SIP, with Microsoft arguing that this is over-complicated and hinders interoperability with non-SDP systems. SDP is used to negotiate the parameters of the connection; things like the bandwidth, the IP addresses and port numbers to use, and so on.

It just happens that Microsoft has non-SDP products of its own—Skype (which remains stubbornly proprietary and undocumented) and Lync (which can bridge with SIP systems, and hence understands SDP, but offers alternative APIs too).

Although W3C's WebRTC working group acknowledged that the current WebRTC spec has parts that are as-yet incomplete, a vote carried out in September to choose between the two paths was heavily in favor of WebRTC. It won with 22 votes to just 4 for Microsoft's proposal.

So what's Microsoft playing at, persevering with its own spec in spite of its rejection by the WebRTC group?

The company's argument is twofold. First, WebRTC simply isn't complete yet, and Microsoft believes that working on its proposal can shed light on how to solve certain problems such as handling changes in network bandwidth or keeping cellular and Wi-Fi connections open in parallel to allow easy failover from one to the other. Even if Redmond's spec isn't adopted wholesale, portions of it may still be useful.

Second, the company believes that WebRTC may not be as close to real standardization as its proponents might argue. The problem is SDP. SDP wasn't originally designed for browser-to-browser communications, and some of the things that WebRTC uses it for go above and beyond the specification. For example, WebRTC wants to be able to include multiple streams multiplexed over a single connection. Doing that will require extensions to SDP. Different SDP implementations also struggle to achieve compatibility; the SDP specification permits multiple conflicting interpretations, with Microsoft and others claiming that the implementations in Chrome and Firefox are incompatible. There are similar difficulties in getting Chrome to talk to existing SIP systems such as Asterisk. Both ends are using SDP—they're just not using the same interpretation of SDP.

The SDP standard isn't governed by W3C. IETF's MMUSIC ("Multiparty Multimedia Session Control") Working Group is in charge of SDP. That group will have to incorporate the new features that the WebRTC group needs, and it will have to do so in a manner that remains compatible with existing deployments of SIP and related protocols.

Until these updates and extensions to SDP are standardized, WebRTC cannot be finalized. That standardization could be quick, if MMUSIC fast-tracks the modifications, but that's not guaranteed. There are compatibility constraints, and these can be hairy. The MMUSIC group may be unwilling to risk breaking extant SIP deployments just to add support for WebRTC.

Underlying all of this is a somewhat different attitude regarding what WebRTC is for. Many in the group, including its chairperson, maintain that browser-to-browser communication is the most important use case. Microsoft, however, wants a more general set of APIs, suitable not just for browser-to-browser communication, but browser-to-legacy-software, browser-to-switchboard, and browser-to-anything else that might make sense.

It's already clear that developers experimenting with Chrome's WebRTC support want to do more than merely communicate with other browsers (such as the previously mentioned attempts to connect to Asterisk), so Microsoft's viewpoint appears to have some resonance with actual developers.

The CU-RTC-Web proposal is lower level, and a SIP system using SDP could be built on top of it if desired; it just doesn't require SDP.

Microsoft's prototype implementation works in Internet Explorer 10 and the latest version of Chrome. In both browsers, it works as a plugin, providing JavaScript programs a version of the CU-RTC-Web API. With this prototype, the company is demonstrating that its proposals do work in practice and could provide a solution to the problems with SDP.

Even backers of the current WebRTC specification acknowledge that the SDP problems have so far proven intractable. The WebRTC spec hinges on getting SDP fit for purpose. If a quick resolution to the difficulties can be found then WebRTC will be here to stay. But if it can't, the working group might want to revisit Microsoft's SDP-less proposal. The best solution to the SDP problems could be to stop using SDP entirely.

I'm concerned that a lot of these new browser technologies will go unused in 5-10+ years. I just don't see the web browser as "end all, be all" solution to access to everything like it is today. The main reason?

Consider the use case of today: turn on computer, login to OS, open browser, get required content.

I really honestly believe that one of these "layers" is going away. Whether it be the "OS" as we know it, or the "browser" as we know it the use case of tomorrow will be:

turn on computer, login to something, get required content. Unfortunately, browsers seem the most likely. iOS, Android, and even Windows apps are already pushing the browser on its way out.

Just to be clear:"browser-to-browser communication is the most important use case". Use, not use case.

Presumably MS were going to have their proposal become an open W3C standard, in which case this is them saying "OK, you don't want to develop this, and want to stick with what we think is a broken system. Fine. We'll make this on our own, and then show you how it's better than what you are going with, and when yours fails, we can help you out by giving you something useful".

That's not to say MS is right, but that their view is that they are right, and they are putting their efforts where their ideal is.

What's undetermined is how it will all shake out. Locking down the internet doesn't seem to be part of it.

At least MS are trying to engage with the standards process, and their own standard could be feasibly adopted by others. Their criticisms of WebRTC are technical and not political.

Couldn't agree more. MS of old is gone. The newer MS has to compete in a progressively standards-reliant world. I do believe WebRTC will "win" per se, but the fact that MS brings up these technical issues is part of a healthy standardization process.

I'm concerned that a lot of these new browser technologies will go unused in 5-10+ years. I just don't see the web browser as "end all, be all" solution to access to everything like it is today. The main reason?

Consider the use case of today: turn on computer, login to OS, open browser, get required content.

I really honestly believe that one of these "layers" is going away. Whether it be the "OS" as we know it, or the "browser" as we know it the use case of tomorrow will be:

turn on computer, login to something, get required content. Unfortunately, browsers seem the most likely. iOS, Android, and even Windows apps are already pushing the browser on its way out.

Just to be clear:"browser-to-browser communication is the most important use case". Use, not use case.

That is the problem.Everything is moving onto the internet. But in doing so, everything is also getting special "apps" developed in order to use it... on the internet.

Rather than smartphones and tablets giving us a "cloud" where everything is on the internet and can be accessed from any device, we seem to be going to a world where everything is on the internet, but requires its own special gateway.

While the current direction seems to be what you say, skipping the browser and having everything with its own app (which IMO is pretty backwards), systems like this would be aimed at "fixing" that, and having more things able to live inside a browser, rather than requiring a specialised app.Which may also be why MS have an issue with the limitations of the W3C direction. It means that people won't bother and we will end up sticking with App world, when most apps are just a rehashing of web content, rather than being actual apps with an existence outside the internet.

So their answer to a plugin-free protocol is to make a plugin version of their own?

Only as a prototype. It's easier to develop a discrete chunk of functionality as a plugin than it is as fully-integrated source patches. The plugin approach is sufficient to test out the JavaScript API and use it as a proof of concept.

So their answer to a plugin-free protocol is to make a plugin version of their own? Good thinking, Microsoft! Sometimes I think Microsoft has nothing better to do than trip others. VP8 is already better than h.264 and it's also being used by Skype...so why try to change that? Because they are afraid WebRTC might disrupt Skype, and they want to somehow tie the new protocol with Skype? Well that would explain it.

It seems to be more a "proof of concept" type activity...You make a plugin version because nothing can support it except what you make support it.If it's supposed to work in more than one browser, you have to make plugins for those browsers.MS have an idea. They want to show people their idea is better than someone elses.They make a plugin to showcase that idea, and maybe eventually it can be standardised and included in browsers without a plugin being required.

Kinda obvious process, if you think about it. They already tried getting people to vote on the concept. Now they will get people to vote on the proof of concept plugin.

I'm concerned that a lot of these new browser technologies will go unused in 5-10+ years. I just don't see the web browser as "end all, be all" solution to access to everything like it is today. The main reason?

Consider the use case of today: turn on computer, login to OS, open browser, get required content.

I really honestly believe that one of these "layers" is going away. Whether it be the "OS" as we know it, or the "browser" as we know it the use case of tomorrow will be:

turn on computer, login to something, get required content. Unfortunately, browsers seem the most likely. iOS, Android, and even Windows apps are already pushing the browser on its way out.

Just to be clear:"browser-to-browser communication is the most important use case". Use, not use case.

Uh.. what? First of all, can you really imagine your daily compute without an actual browser? Second of all, what do probably at least 80% of apps on those mobile platforms have embedded (for example, a reddit app): an embedded browser.

The "OS" is going away eventually, but it will be an extremely slow transition before everything is rewritten in web languages like javascript. The Web Browser as a platform will still take a little bit of work.

Rather than smartphones and tablets giving us a "cloud" where everything is on the internet and can be accessed from any device, we seem to be going to a world where everything is on the internet, but requires its own special gateway.

Interesting take on the situation. Now that you put it this way, it does seem just as likely to have a more "general purpose gateway" as you put it rather than, as I originally saw it, have individual processes that leverage internet functionality. It really is up in the air...

Lonyo wrote:

While the current direction seems to be what you say, skipping the browser and having everything with its own app (which IMO is pretty backwards), systems like this would be aimed at "fixing" that, and having more things able to live inside a browser, rather than requiring a specialised app.Which may also be why MS have an issue with the limitations of the W3C direction. It means that people won't bother and we will end up sticking with App world, when most apps are just a rehashing of web content, rather than being actual apps with an existence outside the internet.

Unfortunately, websites in the traditional browser can't share any information between each other. That's where your "One Gateway To Rule Them All" ideal breaks down, I believe.

How do you share information between two or more websites today? If I want all my pictures from Facebook to go on some weird website that I created 5 minutes ago, because I don't want to use Facebook anymore, how would I do that quick and easy? Sure I could request all my content and/or manually go into facebook and do it all myself. But I dream of a world where if I want my information to be passed around, I should be able to do that in one click. Just like how the cloud works today. All my cloud-based data can be easily modified, created, destroyed, copied, just like I can in file explorer.

Do web browsers do this? Nope. Browsers typically work at the website level only. There really is extremely little cross communication between websites, let alone tabs or different windows. Facebook and Twitter do have in-site content so you can post to those sites or like stuff from many different websites. But what if the content I want to post isn't Facebook or Twitter or something that is popular today?

What if I read an article on Men's Fitness and want to post that to my fitness website or app so I can use it for reference/motivation/etc later? I can't do that, except for copy/paste. Sure, copy/paste works fine... with a keyboard/mouse. But the massive surge in mobile technologies proves KB/Mouse are on their way out. The numbers don't lie. There must be a better way. There needs to be something else there to mediate. I really believe Windows is taking revolutionary strides in this manner with Windows Apps and the Charms bar. If supported, you can share practically anything from one app to another, securely.

Sure Windows ain't popular, I get it. But believe me, this type of workflow will be realized by many within just a few years.

Uh.. what? First of all, can you really imagine your daily compute without an actual browser?

Yes. Of course I can. For the sake of forward thinking, I will take a purely idealist view for most posts on this article. You did say "imagine". In this day, the practicality of not actually having a browser is laughable, I agree. But we didn't have them at one time, I certainly believe they will be surpassed by something better in the future.

mvnjpy wrote:

Second of all, what do probably at least 80% of apps on those mobile platforms have embedded (for example, a reddit app): an embedded browser.

It's true. But this is my largest gripe about apps today. They always kick you to a browser or have an embedded browser. But a browser is so limiting in what you can do. You have these discrete "web apps" that are largely sandboxed from each other, mostly for security, but with the consequence of functionality as well. Again, I'm idealist in this regard. If an app absolutely *needs* a browser, they're doing it wrong in my opinion. Just be a website and fuggetaboddit. Why have an app that relies so heavily on a browser. Why not just stick to a website?

mvnjpy wrote:

The "OS" is going away eventually, but it will be an extremely slow transition before everything is rewritten in web languages like javascript. The Web Browser as a platform will still take a little bit of work.

Indeed, we live in exciting times in this regard. The OS cannot go away, it's fundamentally impossible. However, I do agree that the "OS" as we know it now *will* go away. We are in the infantile stages of the merging of OS and browser. The result will be something far more powerful and useful than we can imagine today.

SDP and SIP have severe interoperability shortcomings. Essentially, every vendor has their own minor variant of the standard. SDP reliant devices like VoIP phones frequently require a very large, kludgy software stack in order to interoperate with just popular SIP endpoints.

Microsoft's moves have not at all appeared to be some kind of attempt to leverage Skype, rather the opposite. I think Microsoft would like to replace a lot more of Skype's proprietary, spaghetti underpinnings with something standards based, and they have done the research to have a good direction to go. They would really like everyone else to get on board. Microsoft's distaste for all of the issues with SIP/SDP are one of the reasons they have largely not leveraged themselves as a VoIP vendor. The hoops that VoIP deployments require as far as validating customer hardware and software with upstream vendor hardware is ridiculous and is boxing businesses into a Cisco is the only remotely safe bet (even there, one must frequently pick hardware judiciously).

It's true. But this is my largest gripe about apps today. They always kick you to a browser or have an embedded browser. But a browser is so limiting in what you can do. You have these discrete "web apps" that are largely sandboxed from each other, mostly for security, but with the consequence of functionality as well. Again, I'm idealist in this regard. If an app absolutely *needs* a browser, they're doing it wrong in my opinion. Just be a website and fuggetaboddit. Why have an app that relies so heavily on a browser. Why not just stick to a website?

You answered your own question: because the web site cannot integrate with your on-device data the way an app can.

lotharamious wrote:

IIndeed, we live in exciting times in this regard. The OS cannot go away, it's fundamentally impossible. However, I do agree that the "OS" as we know it now *will* go away. We are in the infantile stages of the merging of OS and browser. The result will be something far more powerful and useful than we can imagine today.

The traditional interface will absolutely change. There still has to be a core code base below that (the OS). There's really no way around the latter.

All of the superiority of the browser for applications was in the painless of install (in this case lack of any entirely) and the massive install base for the infrastructure. Apps have both of those, and most of the advantages of native programs, although to a lesser extent.

The shortcomings are as described in the 9th paragraph; SDP doesn't do all the things WebRTC needs it to do, and the specification is written in such a way as to afford multiple incompatible implementations. In other words, it's just not a very well-written spec.

Microsoft also has its own experience with SDP (and SIP). Both Skype and Lync do bridge to SIP systems, so the company does have some first-hand knowledge of the difficulties surrounding the spec. It's not hypothetical.

Indeed, we live in exciting times in this regard. The OS cannot go away, it's fundamentally impossible. However, I do agree that the "OS" as we know it now *will* go away. We are in the infantile stages of the merging of OS and browser. The result will be something far more powerful and useful than we can imagine today.

Consider the use case of today: turn on computer, login to OS, open browser, get required content. [...]turn on computer, login to something, get required content. Unfortunately, browsers seem the most likely. iOS, Android, and even Windows apps are already pushing the browser on its way out.

It all started with apps. It's the browser that was starting to displace them, with very poor results might I add. Before it was Javascript, it was Java applets that were going to take over the world, or perhaps Flash, or some other proprietary technology. It didn't happen then, and it won't happen now.

A web browser is a massively inferior way to access information. Not only is it practically slow and clumsy, it also doesn't integrate into the rest of the system in any decent way, and it's completely free-form, meaning we've been subjected to every whim of every half-assed 19 year-old web developer for decades, and things aren't getting better.

Despite decades of companies designing and redesigning browser interfaces for e-mail, a simple old ancient e-mail program is vastly superior in every way, shape, and form. What's more, you can't have a vast array of programs picking-up e-mails from Yahoo WebMail, like you can from IMAP mail boxes. The same goes for all the basic internet protocols folks have wrapped a web interface around... I can go to some web interface for DNS lookups, ping, traceroute, whois, etc., or I can run a tiny and super-fast native command on my local machine, using the purpose-built protocols, and integrate them with any program I want to. It's a no-brainer, yet enough people have no brain that they're on the browser bandwagon.

A web application is only an improvement when your native app was HORRIBLE (or single-platform) to begin with. Sadly, there's some of that out there, but it should be frowned upon, not encouraged.

I anxiously await a world without the decrepit old web browser. I would have been happy with ancient, slow computers for everything I do, except for video, and the ever more bloated web browser I have to keep tolerating. Not that a single application for every site you visit is a good idea, by any means, but there are options. I sure as hell don't read Ars from a web browser... It's vastly superior to read it on my RSS reader, whether on my desktop or phone. I've got a dozen other RSS feeds I browse through every day, from Ars, Slashdot, and The Daily WTF to Dilbert and XKCD. I can read offline, keep track of what I have read, mark stories to keep them for later, scan them quickly, read them full-screen, nicely laid out in whatever color scheme I want, and flip through them page-by-page like an eBook rather than clumsy tabs and unnecessarilly ultra-precise vertical scrolling (and god help you if you need to horizontally scroll). Using RSS readers for my routine daily reading has probably replaced 80% of the time I'd spend using by browser daily.

And I'm not just pro-RSS... Browsers are absolutely HORRIBLE all around. Folks (generally older than me) bemoan the loss of NNTP (newsgroups) as their interface was so vastly superior to web forums... like this one...

And don't get me started on GoToMyPC, WebEx, etc. As if open, lightning fast, standard and native protocols like VNC, X11, NX, RDP, Citrix, SSH, etc., weren't good enough, now we're making fools of ourselves using a browser to launch a java applet, to launch one of the above protocols, using all kinds of non-standard ports that need firewall hacks, so we can view a remote screen inside of a too-small browser box, as it chews through tons of CPU and requires all kinds of key-mapping and other workarounds, for absolutely no reason.

We just need to work on developing common, interoperable standards for the various purposes that people are stuck using browsers for, rather than ending up with proprietary applications from each company (because the browser versions suck) we'd be so vastly better off. RSS works great for watching for periodic updates from predefined sources, but it leaves out many other web uses. Certainly, something that can be an "open" web shopping app would be immensely beneficial. Imagine being able to search for a type of item, and getting results side-by-side from eBay, pricewatch, Amazon, Overstock, Buy.com, Walmart, etc. Not just prices, but descriptions and specifications, product reviews, etc., from all those sources (that you select) in a single app. Most shopping sites have an API for 3rd parties to get all that information, but sadly they nearly all just stick it in a different web page which is no better. We need RSS-for-shopping, and the sooner the better!

But to put it in more general terms, the web was built to serve up free-form documents, and ended up having application-like features bolted on in horrendous ways. Being so completely free-form has not led to revolutionary interfaces as some claim, it's only made it a real nightmare to navigate. If the web was, instead, built upon some native application toolkit, (like, say: QT), we'd all be unimaginably better off for it. Instead, the economies of scale and design by committee has just pushed tons more crap into web browsers, and really just held back real technological progress. Hell, we'd probably have been better off sticking with Gopher.

I'm concerned that a lot of these new browser technologies will go unused in 5-10+ years. I just don't see the web browser as "end all, be all" solution to access to everything like it is today. The main reason?

Consider the use case of today: turn on computer, login to OS, open browser, get required content.

I really honestly believe that one of these "layers" is going away. Whether it be the "OS" as we know it, or the "browser" as we know it the use case of tomorrow will be:

turn on computer, login to something, get required content. Unfortunately, browsers seem the most likely. iOS, Android, and even Windows apps are already pushing the browser on its way out.

Just to be clear:"browser-to-browser communication is the most important use case". Use, not use case.

Consider the use case of today: turn on computer, login to OS, open browser, get required content. [...]turn on computer, login to something, get required content. Unfortunately, browsers seem the most likely. iOS, Android, and even Windows apps are already pushing the browser on its way out.

It all started with apps. It's the browser that was starting to displace them, with very poor results might I add. Before it was Javascript, it was Java applets that were going to take over the world, or perhaps Flash, or some other proprietary technology. It didn't happen then, and it won't happen now.

A web browser is a massively inferior way to access information. Not only is it practically slow and clumsy, it also doesn't integrate into the rest of the system in any decent way, and it's completely free-form, meaning we've been subjected to every whim of every half-assed 19 year-old web developer for decades, and things aren't getting better.

Despite decades of companies designing and redesigning browser interfaces for e-mail, a simple old ancient e-mail program is vastly superior in every way, shape, and form. What's more, you can't have a vast array of programs picking-up e-mails from Yahoo WebMail, like you can from IMAP mail boxes. The same goes for all the basic internet protocols folks have wrapped a web interface around... I can go to some web interface for DNS lookups, ping, traceroute, whois, etc., or I can run a tiny and super-fast native command on my local machine, using the purpose-built protocols, and integrate them with any program I want to. It's a no-brainer, yet enough people have no brain that they're on the browser bandwagon.

A web application is only an improvement when your native app was HORRIBLE (or single-platform) to begin with. Sadly, there's some of that out there, but it should be frowned upon, not encouraged.

I anxiously await a world without the decrepit old web browser. I would have been happy with ancient, slow computers for everything I do, except for video, and the ever more bloated web browser I have to keep tolerating. Not that a single application for every site you visit is a good idea, by any means, but there are options. I sure as hell don't read Ars from a web browser... It's vastly superior to read it on my RSS reader, whether on my desktop or phone. I've got a dozen other RSS feeds I browse through every day, from Ars, Slashdot, and The Daily WTF to Dilbert and XKCD. I can read offline, keep track of what I have read, mark stories to keep them for later, scan them quickly, read them full-screen, nicely laid out in whatever color scheme I want, and flip through them page-by-page like an eBook rather than clumsy tabs and unnecessarilly ultra-precise vertical scrolling (and god help you if you need to horizontally scroll). Using RSS readers for my routine daily reading has probably replaced 80% of the time I'd spend using by browser daily.

And I'm not just pro-RSS... Browsers are absolutely HORRIBLE all around. Folks (generally older than me) bemoan the loss of NNTP (newsgroups) as their interface was so vastly superior to web forums... like this one...

And don't get me started on GoToMyPC, WebEx, etc. As if open, lightning fast, standard and native protocols like VNC, X11, NX, RDP, Citrix, SSH, etc., weren't good enough, now we're making fools of ourselves using a browser to launch a java applet, to launch one of the above protocols, using all kinds of non-standard ports that need firewall hacks, so we can view a remote screen inside of a too-small browser box, as it chews through tons of CPU and requires all kinds of key-mapping and other workarounds, for absolutely no reason.

We just need to work on developing common, interoperable standards for the various purposes that people are stuck using browsers for, rather than ending up with proprietary applications from each company (because the browser versions suck) we'd be so vastly better off. RSS works great for watching for periodic updates from predefined sources, but it leaves out many other web uses. Certainly, something that can be an "open" web shopping app would be immensely beneficial. Imagine being able to search for a type of item, and getting results side-by-side from eBay, pricewatch, Amazon, Overstock, Buy.com, Walmart, etc. Not just prices, but descriptions and specifications, product reviews, etc., from all those sources (that you select) in a single app. Most shopping sites have an API for 3rd parties to get all that information, but sadly they nearly all just stick it in a different web page which is no better. We need RSS-for-shopping, and the sooner the better!

But to put it in more general terms, the web was built to serve up free-form documents, and ended up having application-like features bolted on in horrendous ways. Being so completely free-form has not led to revolutionary interfaces as some claim, it's only made it a real nightmare to navigate. If the web was, instead, built upon some native application toolkit, (like, say: QT), we'd all be unimaginably better off for it. Instead, the economies of scale and design by committee has just pushed tons more crap into web browsers, and really just held back real technological progress. Hell, we'd probably have been better off sticking with Gopher.

I wonder if you're arguing against the concept of a web browser, or just its current horrific implementations. I absolutely agree that the web as it is today is a Frankenstein creation grown from the extremely limited/naïve utility it was originally intended for. There's also a stubborn refusal to drop much legacy support. That said, however, I think that the modern concept of the web browser - a common platform for remotely executed applications with an on-demand GUI - is enormous potential and utility.

Web applications don't inherently have to jump through 9000 layers of abstraction. Newer technologies like WebGL and WebSockets show a trend in the right direction, providing web applications with a relatively direct route of access to native APIs and protocols. There's always going to be overhead from being higher up the stack, but - assuming the web is a lot more efficient than it is today, and closer to the efficiency that it can theoretically achieve - it would be a very good trade-off for the benefits of remote execution and a flexible GUI.

Although I'm a heavy Apple user I prefer how MS behaves with regards to web standards today than Apple. They are constructive, they contribute their propositions to standards bodies (Apple declined to provide a royalty-free license to their touch events API), their web tests are cross-browser (Apple's HTML5 demonstrations were sometimes written for WebKit only, although other browsers could handle them, too), etc.

I like the new MS attitude to the Web. The future for web developers is bright.

This discussion is probably the most incoherent mess I've ever read on Ars - I don't know what you all have been doing wrong, but I've got a PC with more power than it needs to run browsers, all of which are fast, light, and responsive.

I don't need hundreds of single-use apps for whatever your logic might be. Among many other problems, devs would need to start from the ground up writing apps. I don't know about all of you, but I sure as hell wouldn't start over from the ground up with a web app. What's the practical answer? Writing a wrapper around a rendering engine, rather than every site reinventing the wheel over and over again. In that case, how about I just use, ya know, a web browser?

On topic, though, oddly, now that I understand MS' position, I think I'm on their side. I never thought that would happen in a discussion of web standards.

It seems like this thread has gone dangerously off topic... But here's my two cents.

Doesn't this seem like the way the HTML5 Working Group side-stepped the W3C? Things like Canvas and the various magical CSS3 properties happened because one of the browser vendors shipped a functional product, then encouraged their competitors to make compatible implementations through a draft specification.

A "standard" isn't useful if nobody uses it. If Microsoft puts their money where their mouth is and uses their proposed standard to open up the Skype walled garden without forcing everyone else to deal with the legacy spaghetti, then this could be a step in the right direction. Imagine if one day you could call between Skype and FaceTime.

I find it hilarious when I read comments saying how they like the "new" Microsoft way of doing things. Seriously does anyone really believe that they are working in your best interest? This is nothing more than a game they're playing to regain their control over open standards that benefit everyone equally.

Blind hate won't get you anywhere. Reading the article will.

They are proposing an open standard that seems beneficial for more things than the other proposed standard.