Re: JavaScript API on top of SDP

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