- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 19 Jan 2015 09:38:17 +0100
- To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Harald Tveit Alvestrand <harald@alvestrand.no>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 18/01/2015 16:38, Cullen Jennings (fluffy) wrote: > Specifically I would like the text in The working group will, once > WebRTC 1.0: Real-time Communication Between Browsers is considered > stable enough, consider working on a new set of APIsfor real-time > communication. changed to The working group will, once WebRTC 1.0: > Real-time Communication Between Browsers is finished (at CR), the > consider working on a new set of low level object oriented APIs for > real-time communication. That was more or less the intent of the existing text: given that the new process (under which the WebRTC 1.0 spec is evolving) doesn't have a LC, "stable" is pretty much equivalent to CR. I'm fine with either version. > The second issue is all the documents that are joint work with with > the DeviceWG. Having theses as joint work substantial complicates the > issues of resolving issues near the end the draft. I'm somewhat surprised by that comment; my impression had been that most of the overhead that having two groups implied was shouldered by the chairs and myself. And it didn't seem to me that our delays in getting gUM to Last Call had anything to do with having two WGs involved. > It's not even > really clear what would happen if the two WG had conflicting views on > how to resolve an issue in the draft. The same thing that would happen if different participants in a single WG had conflicting views (chairs seek consensus, make a decision if none is found, director intervenes if there is a formal objection). > Because of this I do not think > theses should be spread across two WG unless there is a specific > reason to do so. I know that the reasons we originally did this have > changed - both Microsoft and qualcom and listed on the webrtc members > page thought I don't know their actual status - so it is not clear we > should follow the same path with new specifications. From a purely procedural point of view, it's not really up to this WG to decide whether the other Working Group wants to continue their chartered work on the specs; in particular, this question probably doesn't need to be settled before we move forward with the charter (which of course doesn't mean we should not have that conversation). In terms of what we would lose if we were to ask the Device APIs Working Group to entrust the WebRTC Working Group with the development of these specs and if they agreed to that request: * the patent commitments from companies that are member of DAP and not of WebRTC, specifically Access, Blackberry, CDT, Deutsche Telekom, Fraunhofer Gesellschaft, IBM, iMinds, Institut Telecom, Intel, jQuery Foundation, LG Electronics, Mitre, RITT, Sony, Tomo-Digi, UCWeb, Vodafone, Yandex as of today * the editor of one our spec (media capture depth stream) whose company (Intel) is at least at this time not a Member of this group Dom
Received on Monday, 19 January 2015 08:38:33 UTC