W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: Proposed Charter Changes

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Wed, 8 Apr 2015 12:26:44 +0000
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
CC: Peter Thatcher <pthatcher@google.com>, Justin Uberti <juberti@google.com>, Göran Eriksson AP <goran.ap.eriksson@ericsson.com>, "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>, "Erik Lagerway" <erik@hookflash.com>
Message-ID: <692281E3-A492-4A7A-8B5B-E37B1B1B3315@cisco.com>

I updated my proposal with Peter's text. The latest version is at 

https://github.com/fluffy/webrtc-charter/blob/fluffy/proposed-charter.txt



> On Apr 8, 2015, at 2:19 AM, Göran Eriksson AP <goran.ap.eriksson@ericsson.com> wrote:
> 
> 
> 
> 
>> 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 12:27:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC