Re: Discussing new API proposals

I would love to see such a proposal brought to the table, except we all 
have one major problem. The definition for what is the requirements for 
WebRTC 1.0 seems to be tied to the definition of "what is SDP for the 
browser".

If I just took these two drafts alone:
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-11
http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-07

Then a reasonable API that satisfies those use cases could be made.

If we have to consider:
http://tools.ietf.org/html/draft-ietf-rtcweb-jsep

The we have to define an API that must define all-SDP like features 
might be mapped, e.g.:
http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-03

We could hand wave and say "SDP should be generated via JavaScript" and 
"we will support 1.0 features that can be mapped to SDP and here's how" 
. That currently appears to be an impossible, because we don't know what 
needs to be allowed to be mapped to/from SDP if there is no fixed 
definition for what must be supported in SDP.

For WebRTC 1.0 to be completed with the SDP mandate as it stands, the 
definitive SDP list must be outlined.

How can anyone bring a reasonable alternative approach to the table in 
such a catch-22 situation?

-Robin


> Stefan Håkansson LK <mailto:stefan.lk.hakansson@ericsson.com>
> 17 July, 2013 8:29 AM
> The current approach for 1.0 is to use SDP, but if someone contributes 
> a (detailed) proposal that takes us faster to the goal of a stable 
> spec, maintains functionality and still would be possible to translate 
> to/from SDP, then I think people would listen. My personal view is 
> that we should get to a stable 1.0 ASAP (and therefore I would like to 
> change as few assumptions and design choices as possible), and if 
> there are things that make that faster we should consider them. That 
> said, the devil is often i the details, and something that looks 
> simpler at surface can prove to take a lot of effort when you start 
> getting into the bits and pieces.