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

Re: Proposed Charter Changes

From: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
Date: Sun, 5 Apr 2015 09:47:40 +0000
To: "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>, "Justin Uberti" <juberti@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, Erik Lagerway <erik@hookflash.com>
Message-ID: <D146C9E0.11CE9%goran.ap.eriksson@ericsson.com>



>> I am just a simple engineer, so these process issues frighten and
>>confuse me. 
>
>
>A normal human reaction to W3C-speak, sorry :-)  2 simple questions :
>
>
>- Why should we be worrying  about the charter for a next generation
>standard when the first generation standard is still in flux?
>
>
>-  Why should that next generation charter insist on support for SDP when
>the details of the SDP signaling have been so difficult and contentious
>to get right in 1.0?
>
>
>Iım sure some other members prefer a different future direction than we
>do, so  I prefer Domıs charter that defers this controversy until we have
>more independent implementation experience with SDP-based and
>object-oriented APIs and we can have a more
> data-driven discussion.

But Domıs charter extends the 1.0 charter to March 2017- surely we cannot
wait until then with this discussion and work?

Now I am also not very comfortable with W3C-speak so I may have
misunderstood this. If so, please help me out.



>
>
>
>
>From: Justin Uberti
>Date: Friday, April 3, 2015 at 5:41 PM
>To: Michael Champion
>Cc: "public-webrtc@w3.org", Erik Lagerway
>Subject: 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?
>>
>>
>>
>>
>>
Received on Sunday, 5 April 2015 09:48:07 UTC

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