Re: Proposed Charter Changes

> But Dom¹s charter extends the 1.0 charter to March 2017- surely we cannot
> wait until then with this discussion and work?

I agree, and here’s how I suggest proceeding: The emerging trend in W3C is toward launching formal standardization in a working group AFTER there is a fairly well-baked proposal on the table.  W3C created the Community Group mechanism about 4 years ago to make it easy to incubate specs in a lightweight manner — minimal process, and a IP policy that requires patent commitments on one’s own contributions but not (initially) on everything that might possibly go in a spec. Once the CG creates a fairly stable spec, it can go out for wide patent commitments via a “Final Specification Agreement” and / or it can be contributed to an existing or proposed working group to make it a standard and thus get broad patent commitments. That’s what a community of people — who believe SDP is a “boat anchor” that makes advanced features and interoperability difficult —  did 2 years ago when it became clear that the SDP debate was slowing down the WebRTC WG and consensus on a way forward was unlikely.

One feature of Community Groups is that they don’t have an exclusive “charter” to some problem domain, they offer their specs under a copyright license that lets others fork them.  If the community of people who think that SDP doesn’t get enough appreciation as the way forward want to form a Community Group, they can take whatever they want from the ORTC spec as well as the 1.0 spec, add SDP requirements as they see fit, and still get the patent commitments on contributions people made to ORTC.  This approach was modeled on the way many open source projects work, making faster progress with less process overhead than traditional standards bodies … while still offering an “on-ramp” to formal standardization.  

So my suggestion is basically:
- The WebRTC WG focuses on getting 1.0 standardized

- The ORTC CG will keep refining its proposal for a next-generation standard based on implementation experience (both building shims on top of 1.0 codebases and in implementing the spec from scratch, as Microsoft is doing)

- Alternative proposals for a “Next Generation” spec might get proposed in the ORTC CG (admittedly, those that require SDP might not get a friendly reception) OR incubated in a something like a “SDP-RTC-NG” Community Group that can be created by 5 people, W3C membership not required) and can fork whatever parts of ORTC they want.  In short, there’s a very low barrier to entry to people who want to propose alternatives to ORTC as the way forward.

- Anyone can implement any of these specs in shippable browser code, forks of browsers, shims on top of shipping products, whatever … with the goal of getting implementation and usage experience to demonstrate how the various proposals can actually work.  They can’t claim what they code to is a “standard” of course.

- When WebRTC 1.0 is stable (a Candidate Recommendation maybe) and there are concrete proposals on the table for a 1.1 or 2.0 API out there, W3C can convene some sort of formal or informal consensus-building exercise with the various people and organizations that have put skin in the game for WebRTC 1.0, ORTC, and one or more alternate proposals and the real-world data they produce. W3C staff can assess whether they can create a charter with critical mass of people who will sign up for it.  That could happen anytime, no need to wait until early 2017 *if* 1.0 is largely done and there are 1.1/2.0 draft specs on the table.

That is different than how it’s traditionally been done at W3C, where a WG gets a charter that is stakes out its territory and the WG builds consensus on a way to make that patch of turf productive.  The trouble is, it’s just too hard to get consensus on how to farm the land the WebRTC WG has staked out, and I believe a new approach will be more productive in the long run even if it’s potentially chaotic in the short term.

This is my personal proposal not necessarily “Microsoft’s” so I’m happy to hear alternatives or refinements. But to be successful, proposals have to address the fundamental problem that different people with deep expertise in RTC have quite different opinions on how to develop RTC APIs for the Web, most especially about the role of SDP in those APIs.





-----Original Message-----
From: tim panton
Date: Sunday, April 5, 2015 at 3:41 AM
To: "public-webrtc@w3.org"
Cc: Michael Champion, Justin Uberti, Erik Lagerway, Göran Eriksson AP
Subject: Re: Proposed Charter Changes

>I think we need to be _very_ clear about what we mean by ‘compatibility’ -
>I think it is reasonable to expect that future post 1.0 releases of the webRTC standard(s) should
>be compatible with 1.0 .
>For me that means : 
>1) The wire format is fully compatible -> 1.0 and 1.1 browsers and devices can exchange media
>and data channels with no gateways.  
> This is largely an IETF matter, but the W3C should avoid doing anything that precludes it.
>2) Web apps written to the 1.0 standard should work in 1.1 implementations. (if we went to 2.0 that expectation
>might be relaxed somewhat). 
>
>However…. I don’t expect this to apply to apps which have manipulated the SDP directly
>(as described by Chris Wendt <chris-w3c@chriswendt.net>
>
>> We’ve had to essentially hack the system with the current SDP exchange in many respects and at a minimum pass a bunch of redundant information.
>)
>
>I think it is reasonable to expect javascript programmers to add dynamic polyfill here if it detects that
>the browser implements a new version of the standard and use that pollyfill to tweak bandwidths or mark
>which track is from a screenshare (for example).
>
>So I expect that 1.1 (and to a lesser extent 2.0) would implement all the javascript object/methods/properties and callbacks
>specified in 1.0 - but I don’t expect the content of the supposedly 'opaque blobs’ to backwards compatible.
>
>In some ways this is regrettable - since almost all of my webRTC apps to date have had to mess with the SDP,
>but I’m still hoping that as we get to 1.0 the need for this will be reduced. 
>
>Having spent the last month working with web devs and watching their first exposure to the ‘joys’ of SDP 
>I think that for webRTC to be a popular API, we may need to remove SDP as an API mechanism so we
>should not make charter decisions now that preclude that future choice.
>
>
>Tim.
>
>
>

Received on Sunday, 5 April 2015 17:45:35 UTC