Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

[Ted Hardie <[e-mail]>]

On Sat, Oct 15, 2011 at 1:43 AM, Iñaki Baz Castillo <[e-mail]> wrote:

>
> > Do you think you could support SIP identity with a javascript client?
>
>
> Yes. The spec (RFC 4474) does NOT mandate that the SIP client MUST to
> have a list of CA's and verify the retrieved certificate by itself. A
> JavaScript client receiving an incoming INVITE with Identity and
> Identity-Info header could make a webservice call (i.e. using AJAX)
> and ask its web server to retrieve it and verify it in behalf of the
> client. And still that is SIP.
>
> So yes, I could support SIP Indentity with a JavaScript client.
>
>
I would say you did not do it within the JavaScript client, but built a
JavaScript client that simply trusted the results of the webserver.  This is
significantly worse than even the SSH-style limited identity we've discussed
before, because the Javascript client doesn't even check whether the
identity matches previous uses of that identity.  You also don't describe
how you go about assuring the path over which the media flows, which is a
part of sip identity.



>
> >
> > Well, given that you don't believe in the need for a protocol here at
> all,
>
> A protocol is needed, of course. But not a *specific* protocol.
>
>
> > but only an incredibly flexible API, it seems a bit unclear why you're
> not
> > making these points on the W3C public mailing list for this activity.
>
>
By "a protocol here", I meant "standardized in the IETF" sorry that was not
clear.


> I expect such work must come once the requirements for such API are
> done in this WG.
>
>
The work is ongoing now in both groups and the two are meant to coordinate.
Presuming that all the work will go on there to provide a model-agnostic API
is not effective coordination, at least in my view.


>
> > A truly well structured API here will imply, at least in my view, at
> least a
> > common model for negotiation and a common set of structured data to be
> > passed via this javascript-implemented protocol.  Doing that without
> > defining a standard protocol is actually harder than doing it while
> defining
> > a protocol.
> >
> > I've heard the various arguments against defining one, but none of them
> > seems to stand up against the base fact that you can have a standard
> > protocol--known to be available--without restricting the ability to
> create
> > proprietary protocols using the same API.
>
> There have been lot of arguments contrary to defining a "default
> signaling protocol". I don't want to repeat them again, but neither
> answer as if they don't exist.
>
>
There have been a lot of arguments, but speaking personally, they seem to
boil down to a preference for inferring a model (offer/answer) along with a
slow realization that much of the negotiation here (e.g. codec parameters)
cannot really be punted.  As I said before, if you go down the route of
creating a common model for negotiation and a common set of structured data
for the negotiation and security assurances, you have done the semantic work
of creating a protocol.  Failing to choose a common in syntax in that
situation is, in my experience, both odd and likely to decrease the amount
of deployment and increase the failure rate.

My personal opinion,

Ted Hardie