Re: JavaScript API on top of SDP

Hi Eric,

     I assume you are referring to 
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-11

     I see the following problems with this document:

 1. Section 4 states: "It is assumed that the user applications are
    executed on a browser". This assertion flies in the face of many of
    our use-cases.
 2. Without API examples, there is no feedback mechanism of how good/bad
    the API fits our use-cases. Recent conversations highlight why need
    such a mechanism.
 3. The document fails to explain the reasoning behind the design
    decisions that were made.

     Don't get me wrong: this is a good start. But this document is to a 
Design Document what voting is to Democracy. It is just the tip of the 
iceberg. We can, and should, do a lot more.

Gili


On 16/07/2013 1:42 AM, Eric Rescorla wrote:
> There already is a use-cases document in IETF.
>
> I don't think it really needs to come with API examples for each
> use case, though perhaps it would be useful for some of the less
> obvious ones.
>
> -Ekr
>
>
> On Mon, Jul 15, 2013 at 11:21 AM, cowwoc <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> wrote:
>
>     Hi Jim,
>
>         Over a month ago, I proposed publishing a design document in
>     which you would list all use-cases and how the API will address it
>     (insert a brief note as a place-holder, replace with formal API
>     when it becomes available). This document would be useful at this
>     point, as it would acknowledge that you are aware of the use-cases
>     and let us how you plan to address it.
>
>         Is the WG willing to publish such a document?
>
>     Thanks,
>     Gili
>
>
>     On 15/07/2013 2:05 PM, Jim Barnett wrote:
>>
>>     I think that the group has always known/assumed that we would
>>     need to specify what SDP features are supported, what can be
>>     modified, etc.  Maybe I’ve missed something, but I haven’t heard
>>     anyone say that this wasn’t necessary.   It’s just that we
>>     haven’t gotten around to it yet.
>>
>>     -Jim
>>
>>     *From:*Roman Shpount [mailto:roman@telurix.com]
>>     *Sent:* Monday, July 15, 2013 11:59 AM
>>     *To:* Jim Barnett
>>     *Cc:* public-webrtc@w3.org <mailto:public-webrtc@w3.org>
>>     *Subject:* Re: JavaScript API on top of SDP
>>
>>     On Mon, Jul 15, 2013 at 10:06 AM, Jim Barnett
>>     <Jim.Barnett@genesyslab.com <mailto:Jim.Barnett@genesyslab.com>>
>>     wrote:
>>
>>     We could add an object-oriented API that defined a javascript
>>     structure representing the SDP.  Developers could modify the
>>     structure using JavaScript, rather than having to parse it
>>     themselves.  Given such a JS structure, it would be easy to
>>     serialize it as JSON, so developers wouldn't  need to touch the
>>     SDP directly.  But they would still have the option to do so, if
>>     they wanted to do something that the API didn't cover (and it
>>     would be up to us to decide how much the API covered.)
>>
>>     - Jim
>>
>>     I think this API would be of very little use at best. The issue
>>     is that SDP in WebRTC is under-defined. Unless it is clearly
>>     specified what SDP features are supported, which portions of SDP
>>     can be modified and what these modifications mean, SDP does not
>>     present a valid API surface. It is possible to parse SDP and
>>     serialize it back from JavaScript. If you take a look at almost
>>     every WebRTC JavaScript library created so far, you would see
>>     that  practically each of them parses SDP. The problem is that
>>     SDP produced by the browser can change in a way that will render
>>     any code that relies on SDP data unoperational. For example,
>>     adding bundle will almost guarantee to break all current
>>     JavaScript code that deals with parsed SDP. Not the SDP parser,
>>     which will continue to work, but interpretation of this parsed
>>     data will no longer work and will need to be updated. Unless the
>>     meaning of each attribute and supported attribute values in SDP
>>     are defined somewhere, giving me a list of parsed attributes does
>>     not help me in any way.
>>
>>     So, unless you are planning to propose an API that replaces SDP
>>     with a JavaScript object with a well defined set of methods, and
>>     by doing so clearly specify supported media description
>>     functionality, this new API will not help in any meaningful way.
>>     Furthermore, unless supported SDP is clearly defined or replaced
>>     by well defined API this specification could never become a
>>     complete standard.
>>
>>     _____________
>>     Roman Shpount
>>
>
>