W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

RE: Proposed Charter Changes

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Thu, 30 Apr 2015 01:52:36 +0000
To: Justin Uberti <juberti@google.com>, "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <BLUPR03MB149410C4AB53A37E2697661ECD60@BLUPR03MB149.namprd03.prod.outlook.com>
Support for 1.0 features is pretty important, what is often called "feature parity".  Some advancement beyond no-SDP is also needed because you need a carrot, not just removal of a stick.

In common usage, "API backward compatibility" has a very specific and quite different meaning - it means that 1.0 API calls are natively supported, and behave identically.

That would be a fine goal for a WG that wanted to refine an SDP + object model such as what we have in 1.0.

But those words preclude an API that does not include support for SDP - even if all features of 1.0 were supported, and a JS shim were feasible.

It's also ok to say "we will figure it out later when we know more". Sometimes kicking the can down the road is easier - just ask Congress.

From: Justin Uberti<mailto:juberti@google.com>
Sent: ż4/ż29/ż2015 12:57 PM
To: Michael Champion (MS OPEN TECH)<mailto:Michael.Champion@microsoft.com>
Cc: public-webrtc@w3.org<mailto:public-webrtc@w3.org>
Subject: Re: Proposed Charter Changes

I understand where you are coming from, but it would be good to have an example of something specific that we don't want to have to support in the future.

SDP munging is a clumsy API surface, but I am not sure it imposes any additional constraints on the lower layers.

On Wed, Apr 29, 2015 at 9:41 AM, Michael Champion (MS OPEN TECH) <Michael.Champion@microsoft.com<mailto:Michael.Champion@microsoft.com>> wrote:
Justin wrote:

> As mentioned yesterday, I think we have a better idea now of what 1.1 is going to be than what 1.0 was
> going to be when we started 1.0. IOW, I don't think you can really argue that we are signing a blank check here.

So what language might be appropriate in a 1.0 charter to put some discussion of 1.1 in scope?    I think everyone supports the goal of a smooth transition for app developers, especially if they can re-use the high level APIs unchanged in many scenarios.  Or as you put it in another message, if the constraint is "PeerConnection can be implemented atop the 1.1 objectsĒ I suspect everyone could live with that.   But as Tim Panton notes in this thread ďThe reality of the current API is that everyone has to mess with the SDP to get what they want, and frankly there is nothing lower level than regexps on SDP.Ē Thatís not a ďcompatibility" we want to inflict on posterity!

From: Justin Uberti
Date: Wednesday, April 29, 2015 at 9:12 AM
To: Michael Champion
Cc: "public-webrtc@w3.org<mailto:public-webrtc@w3.org>"
Subject: Re: Proposed Charter Changes

On Tue, Apr 28, 2015 at 10:24 PM, Michael Champion (MS OPEN TECH) <Michael.Champion@microsoft.com<mailto:Michael.Champion@microsoft.com>> wrote:
Cullen Jennings <fluffy@cisco.com<mailto:fluffy@cisco.com?Subject=Re%3A%20Proposed%20Charter%20Changes&In-Reply-To=%3CAF740A35-9FB8-4F56-A0BB-A4864880BC8E%40cisco.com%3E&References=%3CAF740A35-9FB8-4F56-A0BB-A4864880BC8E%40cisco.com%3E>> wrote:
> I put a diff at
> https://github.com/fluffy/webrtc-charter/compare/gh-pages...fluffy:ekr

That appears to compare EKRís proposal with the original charter that triggered formal objections.  Comparing Domís revised  charter proposal which addresses the objections in https://lists.w3.org/Archives/Public/public-webrtc/2015Mar/att-0046/webrtc-charter.html to EKRs in https://github.com/ekr/webrtc-charter/tree/ekr_revision  I see a number of significant changes.  EKRís proposal:

- Adds a 3rd year to the lifetime of the WG, saying that once 1.0 is stable, ďthe group will reevaluate its deliverables and milestones, and may reconsider its scope.Ē
- Adds language to the Deliverables section constraining future versions of the WebRTC spec to be backward compatible with 1.0
- Drops the formal liaison with the ORTC Community Group
- Drops language from the Decision Policy section saying that editors are responsible for reflecting the consensus in the WG and that those sections that havenít been reviewed by the WG should visibly reflect that fact

These changes are not likely to build bridges between the RTC communities, and are problematic for a number of reasons.  In particular  the idea that a WG ďmay reconsider its scopeĒ without going through a formal chartering process is incompatible with the W3C process and patent policy.  The scope statement is a key part of the WGís ďcontractĒ with the AC and what drives members IPR commitments when they join a WG.  If we have to go thru another rechartering exercise to put 1.1/NG deliverables in scope, letís have that discussion when we have stable specs and real world experience to discuss, not pencil it in now and change it later.

I strongly object to changing the Decision Policy section in Domís draft, which was negotiated as a way around the 2 formal objections. If there are substantive objections to the proposed decision policy, letís discuss.

On the ORTC liaison,the CG is a group with many of the same members as the WebRTC WG, and implementation experience with ORTC is exposing many questions about the underlying IETF specs and protocols that affect 1.0 as well.  No one is asking for joint decision making or a veto power, and it seems to be in the WebRTC WGís best interest to maintain open and respectful communications with the ORTC CG.

This proposal from Eric was an attempt to sketch out the general idea of what a 1.1 charter would look like, not to nail down all the details. It's good to raise these points but I think most of them are just oversights.

On constraining a future WebRTC standard to be backward compatible with 1.0, that seems reasonable in principle and Justin has sketched out an approach to keeping apps built for 1.0 working on in a future version. BUT there is a very big devil in the details: There is no stable version of 1.0 yet, so itís essentially signing a ďblank checkĒ, promising to support whatever the WG eventually fills in, irrespective of how it works in the real world.

As mentioned yesterday, I think we have a better idea now of what 1.1 is going to be than what 1.0 was going to be when we started 1.0. IOW, I don't think you can really argue that we are signing a blank check here.

The way forward Domís charter sketches out seems less confrontational:  The WG focuses on getting 1.0 stabilized, the ORTC CG works to see if itís ideas actually work for implementers and app developers. When 1.0 gets to CR we all look at the evidence of what works, what else is needed, and figure out a 1.1/NG charter that everyone can sign up to.  I donít particularly care whether the current WG charter is extended or Domís charter approved, but itís premature to draft a 1.1 charter while 1.0 is in flux and ORTC is still learning from  implementation experience.  For those who disagree, let's start with Domís draft and see if there are tweaks to satisfy both those who want to have NG work in scope, and those who want to see the WG prove it can build  consensus on a 1.0 spec before claiming ownership of  the next generation.
Received on Thursday, 30 April 2015 01:53:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC