Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing

[Harald Alvestrand <[e-mail]>]

On 10/18/11 19:54, Wolfgang Beck wrote:
> On Tue, Oct 18, 2011 at 1:43 PM, Harald Alvestrand<[e-mail]>  wrote:
>
>
>> The context of RTCWEB is the well known trapezoid:
>>
>> +-----------+ +-----------+
>> | Web | | Web |
>> | | Signalling | |
>> | |-------------| |
>> | Server | path | Server |
>> | | | |
>> +-----------+ +-----------+
>> / \
>> / \ Proprietary over
>> / \ HTTP/Websockets
>> / \
>> / Proprietary over \
>> / HTTP/Websockets \
>> / \
>> +-----------+ +-----------+
>> |JS/HTML/CSS| |JS/HTML/CSS|
>> +-----------+ +-----------+
>> +-----------+ +-----------+
>> | | | |
>> | | | |
>> | Browser | ------------------------- | Browser |
>> | | Media path | |
>> | | | |
>> +-----------+ +-----------+
>>
>> or even the triangle, where the triangle is formed when the two Web severs
>> on top are collapsed into one.
> I'll nag you again about my draft where there is only one single web
> server and one JS client that runs on both browsers.
> If you can make sure that all parties in a call use the same RTCWEB
> server and -client, you don't need to standardize a protocol.
I disagree with both of your assertions.

1) we have to support both the case of one web server and the case of 2 
web servers.

2) when there is only one web server, one of the browsers is Firefox and 
the other one is Chrome, the JS needs to have a standard means of 
communication with the browser. This means a standard.
I have explained in my long note why I think it makes sense to describe 
this as a protocol.
> We startet RCTWEB to overcome the slow innovation pace associated with
> protocol standardization.
> If RTCWEB relies on a standardized protocol for its key functionality,
> we have gained very little.
>
>> Another design criterion is that interworking should be possible
> I'm not convinced that we need this, at least not at the signaling
> level of RTCWEB clients and servers.
I agree that we disagree.
>
> Wolfgang Beck
>