Re: Proposed Charter Changes

Based on concerns raised and after speaking to several WG and CG
participants, I am proposing the following changes:

- removed liaison requirement
- added some copy around getting the groups working together
- changed "low-level" to Object
- changed "high-level" to 1.0 SDP

I believe this addresses most of the concerns and feels like a common
ground we can start from, the proposal in its entirety is attached.

Cheers,
Erik


On Thu, Apr 30, 2015 at 8:00 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Wed, Apr 29, 2015 at 6:52 PM, Bernard Aboba <
> Bernard.Aboba@microsoft.com> wrote:
>
>>  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.
>>
>
> Thanks for making this point sharp.
>
> "Native" can mean two things in this context:
>
> 1. Written in some native language, such as C++ and not JS.
> 2. Built-in so that the browser supports it without the site having to do
> anything.
>
> What I mean is the latter. More specifically: sites which work now should
> work
> in a browser which implements the 1.1 API without *any* modification to
> those
> sites, including loading a JS polyfill [0]. If this is truly the point of
> contention
> and people want the WG to develop an API that doesn't have this property,
> then I don't see much possibility for consensus.
>
> -Ekr
>
> [0] Modulo changes made for extremely compelling reasons, like we found
> something which was actually broken and on which almost nobody relied.
>
>
> 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 <juberti@google.com>
>> Sent: ‎4/‎29/‎2015 12:57 PM
>> To: Michael Champion (MS OPEN TECH) <Michael.Champion@microsoft.com>
>>
>> Cc: 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> 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"
>>> Subject: Re: Proposed Charter Changes
>>>
>>>
>>>
>>>  On Tue, Apr 28, 2015 at 10:24 PM, Michael Champion (MS OPEN TECH) <
>>> Michael.Champion@microsoft.com> wrote:
>>>
>>>>  Cullen Jennings <fluffy@cisco.com
>>>> <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.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>