Re: Proposal: Different specifications for different target audiences

On Fri, Jul 19, 2013 at 11:39 AM, Matthew Kaufman (SKYPE) <
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]
> *Sent:* Friday, July 19, 2013 9:17 AM
> *To:* 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:****
>
>
>     - One for Browser Vendors.****
>       - One for Integrators.****
>       - One for Web Developers.****
>
>     What do you think?
>
> Gili ****
>

Received on Sunday, 21 July 2013 21:08:50 UTC