Re: Proposed Charter Changes

Göran, are you supportive of my proposed charter? I couldn't tell exactly
from your last message.

On Tue, May 5, 2015 at 7:14 PM, Göran Eriksson AP <
goran.ap.eriksson@ericsson.com> wrote:

> Hi Bernard,
>
> Comments online (thanks for response).
>
> To avoid misunderstandings; we want focus on 1.0 and getting the “low
> level API” work done. The stuff on our list is only application
> AFTER that has been done but since the rechartering text seem to have been
> dropped in the proposed charter, we felt we needed to raise this.
>
> We think it should be reflected in either the charter or elsewhere, that
> this discussion will take place at a later time
>
>
> Göran
>
> -----Original Message-----
> From: Bernard Aboba <Bernard.Aboba@microsoft.com>
> Date: Tuesday 5 May 2015 18:27
> To: Göran Eriksson <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>, W3C WEBRTC <public-webrtc@w3.org>,
> Stefan Håkansson <stefan.lk.hakansson@ericsson.com>
> Subject: Re: Proposed Charter Changes
>
> >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: Ok, makes sense. Comment withdrawn.
>
> >
> >
> >> 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.
> GE: See what You mean but NOT allowing the WG/Community to consider this
> is not nice either… a rock and a hard place… But I think we need to make
> an effort to come up with a way to also evolve this part of the RTC
> platform.
> >
> >> 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).
> GE: Yes, and there may be other things coming up. We’re interested to
> explore beyond iFrame sandbox.
>
> >
> >> * More multi-path.
> >
> >[BA] this one is not on my personal priority list.
> GE: :-). Well, must admit it is not any of mine either, especially if the
> path selection is done out-of-control of the application, :-).
> But that does not mean we should not discuss this at some point I think.
>
>
> >
> >> * Data channel.
> >
> >[BA] Can we be more specific? Is this about a new API approach? Something
> >else?
> GE: This is perhaps a bit disruptive- sorry for that- but I have cases
> where QUIC(and what IETF comes up with for NG transport protocol) would be
> a nice option to have, allowing me to harmonise a server side realisation
> as well as with rest of the browser networking. Will this affect the API?
> Hopefully not- the Web API should not be specific to the transport
> protocol.
>
>
> >
> >>
> >> 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.
>
> GE: Agreed. Whether that is the appropriate priority or not I am less
> convinced of- the security including delegation are important from a
> WebAPI and Enterprise CS/IO perspective. I am a bit worried that what it
> means to have a “great” mobile solution is not 100% well defined (somewhat
> of a moving target).
>
> But again, this are post- 1.0 and “low level API” issues. What do be done
> then can be discussed later. We think it should be reflected in either the
> charter or elsewhere,
> that this discussion will take place at a later time.
>
> Best regards
> Göran
>
>
>
>