RE: Proposed Charter Changes

Cullen, I see that your proposal doesn't include two sentences in Dom's proposal under Decision Policy:



Editors are responsible for reflecting the consensus from the Working Group in the specifications; where editors bring technical solutions in the specifications that have not been reviewed by the group, these solutions are annotated to reflect their status.



Contributors are encouraged to bring specific modifications (e.g. as patches) to the group's specifications to facilitate their review by the group and eventual integration by the editors.



Was this an oversight, or do you object to including that text?



Likewise it excludes the liaison with the ORTC Community Group mentioned in Dom's draft. I think it would be useful to make the liaison explicit even though the overlap in membership between the WG and CG means that formal liaison mechanisms are probably overkill.





-----Original Message-----
From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
Sent: Wednesday, April 8, 2015 5:27 AM
To: public-webrtc@w3.org
Cc: Peter Thatcher; Justin Uberti; Göran Eriksson AP; Michael Champion (MS OPEN TECH); Erik Lagerway
Subject: Re: Proposed Charter Changes





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

>>

>>

>>

>>

>>

>>

>>

>>

>>

>

>

>