Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt

Harald Alvestrand <harald@alvestrand.no> Mon, 14 November 2011 15:30 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 0522311E80CF for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 07:30:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.549
X-Spam-Level:
X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 aBUfbIMEnPxN for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 07:29:59 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E571111E81A0 for <rtcweb@ietf.org>; Mon, 14 Nov 2011 07:29:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DC6E639E0E7; Mon, 14 Nov 2011 16:29:57 +0100 (CET)
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 RfAYy20BksG6; Mon, 14 Nov 2011 16:29:56 +0100 (CET)
Received: from [192.168.0.101] (dhcp-4268.meeting.ietf.org [130.129.66.104]) by eikenes.alvestrand.no (Postfix) with ESMTPS id F2E2B39E074; Mon, 14 Nov 2011 16:29:55 +0100 (CET)
Message-ID: <4EC133F1.8080606@alvestrand.no>
Date: Mon, 14 Nov 2011 23:29:53 +0800
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: Wolfgang Beck <wolfgang.beck01@googlemail.com>
References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <CAAJUQMhCHHWqeUSKdn4SAS67ohF1y_QxCbc9KcgeybAe7N-5-w@mail.gmail.com> <CAOJ7v-3-2ZL5fvsXxGiwjAh3TKe__PGdU+Aw0cR-fGqzT6Ht9g@mail.gmail.com> <CAAJUQMiyit3QvYJ3piuX26r4T5KtwLwWHX3NaC1wWL-zzeRftA@mail.gmail.com>
In-Reply-To: <CAAJUQMiyit3QvYJ3piuX26r4T5KtwLwWHX3NaC1wWL-zzeRftA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt
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: Mon, 14 Nov 2011 15:30:00 -0000

On 11/14/2011 07:20 PM, Wolfgang Beck wrote:
> On Mon, Nov 14, 2011 at 6:42 PM, Justin Uberti<juberti@google.com>  wrote:
>> On Mon, Nov 14, 2011 at 4:35 AM, Wolfgang Beck
>> <wolfgang.beck01@googlemail.com>  wrote:
>>> If not, how is the content of the data stream -- the 'codec'
>>> -- negotiated between the different JS clients? ROAP will not work as
>>> it is the JS clients which writes to the data stream. The ROAP
>>> component of the browser doesn't know what's in there.
>> The format of the data stream will be standardized.
> Now it gets interesting: who is responsible for the rtcweb-data content?
>
> if it is the browser:
> - every new application will have to be standardized.
> - for every new application, the browser has to be updated.
> ***whether we do server-to-server or not***
>
> It basically means every rtcweb-data application needs to get the
> approval of Firefox, Google, and Microsoft.
>
> If it is the JS client:
> - the JS client has to handle Offer/Answer. The browser doesn't know
> enough about the content to do this.
I believe the discussion above bears very little relationship to what 
has been proposed.
As I read the proposal:

- Data channel does not touch the servers.
- Of course two JS apps can only have sensible communication if they 
agree on the data format. Being the same application is one way to 
agree; it's not the only one.
- The data format (content of data) is not negotiated in offer/answer. 
Just the fact that there is a data channel is negotiated.
- Standardizing a data format may be useful. But it is not required. 
Bilateral agreements work too.