Re: [rtcweb] Draft agenda for IETF 87

[Peter Thatcher <[e-mail]>]

On Fri, Jul 12, 2013 at 12:35 AM, Stefan Håkansson LK <
[e-mail]> wrote:

> On 7/11/13 9:38 PM, Martin Thomson wrote:
> > On 11 July 2013 12:04, Cullen Jennings (fluffy) <[e-mail]>
> > wrote:
> >> On Jul 11, 2013, at 10:35 AM, Emil Ivov <[e-mail]>
> >>> In you last mail on the subject you mentioned that we will be
> >>> discussing No Plan in Berlin together with plans A and B. Could
> >>> we please add this to the agenda?
> >>
> >> No. We believe that conversation needs to happen in the W3C WebRTC
> >> WG. I expect to see a message from W3C chairs on this at some
> >> point.
> >
> > I'm a little nervous about this.  Where does the decision on the
> > separation of responsibilities (API vs. SDP) get made?
>
> (I have not been able to confer with any of the other chairs, so this is
> just my personal opinion):
>
> To me it seems pretty straightforward to a certain point:
>
> * The SDP (if we opt to continue using SDP for this purpose) that goes
> on the signaling wire between the browsers is defined by IETF (and by
> the rtcweb WG I presume even though MMUSIC seems to have some stake)
>
> * JS APIs to:
> ** Apply an SDP (e.g. received on the signaling channel) to the browser
> ** Hand an SDP generated by the browser over to the application (for
> transmission over the signaling wire presumably)
> ** Influencing/modifying the contents of the SDP
> * All belongs to the W3C WebRTC
>

Would it make sense to change this list to say the following?

* JS APIs to:
** Apply a SessionDescription (created by SDP; eg received on the signaling
channel or built by JS) to the browser
** Hand a SessionDescription (serializable to SDP) generated by the browser
over to the application (for
transmission over the signaling wire presumably or for immediately applying
with setLocalDescription for some local effect)
** Influencing/modifying the contents of the SessionDescription (and thus,
SDP, when serialized to SDP)
* All belongs to the W3C WebRTC


My changes highlight a few things:
1.  The API (setLocalDescripiton, setRemoteDescription, creatOffer, etc)
doesn't work with SDP directly.  It works with RTCSessionDescription
objects.  It just happens to be that currently the only way to interact
with RTCSessionDescription objects is through SDP.  I think it's worth
remembering that distinction.

2.  SDP does not necessarily go over the wire.   It only necessarily goes
through the API between JS and browser.   I think it's worth remembering
that distinction.

3.  Calling setLocalDescription with a new SessionDescription object can
have purely local effects that don't need to be sent over the wire.  I
think it's worth remembering those cases.



>
> What seems unclear to me is where we define what modifications to the
> SDP that are allowed - and when. Even though the ambition is to have
> APIs that makes SDP mangling an exception, we will still see that
> happening.
>

I think advanced JS apps are going to use every control knob they can get
to, whether it's anticipated and well-supported or not.    I think there's
a good chance that a a popular WebRTC web app will use some SDP mangling
that wasn't anticipated, but happened to work, but then the browser can't
remove it because it will break certain websites.  It could get even worse
if someone writes a popular WebRTC wrapper library that uses tricky SDP
mangling that is then used by lots of websites.  Certain SDP mangling
techniques might end up becoming a defacto standard API that can't be
removed, even if it was originally a bug.  Or worse, one browser will have
to implement the SDP mangling or even the bugs of another, because WebRTC
apps have come to rely on them.

In fact, it's already the case that Chrome and Firefox support far
different SDP manglings.  I don't think any web apps rely on that yet, but
it's only a matter of time before someone figures out "hey, if I mangle the
SDP on this browser this way and on that browser that way, I can do things
I couldn't do otherwise".  Or worse, an advanced web app developer says
"hey, I can make this work well on browser X via SDP mangling, but not on
browser Y, so I'll put a 'best used with Browser X' icon on my website".
Then that someone writes an abstraction on top of that, and then maybe
shares that with others, and it goes from there.

I think we're in a race with web developers to see if they'll figure out
SDP mangling before we provide a way to avoid SDP mangling.   Who do you
think moves faster?










>
> > _______________________________________________ rtcweb mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>