Re: Proposed Charter Changes

I'm also just a simple engineer, unclear on what has to go in a charter and
what doesn't.   But it sounds to me like we're all trying to decide on and
agree upon what "1.1" and "compatibility" mean right now, even though we
could just as easily decide that later.  Could we simply change the charter
text to the this?

"As the name implies, WebRTC 1.0: Real-time Communication Between Browsers
is to be considered as a first version of APIs for real-time communication.
The working group will, once WebRTC 1.0: Real-time Communication Between
Browsers reaches Candidate Recommendation, consider proposals for the next
version of APIs."

Then we could save all this discussion for what "next version" means after
we have the charter to make one, and the process of chartering wouldn't be
blocked.

On Fri, Apr 3, 2015 at 5:41 PM, Justin Uberti <juberti@google.com> wrote:

> I am just a simple engineer, so these process issues frighten and confuse
> me. Nevertheless, I've tried to respond to the concerns you raised below:
>
> On Thu, Apr 2, 2015 at 8:49 PM, Michael Champion (MS OPEN TECH) <
> Michael.Champion@microsoft.com> wrote:
>
>> I’ve seen Cullen’s  counterproposal [1] to Dom’s proposed charter
>> revision [2] that addressed comments on the charter balloted by the AC. As
>> Microsoft’s Advisory Committee representative who filed one of those
>> comments, I see two fairly fundamental issues here.
>>
>> First, we strongly believe the WebRTC WG should focus on getting WebRTC
>> 1.0 done as soon as possible, and that work shouldn’t be distracted by
>> discussions about a next-generation standard.  Contrary to some assertions
>> expressed on this list,  Microsoft  and Hookflash  do want to see a WebRTC
>> 1.0 Recommendation completed that reflects the WG consensus to integrate an
>> object model, along the lines proposed by Justin Uberti.   Also, having a
>> basic object framework within WebRTC 1.0 (even if the objects are not used
>> for direct control) is an important step toward future work.  Until the
>> WebRTC 1.0 standard is completed, it is premature to talk about
>> interoperability between WebRTC 1.0 and some future standard.
>>
>
> I don't entirely get the concern about compatibility. For the benefit of
> developers using WebRTC, wouldn't we want to ensure this?
>
>>
>>  Second, we see a major distinction between chartering the WEBRTC WG to
>> “extend” the WebRTC 1.0 API, while retaining the SDP control mechanism, and
>> working on an API that does not utilize SDP.  In our view, a WebRTC 1.0 API
>> with objects only has limited opportunities for extension within the object
>> model, since the objects could only be used to provide functionality that
>> is not negotiated.  As a result, we view the former approach as more of a
>> “WebRTC 1.0 maintenance” exercise.   ORTC’s goal has been to support the
>> WebRTC 1.0 feature set without SDP,  which we view as an approach better
>> able to accommodate advanced video in the short term and significant
>> additional functionality in the long term.  While we recognize there are
>> different views on the way forward, we don’t think constraining future
>> specs to be backward compatible with 1.0 is a good idea, certainly not at
>> this point when the 1.0 spec is still immature and interoperability between
>> independent implementations of 1.0 has not been rigorously demonstrated.
>>
>
> The path we have been on (IIUC) is that if you program to the high level
> API (e.g. PeerConnection), you don't get to set all the knobs at the low
> level. If you program directly to the low level objects (e.g.
> RtpSender/RtpReceiver/Transport/etc), you get full control, but you're on
> your own for signaling.
>
> I don't see any problem with calling this "extending 1.0", and this seems
> like the best path for everyone involved - it is good for developers and
> easy to explain. Do you have some alternate future scenario in mind that
> you want to allow for?
>