Re: Proposed Charter Changes

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
>
>
>
>
>
>
>
>

Received on Thursday, 7 May 2015 13:30:11 UTC