Harald,

Please read = inline.

Thanks

Partha

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Wednesday, October 19, 2011 10:48 AM
To: Ravindran Parthasarathi
Cc: rtcweb@ietf.org
Subject: Re: Comment on draft-ietf-rtcweb-overview-02 (Browser = RTC trapezoid)

On 10/19/2011 01:12 AM, Ravindran Parthasarathi = wrote:

Harald,

In Fig 2 (Browser RTC Trapezoid), I’m getting = the feel that JS/HTML communicates with webserver directly without the = involvement of browser. Please clarify whether it is intended not to use browser = for JS.

Sorry, you completely lost me there.

The browser is the execution context for Javascript. The words "it = is intended not to use browser for JS" look like English to me, but I = can't find any interpretation that makes any sense.

<partha> Sorry, = I messed up with the words here but you clarified it in the below mail thread </partha>

If you don't have a clear view of the Javascript execution model, I = recommend spending a few hours with an introductory Javascript text and playing = with writing some Javascript in your own web pages. It will save lots of = confused emails to the list.

<partha> In = fact I tried couple of W3Cschools Javascript before starting the mail thread in RTCWeb. = I’ll learn more terminology in Javascript to clearly present my ideas = </partha>

IMO, the browser RTC trapezoid shall be =

&= nbsp; +-----------+ &= nbsp; +-----------+

&= nbsp; | RTCWeb | Federation | RTCWeb = |

&= nbsp; | | Signaling = | = |

&= nbsp; | |-------------| &nbs= p; |

&= nbsp; | Server | protocol | Server |

&= nbsp; | | = | = |

&= nbsp; +-----------+ = +-----------+

&= nbsp; &n= bsp; / = &= nbsp; \

&= nbsp; / = &= nbsp; \ RTCWeb

&= nbsp; / = &= nbsp; \ Signaling

&= nbsp; / = &= nbsp; \

&= nbsp; / = RTCWeb &= nbsp; &n= bsp; \

&= nbsp; / Signaling &nbs= p; = ; \

&= nbsp; / = &= nbsp; &n= bsp; \

&= nbsp; +-----------+ = &= nbsp; +-----------+

&= nbsp; | | = &= nbsp; | = |

&= nbsp; | Browser | ------------------------- | Browser = |

&= nbsp; | | Media path = | |

&= nbsp; | | = &= nbsp; | = |

&= nbsp; +-----------+ = &= nbsp; +-----------+

+-----------+ = &= nbsp; +-----------+

&= nbsp; |JS/HTML/CSS| = &= nbsp; |JS/HTML/CSS|

&= nbsp; +-----------+ = &= nbsp; +-----------+

Absolutely not.

1) The term "RTCWeb Signaling" has no clear definition, as = this discussion has proved again.

<partha> May I = need to put clear definition by which we will come to common understanding. = </partha>

2) The conceptual difference between the media path (managed by the = browser without being mediated through Javascript) and the signalling path = (mediated through Javascript, transmitted through interfaces that this WG has no intention of changing) is lost by the inversion of the "browser stack".

<partha> Agreed = and my intention is not manage media path through Javascript. My figure has to change = JS/HTML position to reflect it correctly. </partha>

The detailed relationships between the browser components are better = described in Figure 1 of -overview- than in Figure 2 (the one you've quoted). I've = noted the need to mention that the JS uses browser functions to access HTTP = and WebSockets too, since it's apparently not completely obvious to = all.

<partha> My = intention of the mail is above statement and it is not clear from the figure 1 & = 2. </partha>

I = explained the same diagram in Fig 1 of draft-partha-rtcweb-signaling-00. RTCWeb = signaling shall be proprietary HTTP/websocket. I’m asking this change = because I’m seeing folks confuses API vs. on-wire-protocol. Also, Please = note that JS + browser is the single system with two different modules and it = shall have protocol or API to communicate (without passing any information in = the wire). Could you please let me know in case I’m missing = something.

Thanks

Partha