Re: Proposed Charter Changes

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 Tuesday, 5 May 2015 17:15:23 UTC