Re: Proposed Charter Changes

+1 , that works for Hookflash as well.

Erik Lagerway - m. 604.562.8647

> On Apr 7, 2015, at 5:04 PM, Michael Champion (MS OPEN TECH) <Michael.Champion@microsoft.com> wrote:
> 
> > The working group will, once WebRTC 1.0: Real-time Communication Between Browsers reaches Candidate Recommendation, consider proposals for the next version of APIs."
>  
> Thanks Peter, that approach works for Microsoft.
>  
> From: Peter Thatcher [mailto:pthatcher@google.com] 
> Sent: Tuesday, April 7, 2015 2:12 PM
> To: Justin Uberti
> Cc: Michael Champion (MS OPEN TECH); public-webrtc@w3.org; Erik Lagerway
> Subject: 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?
>