Re: JavaScript API on top of SDP

On 07/16/2013 06:05 PM, cowwoc wrote:
> 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.
>
I think I have to ask you to explain that. As far as I can tell, every 
use case in that document executes on a browser (but often communicates 
with non-browser components).

> 1.
>
>
>  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.
>
But those examples don't belong in the use cases and requirements 
document; they might belong in a document showing how the API satisfies 
the use cases.
>
>  1. The document fails to explain the reasoning behind the design
>     decisions that were made.
>
The -overview document is the place to explain design decisions. Use 
cases documents are not supposed to be the place where you make design; 
they guide design, they don't mandate it.

>     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
>>>
>>
>>
>