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

   -