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