Re: Proposal: Different specifications for different target audiences

Ted,

     I don't think there is a conflict here (at least with respect to my 
original proposal).

     I view API calls as requests/hints to the layers that lie below it 
(high-level API to low-level API to signaling layer). The goal is for us 
to tell the lower layers "what" not "how" we want them to do and you are 
free to reject these requests for security reasons.

Gili

On 21/07/2013 5:08 PM, Ted Hardie wrote:
> On Fri, Jul 19, 2013 at 11:39 AM, Matthew Kaufman (SKYPE) 
> <matthew.kaufman@skype.net <mailto:matthew.kaufman@skype.net>> wrote:
>
>     Doesn’t solve the basic problem.
>
>     You don’t want **any** specification that describes a “signaling
>     layer” over which the browsers conspire with each other to do
>     something other than what you asked for in the JavaScript API.
>
>
> "conspire" is an interesting term.  The current security documents 
> pretty much treat the JavaScript as potentially malicious (because, 
> you know, reality); that means that there are certain things we want 
> *something* to intermediate its behaviour for.  Without that, voice 
> hammer and other attacks become trivial.
>
> If it is not the browser or web framework, what solves that problem?
>
> If it is the browser, don't you have the situation where the browser 
> or mobile framework essentially talks to a peers' browser or mobile 
> framework for the elements which bear that risk?
>
> We can push things about the plate all we want, but there's some 
> spinach there that needs eating up, eh?
>
> regards,
>
> Ted
>
>     Matthew Kaufman
>
>     *From:*cowwoc [mailto:cowwoc@bbs.darktech.org
>     <mailto:cowwoc@bbs.darktech.org>]
>     *Sent:* Friday, July 19, 2013 9:17 AM
>     *To:* public-webrtc@w3.org <mailto:public-webrtc@w3.org>
>     *Subject:* Proposal: Different specifications for different target
>     audiences
>
>
>         The WebRTC specification has 3 target audiences:
>
>      1. Browser vendors
>      2. Integrators
>      3. Application Developers
>
>         Currently, we have lump them into a single category and put
>     out a single specification document and API for all three. I
>     believe this is a huge mistake and the cause of most of our
>     problems. It is reasonable that these people cannot come to an
>     agreement because they have different (perfectly reasonable!)
>     requirements.
>
>         I propose doing the following:
>
>      1. Browser vendors publish a signaling layer specification.
>      2. Integrators publish a low-level (object-oriented) API.
>      3. Application Developers publish a high-level (object-oriented) API.
>      4. Browser vendors implement the low-level API on top of the
>         signaling layer.
>      5. Application Developers implement the  high-level API on top of
>         the low-level API.
>
>         Benefits:
>
>       * The browser vendor implements the low-level API once and both
>         Integrators and Application Developers reuse this code (as
>         opposed to everyone digging their fingers into the signaling
>         layer as we're currently forced to for some common use-cases).
>       * Integrators get the low-level API they need to ensure
>         interoperability.
>       * Application Developers get a high-level API.
>       * Both Integrators and Application Developers are now protected
>         from changes to the signaling layer. The underlying signaling
>         protocol may change without breaking their code.
>       * On the flip side, browser vendors are free to change the
>         underlying signaling protocol with much less backwards
>         compatibility baggage.
>       * Application Developers who want to explore experimental
>         features or advanced use-cases can use the low-level API as
>         needed.
>
>         Process:
>
>       * The APIs should be driven by use-cases and developed from the
>         top-down.
>       * Meaning, Web Developer use-cases should drive the high-level
>         API which, in turn, will drive changes to the low-level API
>         and signaling layer.
>       * Similarly, Integrator use-cases should drive the low-level API
>         which, in turn, will drive changes to the signaling layer.
>       * Ideally, implementation details should never travel upwards.
>         Meaning, signaling layer requirements should not leak up to
>         the high-level API.
>       * We publish separate documents for the different target audiences:
>
>           o One for Browser Vendors.
>           o One for Integrators.
>           o One for Web Developers.
>
>         What do you think?
>
>     Gili
>
>