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

Harald Alvestrand <harald@alvestrand.no> Wed, 19 October 2011 05:18 UTC

Return-Path: <harald@alvestrand.no>
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 75A5611E8080 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 22:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.486
X-Spam-Level:
X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 S8uqpuYNhyBv for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 22:18:09 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 417B811E8073 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 22:18:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2D9039E0F0; Wed, 19 Oct 2011 07:18:08 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju5VmWIG15Mx; Wed, 19 Oct 2011 07:18:06 +0200 (CEST)
Received: from [172.16.48.71] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6A62839E0D2; Wed, 19 Oct 2011 07:18:06 +0200 (CEST)
Message-ID: <4E9E5D8D.6030707@alvestrand.no>
Date: Wed, 19 Oct 2011 07:18:05 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com>
Content-Type: multipart/alternative; boundary="------------000606040904020609030809"
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 05:18:11 -0000

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
>