Re: Cisco's position on the WebRTC API

On 24/07/2013 1:05 AM, Eric Rescorla wrote:
> On Tue, Jul 23, 2013 at 9:58 PM, cowwoc <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> wrote:
>
>     On 23/07/2013 11:59 PM, Eric Rescorla wrote:
>>         We need more frequent webrtc-public IRC meetings
>>
>>     I (and I suspect others) prefer con calls to IRC meetings. I
>>     don't think this presents an undue
>>     barrier to entry.
>
>         No problem. Please announce these on webrtc-public with
>     instructions on how to join and we will happily meet you there.
>
>
> Conference calls *are* announced on webrtc-public. For instance:
>
> http://lists.w3.org/Archives/Public/public-webrtc/2013Jun/0003.html
>
> How do you think the WG members find out about them.

     I was there. I assumed you had other (unannounced) meetings since 
then because it's almost been 2 months.stopping developers from posting 
directly here.

>         The solution I am leaning towards is divorcing WebRTC from
>     Telecoms and Web Developers. This sounds like the easiest
>     solution. In that case I would expect Browser Vendors to agree to
>     a common API that is interoperable across all browsers and (key
>     point!) does not unduly influence design decisions of APIs placed
>     on top of it. From a decision-making process point of view, things
>     should move a lot faster because each one of us will be
>     negotiating with similarly-minded players.
>
>
> Nothing is stopping you from proposing some new JS API in another
> forum. This WG is about deciding the API that's implemented in the 
> browser.

     I understand that. All I was saying is I don't understand the 
coupling between the Browser API and Telecom requirements. I mean,

  * If the WG is producing an API for web browsers (not Telecom
    gateways), and
  * It's technically feasible to layer a Telecom API on top of this
    (that uses SDP)

     then why is the WG mandating this part of the spec? Why isn't it 
"out of scope" like the initial offer/answer transport layer?

Gili