Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid)

[José Luis Millán <[e-mail]>]

Ravindran,

Whichever your motivation for arguing against or in favor, arguments
need to be rigorous and clear. I guess most people reading and
contributing have a deep knowledge about what is being speaking about
here.

After reading this email, it's very dificult for me understanding how
can there be so many mails from you asking for the adoption of
whichever position in this list.

> 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.

This question (of course, questions are always legitimate) comes after
you exposed a document
(http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00) focused
on standarizing a signaling between browser and RTCWeb server.

"In the above mentioned architecture, this document focus on
   standardizing RTCWeb signaling between browser and RTCWeb server"


This is nothing personal, but this attitude makes the mailing list
hard to follow, at least.


I apologize if this comment is out of context.


2011/10/19 Harald Alvestrand <[e-mail]>:
> 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.
>
> 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.
>
>
>
> IMO, the browser RTC trapezoid shall be
>
>
>
>                    +-----------+             +-----------+
>
>                    |   RTCWeb  |  Federation |   RTCWeb  |
>
>                    |           |  Signaling  |           |
>
>                    |           |-------------|           |
>
>                    |  Server   |   protocol  |  Server   |
>
>                    |           |             |           |
>
>                    +-----------+             +-----------+
>
>                         /                           \
>
>                        /                             \   RTCWeb
>
>                       /                               \  Signaling
>
>                      /                                 \
>
>                     /  RTCWeb                           \
>
>                    /   Signaling                         \
>
>                   /                                       \
>
>             +-----------+                           +-----------+
>
>             |           |                           |           |
>
>             |           |                           |           |
>
>             |  Browser  | ------------------------- |  Browser  |
>
>             |           |          Media path       |           |
>
>             |           |                           |           |
>
>             +-----------+                           +-----------+
>
>             +-----------+                           +-----------+
>
>             |JS/HTML/CSS|                           |JS/HTML/CSS|
>
>             +-----------+                           +-----------+
>
> Absolutely not.
>
> 1) The term "RTCWeb Signaling" has no clear definition, as this discussion
> has proved again.
> 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".
>
> 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.
>
>
>
> 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
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>