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

José Luis Millán <jmillan@aliax.net> Wed, 19 October 2011 06:22 UTC

Return-Path: <jmillan@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB081F0C4E for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 23:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Level:
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpVDYE3J5gAb for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 23:22:38 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7E831F0C49 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 23:22:38 -0700 (PDT)
Received: by iabn5 with SMTP id n5so1872315iab.31 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 23:22:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.67.80 with SMTP id q16mr2231179ibi.86.1319005358358; Tue, 18 Oct 2011 23:22:38 -0700 (PDT)
Received: by 10.231.16.75 with HTTP; Tue, 18 Oct 2011 23:22:38 -0700 (PDT)
In-Reply-To: <4E9E5D8D.6030707@alvestrand.no>
References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com> <4E9E5D8D.6030707@alvestrand.no>
Date: Wed, 19 Oct 2011 08:22:38 +0200
Message-ID: <CABw3bnP0wkYWFsBCENkAkuZk73-KyvWxB7HHynbB_Mzh71Lx2A@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= <jmillan@aliax.net>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: base64
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2011 06:22:39 -0000

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 <harald@alvestrand.no>;:
> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>