Re: Proposed Charter Changes

+1

On Sun, May 10, 2015 at 10:48 PM, Hutton, Andrew
<andrew.hutton@unify.com> wrote:
> +1, I also would support the proposed charter text at
> https://github.com/juberti/webrtc-charter/blob/alt/proposed-charter.txt.
>
>
>
> Regards
>
> Andy
>
>
>
>
>
> From: Alexandre GOUAILLARD [mailto:agouaillard@gmail.com]
> Sent: 08 May 2015 18:41
> To: Göran Eriksson AP
> Cc: Justin Uberti; Bernard Aboba; Erik Lagerway; Cullen Jennings; Eric
> Rescorla; Michael Champion (MS OPEN TECH); public-webrtc@w3.org; Stefan
> Håkansson LK
>
>
> Subject: Re: Proposed Charter Changes
>
>
>
> 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
>
>
>
>
> -----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
>
> ·



-- 
Victor Pascual Ávila

Received on Tuesday, 12 May 2015 09:45:28 UTC