W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Cisco's position on the WebRTC API

From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 23 Jul 2013 22:52:12 -0700
Message-ID: <CABcZeBMQnMqA6jnm7Ne3BiLmdHx2W3S+sw=fzT-f+=o72+1+qg@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Tue, Jul 23, 2013 at 10:37 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  On 24/07/2013 1:05 AM, Eric Rescorla wrote:
>
> On Tue, Jul 23, 2013 at 9:58 PM, cowwoc <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.
>

Right. You're not being excluded.



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

Which developers have been stopped from posting directly here and how?
As far as I know this is an open list.


        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 I layer?
>
I don't understand this question. There was extremely extensive debate about
the API style and a WG decision was taken to proceed along the lines of the
current API. It's neither appropriate for useful for me to try to
recapitulate
the entire debate here. I refer you to the archives and meeting minutes.

-Ekr
Received on Wednesday, 24 July 2013 05:53:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC