Re: Proposed Charter Changes

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?