- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Tue, 5 May 2015 16:27:01 +0000
- To: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
- CC: Justin Uberti <juberti@google.com>, Erik Lagerway <erik@hookflash.com>, Cullen Jennings <fluffy@iii.ca>, Eric Rescorla <ekr@rtfm.com>, "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
On May 5, 2015, at 12:01 PM, Göran Eriksson AP <goran.ap.eriksson@ericsson.com> wrote: > > Hi, > > Does Justins proposal reflect this? Looking at it, the approach for how to > solve it is good but we have the following comments: > > Direct control: The new APIs are intended to provide direct control over > the details of real-time communication, where the application can directly > specify how information should be transmitted, without any built-in > negotiation semantics. > > GE: This makes it clear that O/A is not included in the exposed > capabilities but I am not sure what ³where the application can directly > specify how information should be transmitted² adds/means? Drop unless > there is a meaning behind this I¹ve missed? [BA] I believe this refers to controlling use of RTP/RTCP mux, BUNDLE, etc. > GE: Here I have a problem: > The WG should not be bound to keep mistakes, omissions > compromises from legacy systems and technologies if these have a negative > impact on the Web Platform security, interoperability and performance. [BA] The question is how the decision about "mistakes" and "omissions" is made, particularly if those are encapsulated in RFCs that have not been updated or obsoleted. Currently the charter does not say much about functionality goals for the extensions, so it may be hard to draw the line on what is in and out. > 2) Plans for beyond the low-level API > > Our list of items for discussion is (which we of course are ready to > describe and discuss): > > And API surfaces for RTCWeb stack evolution we anticipate in at least the > following areas: > * More on ICE and Mobility. [BA] this one seems quite important, especially given the mobile take up of WebRTC. > * More multi-party. [BA] this one also seems important (including aspects such as simulcast and SVC). > * More multi-path. [BA] this one is not on my personal priority list. > * Data channel. [BA] Can we be more specific? Is this about a new API approach? Something else? > > We think the proposed charter is weak on work and deliverables [BA] While I would agree in general, Please do not try to take on EVERYTHING on the list. In addition to the new API work, a few compelling themes (e.g. Works great on mobile devices, supports conferencing) is probably enough to keep us busy.
Received on Tuesday, 5 May 2015 16:27:31 UTC