Re: [rtcweb] Review request for RTCWeb standard signaling protocol

["Ravindran Parthasarathi" <[e-mail]>]

Hadriel,

<snip> Neil makes an excellent point which has only been briefly brought
up but
>should be made more explicit: picking a standard signaling protocol for
>the Browser to implement is only half the problem - the other half of
>the problem is the Web Server has to implement it too, tie it into a
>location database, possibly with authentication and authorization
policy
>rules, and whatever else the specific Web application needs. </snip>

My way of looking at the problem is between RTCWeb client (browser +
javascript) and RTCWeb server signaling. I think that we are in the
agreement that server has to perform couple of functionality like
authentication and authorization policy which is normally dealt in all
signaling protocol. My point is that it is better to spell out RTCWeb
standard protocol between RTCWeb client and RTCWeb server by which
RTCWeb server vendors shall interop smoothly with RTCWeb client. I
missed to spell out in my draft about RTCWeb server dependency but
pointed out the issues in gateway development of RTCWeb server & legacy
server and it may be because I'm more concern about gateways ;-) I'll
clarify in the next revision.

Also, I'm not against creative RTCweb developer to innovate new
signaling protocol for their website. But IETF MUST not mandate every
web developer to create the signaling protocol to make RTCWeb solution
work. 

Thanks
Partha

>-----Original Message-----
>From: Hadriel Kaplan [mailto:[e-mail]]
>Sent: Saturday, October 08, 2011 12:20 AM
>To: <[e-mail]>
>Cc: Ravindran Parthasarathi; Neil Stratford
>Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
>protocol
>
>
>Neil makes an excellent point which has only been briefly brought up
but
>should be made more explicit: picking a standard signaling protocol for
>the Browser to implement is only half the problem - the other half of
>the problem is the Web Server has to implement it too, tie it into a
>location database, possibly with authentication and authorization
policy
>rules, and whatever else the specific Web application needs.
>
>There is no "20 lines of code" solution once you realize that.  It may
>be 20 lines of JavaScript, but that's only part of the
problem/solution.
>In fact, the most likely way to get to 20 lines of code for the Web
>Server owner is for him/her to use a public JS library for signaling
>which is paired with a web server module written for that specific JS
>library.
>
>-hadriel
>
>
>On Oct 7, 2011, at 7:16 AM, Neil Stratford wrote:
>
>>
>> If we did go down the hypothetical new standard protocol route (which
>I really think we shouldn't) my requirements would be:
>> - No server side infrastructure (SIP proxies etc) to maintain or
>configure.
>> - No special understanding in the server side web application beyond
>discovering peer identities you might want to communicate with.
>>
>> Which would lead to something looking like a browser maintained peer
>to peer network, at which point we are re-inventing the web, which
>sounds like something beyond this group. So I strongly support not
>picking a default and instead encourage some innovation at the
>javascript level.
>>
>> Neil
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb