Re: Proposed Charter Changes

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.
>>>
>>>
>>>
>>
>>
>>
>>
>>
>