Re: Proposed Charter Changes

I am generally supportive of Justin's proposed charter, with some
editorialish
(hopefully) changes I sent offlist.

-Ekr


On Fri, May 8, 2015 at 10:40 AM, Alexandre GOUAILLARD <agouaillard@gmail.com
> wrote:

> I like Justin change, and support that charter.
>
> On Thu, May 7, 2015 at 6:29 AM, Göran Eriksson AP <
> goran.ap.eriksson@ericsson.com> wrote:
>
>> Hi Justin,
>>
>> Assuming you mean [1] by "my proposed charter", I find it mostly
>> reasonable. My issue is that it scopes down what we do once 1.0 reaches
>> CR to only deal with the control of how media is sent over the network.
>>
>> The possible limitation in only “extending” 1.0 with respect to SDP is
>> also a concern I have.
>>
>> As I said in my mail we should also, once 1.0 reaches CR, deal with:
>>
>> * harmonization with rest of WebAppSec (and others) about Web platform
>> security evolution
>> * General User Security and Privacy improvements
>> * Delegation use cases (Web app from one origin, part of find and
>> connect, TURN, conference servers from another provider (and origin))
>> for verticals like Financial, E-health and Manufacturing
>>
>> In [2] there is the sentence "The Working Group will, once WebRTC
>> 1.0: Real-time Communication Between Browsers reaches Candidate
>> Recommendation, consider proposals for the next version of APIs." which
>> I find being less constrictive than your proposed text.
>>
>> Best Regards
>> Göran
>>
>> [1]
>> https://github.com/juberti/webrtc-charter/blob/alt/proposed-charter.txt
>> [2]
>>
>> https://htmlpreview.github.io/?https://github.com/w3c/webrtc-charter/blob/r
>> evision/webrtc-charter.html
>> <https://htmlpreview.github.io/?https://github.com/w3c/webrtc-charter/blob/revision/webrtc-charter.html>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Justin Uberti <juberti@google.com>
>> Date: Thursday 7 May 2015 00:36
>> To: Göran Eriksson <goran.ap.eriksson@ericsson.com>
>> Cc: Bernard Aboba <Bernard.Aboba@microsoft.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
>>
>> >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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
> --
> Alex. Gouaillard, PhD, PhD, MBA
>
> ------------------------------------------------------------------------------------
> CTO - Temasys Communications, S'pore / Mountain View
> President - CoSMo Software, Cambridge, MA
>
> ------------------------------------------------------------------------------------
> sg.linkedin.com/agouaillard
>
>    -
>
>