Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

[Jim McEachern <[e-mail]>]

Comment inline

Jim

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Randell Jesup
> Sent: Monday, September 19, 2011 9:54 AM
> To: [e-mail]
> Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
> defining a signaling protocol for WebRTC (or not)]
> 
> On 9/19/2011 6:23 AM, Hadriel Kaplan wrote:
> > On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote:
> >
> >> The point was made repeatedly when I explained this primary area of
> contention that we want it to be easy to use by the "little guys", and that
> even if signalling was a downloaded JS library, you'd end up with a wild
> mixture of old versions in use, which may complicate interop/federation
> (plus the overhead to pull them down, and some possible security issues).
> >
> > And you think having it in the Browsers won't end up with a wild mixture of
> old versions in use, and complicated interop/federation?
> 
> Not compared to the complexity if it's all "roll-your-own".  No one suggested
> that people be locked into a signalling protocol, and JS libraries are an option.
> We do have a lot of experience with pseudo-standard APIs implemented in
> JS, such as jquery and many others, and these aren't unrealistic concerns.
> 
> I lean towards a proposal I made a week or two ago; to allow full access
> (which allows user-written JS signalling libraries) but provide minimal
> SIP+O/A as an option within the browser.  This could be a JS library, but the
> primary users of this would be the "little guys" who just want simple setup of
> media streams, and they're most likely to never update, while browsers are
> updated frequently.

Are you suggesting that the "minimal SIP+O/A as an option within the browser" be baked into the browser, or simply provided as a standard JS library that would be made available to those who wanted to use it.  It sounds like you are suggesting the later, but I want to be certain, since it could make a big difference.

> 
> > And on top of it you'll end up with a wild mixture of signaling vendors,
> because there'll be a mixture of Browser vendors and it's unlikely they'll all
> use the same source code inside.  What's worse, it won't be controllable by
> the JS developer.  At least with a JS library they're all using the same source
> code, and the JS developer knows what it was/did if it was an older version.
> 
> That's entirely available to the application; they can use their own if they
> wish.
> And while I suggest a simple SIP set be included, if we were certain a
> "standard" JS lib were freely available and solid enough, that would make the
> argument stronger for a JS lib.
> 
> > With regard to the issue of overhead of pulling it down every time, I
> thought browsers cache JS scripts, no?
> 
> Yes, and as of Firefox 3 if a script is served with Cache-Control: public, it will
> be cached to disk even if coming from https.  Note that secure (https)
> content by default isn't cached unless cache-control options are set.
> 
> I would strongly warn against fetching JS libs for a service like this over http,
> and as part of the security review here we may well go further than that.
> 
> 
> --
> Randell Jesup
> [e-mail]
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb