back to article Microsoft offers alternative Lync-like web chat spec to W3C

Microsoft has submitted a proposed standard for real-time web communications to the World Wide Web Consortium (W3C), in a move that could upset the apple cart for other browser vendors who have been working on their own such standard since early 2011. Microsoft, like Google, Mozilla, and Opera, all want web browsers to be able …


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    Something else that works in every browser in the universe except IE? Again? Fuck you, Microsoft, fuck you.

    1. Anonymous Coward

      Ahh well, finger's crossed Apple decide to take the existing standard under their wing. Given IE is only on Windows, and Windows is seeing declining market share, IE will soon be completely irrelevant.

      That dodgy NCSA Mosaic-based rellic will be a thing of the past if they keep this up.

    2. Anonymous Coward


      Nah, it'll work. IF we're willing to pay enough money for it.

      Coming up next: Microsoft study reveals Internet users to be "cheapskates".

  2. Magnus_Pym

    Dear Microsoft

    Attempts to tie users in to existing de facto standards can only work if you have the de facto standard already.

    1. jonathanb Silver badge

      Re: Dear Microsoft

      And Skype is the de-facto standard

  3. wowfood

    but in a surprise move on Monday the software giant submitted its own, competing specification to the W3C's WebRTC working group

    Surprise move? This is MICROSOFT we're talking about, and IE, how the hell is them going off and making their own standards nobody else will use a surprise anymore?

  4. TeeCee Gold badge

    Hold fire on the hate....

    "[WebRTC] shows no signs of offering real world interoperability with existing VoIP phones, and mobile phones, from behind firewalls and across routers,"

    If any of that is true, they are quite correct, it's shit and needs to be changed before we get lumbered with yet another half-arsed standard.

    I reckon the problem here is in the standard's SIP derivation. Anyone who's sat behind a router or firewall and jumped through hoops with STUN servers and / or SIP proxies will know how desperately that needs a rework. I happen to use a SIP service, but it is perishingly close to rocket science to get working and even I recognise that Skype has a shitload of "it just works" that SIP lacks, which is essential to anything aimed at end-users. If MS are offering anything like the Skype transport mechanism here (and it certainly looks like it), the W3C really ought to have a rethink.

    1. sabroni Silver badge

      Excuse me, Mr. Sensible argument....

      This is MICROSOFT we're talking about!!

    2. h4rm0ny

      Re: Hold fire on the hate....

      I linked to the drafts below - you sound like someone who will understand the details in them. But I think anyone with a reasonably good IT background can get a feel from both of them. Compare equivalent snippets of the security handling between the two documents:

      Draft X

      interface CertificateInformation {

      static CertificateInformation getLocalCertificate ();

      readonly attribute ArrayBuffer certificate;

      readonly attribute DOMString subject;

      readonly attribute CertificateFingerprints fingerprint;


      dictionary SrtpSecurityDescription {

      DOMString encrypt = "AES-CM";

      boolean encryptRtp = true;

      boolean encryptRtcp = true;

      unsigned short keystreamPrefix = 0;

      DOMString authenticate = "HMAC-SHA1";

      unsigned short n_a = 160;

      unsigned short n_tag = 80;

      DOMString keyDerivation = "AES-CM";

      unsigned long keyDerivationInterval = 0;

      ArrayBuffer key;

      ArrayBuffer salt;

      unsigned long? windowSizeHint;

      unsigned long long rtpPacketCount = 281474976710656;

      unsigned long long rtcpPacketCount = 2147483648;

      ArrayBuffer? mki;


      Applications that establish peer-to-peer transports require that the IP addresses of a peer are signaled to the remote peer. This can pose a privacy exposure even though an IP address can only be loosely correlated with a person. For instance, it is possible to use IP addresses to determine the physical location of a person.

      In some applications, establishing a peer-to-peer transport occurs prior to establishing user consent for the session. This can be necessary to remove the delays associated with transport setup that might otherwise occur after session acceptance. Exposing IP address information prior to acceptance provides the initiator of the session a way to collect the IP address of even an unwilling peer.

      Applications are encouraged to only signal relay ports prior to gaining explicit consent from users.

      End Draft X

      Draft Y

      To Do: Discuss privacy aspects of this from a finger printing point of view - it's probably around as bad as access to a canvas :-)

      End Draft Y

      The second one simply doesn't have a lot of what the first example has. It shuffles the whole area off elsewhere as far as I can see - and holes in a specification lead to fragmentation.

    3. Anonymous Coward
      Anonymous Coward

      Re: Hold fire on the hate....

      Fundamentally, any peer to peer protocol will have issues with a good stateful firewall. Any good admin will restrict what goes through a firewall, and will have a default deny rule in place, so any peer to peer VoIP protocol will have to be on specified ports so that an admin can allow it through. Add to that the mess that is NAT in IPv4 and NO protocol will work well without hackery (see Skype).

      When we finally get IPv6 widely adopted, much of the nastiness of VoIP (indeed, all peer to peer) will go away, and under that, SIP will work pretty well.

    4. Robert Carnegie Silver badge

      Re: Hold fire on the hate....

      An internet protocol that doesn't sneak through firewalls...

      Isn't that what a firewall is FOR?

      If I don't want my hypothetical employees to use chat or Skype personally in office hours, or to acquire the range of viruses and other malware that will be specific to that channel, such as BUGGING THE OFFICE THROUGH OUR PCs, it seems to me reasonable to expect to be able to block the protocols at the firewall.

  5. This post has been deleted by its author

  6. h4rm0ny

    What Opera said...

    "We look forward to assessing it on its technical merits."

    Whichever is the best protocol wins, imo. It's not as if any of us already have existing VoIP built into our web-browsers already and would have to shift.

    The two current specifications are here so people can make informed judgements rather than knee-jerk.

    MS Design

    RTC Draft

    If we go with something inadequate at this stage, it will lead to far greater fragmentation down the road if people have to produce their own work-arounds or alternates.

    1. nematoad Silver badge

      Re: What Opera said...

      "Whichever is the best protocol wins, imo"

      Don't forget the OOXML fiasco. MS bent the rules, packed committees and generally made an absolute nuisance of themselves just to try and see off the perceived threat of ODF. And what have we got now, two competing ISO specs, only one of which is capable of being implemented properly.

      MS learned a long time ago that if you have the wherewithal you can ram through your chosen option regardless of whether it is the best choice for the wider community.

      1. h4rm0ny

        Re: What Opera said...

        OOXML is a monster-bastard of a specification though. (As is ODF). OOXML spec runs to well over ten thousand pages (iirc). This draft comes to (I am guestimating from a scrolling web-page without page breaks), about twenty pages? The latter is obviously going to be orders of magnitude easier to conform to by any party. I can't see any reason why it would be a problem. And it's not like MS would have any unilateral power to change an accepted spec any more than anyone else would.

        "MS learned a long time ago that if you have the wherewithal you can ram through your chosen option regardless of whether it is the best choice for the wider community."

        This is why I posted links to the specifications - so that people could form judgements based on technical merit, which is after all what matters. I presume that given the spec would be equally implementable by all, that you would want the one that is best technically to be adopted. So basically, have you looked through them yet?

        Or alternately, you're reassured by W3C's long history of consistency, never having partial specifications and developing standards long before industry gives up and just starts doing its own thing in frustration. ;)

  7. Patrick O'Reilly


    The current WebRTC spec does not lack Peer-to-peer capability, it has both a P2P messengering and data API's. Even dev versions of Chrome have it implemented and hidden behind about:flags.

  8. Sir Didymus
    Thumb Up

    Hopefully lead to a better protocol

    Microsoft are offering technical input based on their extensive knowledge in the area. Seems like a good thing to me. The important part here is that they are going though the standards process and hopefully the good parts will be merged in to the existing draft spec so all will implement the final thing, whatever that may be.

  9. mikebartnz

    Typical MS

    Why the hell can't MS try and work with others instead of always running off and creating another standard like OOXML.

This topic is closed for new posts.

Other stories you might like