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

That feels like a good, practical approach right now. Focus on getting 1.0
done. Personally I hope we will also see focus on testing soon in the WG,
including nailing down the protocol parts done as well, i.e the relevant
IETF drafts to LC.

Again, +1 to Peters proposal.


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

Received on Wednesday, 8 April 2015 08:19:45 UTC