- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Mon, 15 Jul 2013 16:47:38 +0200
- To: Jim Barnett <Jim.Barnett@genesyslab.com>
- Cc: Peter Thatcher <pthatcher@google.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
2013/7/15 Jim Barnett <Jim.Barnett@genesyslab.com>: > I’m not sure even the revised 3) is correct. There is certainly a strong > focus on getting version 1 done, and on not un-doing work that has already > been done. However a carefully designed API sitting on top of SDP would be > largely independent of the rest of the API and would not necessarily delay > things. Hi Jim, please let me know if I understand correctly: So many people in this list has given lot of rationale explaining why the current model is not good. Developers have confirmed it in a survey. The arguments (along with others) are: - SDP O/A mandate is an artifice. We don't need O/A, and it can be done by the JS APP. - SDP fixed model is bad for interoperability (even for SIP). - Current SDP model makes it impossible to implement in the browser whatever different than SIP or something not based on plain-SDP O/A (i.e. Jingle XEP-0167 which uses SDP-XML) - Many others... All of them are properly explained in a draft: http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-01 But now it seems that "adding a few API methods on top of the SessionDescription Object" is the only we all need, am I right? > If we just elaborate RTCSDPType, only section 4.7 is affected. > If it got done in time, it would be part of version 1. If it didn’t, it > could end up in a later version. Honestly I would like to read some kind of veredict on this topic from chairs. At this point I do not know *who* is deciding or assuming the conclusion you assert, and people does not want to waste time providing new API proposals if they are doomed before birth. Best regards. -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Monday, 15 July 2013 14:48:26 UTC