Re: [rtcweb] Open data channel issues

Randell Jesup <randell-ietf@jesup.org> Tue, 04 March 2014 09:02 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A9A1A0427 for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 01:02:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3_KG92X0hmo for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 01:02:09 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 037BF1A0429 for <rtcweb@ietf.org>; Tue, 4 Mar 2014 01:02:08 -0800 (PST)
Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:4679 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <randell-ietf@jesup.org>) id 1WKlEj-0003dj-7J for rtcweb@ietf.org; Tue, 04 Mar 2014 03:02:05 -0600
Message-ID: <53159637.8050909@jesup.org>
Date: Tue, 04 Mar 2014 04:00:39 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <CAOJ7v-2GHt37u8raWDKquNFLCjSv-ptP0YGojPwuLv02da_m1Q@mail.gmail.com> <5313EC0D.9030808@jesup.org> <CAOJ7v-3L5_V2wuwVLKpz61VHey7yx3LnG_xrPLb5W+6DOLiEJw@mail.gmail.com> <53146B2C.8080008@jesup.org> <CABkgnnV1BdAMvFqGq8xiL0Zu28aZBCAdPwZB8whpMeXrCD7AHQ@mail.gmail.com> <53149F0C.6070001@jesup.org> <CAOJ7v-0xSq2xvF_5Do-R4SG6yAVNdqELwRvt_VBU69ir6nHhGQ@mail.gmail.com> <53154AA8.4000202@jesup.org> <CABkgnnVWESeVgrPjYnxuhB5w1QTjbXNW+zBLfYRwUL059Q0_hw@mail.gmail.com> <53158103.4000809@jesup.org> <1D3890D9-AF14-4648-820D-7586134D56DA@lurchi.franken.de>
In-Reply-To: <1D3890D9-AF14-4648-820D-7586134D56DA@lurchi.franken.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZqGsJmiAqFvhYqynVQVsrIBne3g
Subject: Re: [rtcweb] Open data channel issues
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 04 Mar 2014 09:02:10 -0000

On 3/4/2014 2:55 AM, Michael Tuexen wrote:
> On 04 Mar 2014, at 07:30, Randell Jesup <randell-ietf@jesup.org> wrote:
>
>> On 3/4/2014 2:00 AM, Martin Thomson wrote:
>>> On 4 March 2014 03:38, Randell Jesup <randell-ietf@jesup.org> wrote:
>>>> To take your suggestion:
>>>> a) applications assume 16KB if ndata wasn't negotiated (per the current
>>>> suggestion)
>>>> b) implement ndata and EOR support in the browsers, and drop the 16KB limit
>>>> when ndata is negotiated.
>>>> All this needs is "is ndata supported by this association" exposed to the
>>>> app; no sdp changes needed.  (One less dependency!)
>>> Or, to avoid vestigal crap in the API in the end state, when you
>>> install the 16K limitation, add an indicator that applications can
>>> check.  Once you remove the cap, remove the indicator.
>>>
>>> if (dataChannel.isNotVeryGood) {
>>>    chunkMessage(message);
>>> } else {
>>>    dataChannel.send(message);
>>> }


Wait, the reason why we had it be 16K as a default was that current 
impls don't have the property.  So datachannel.isntFixed (ok, better 
names can be found - but that's W3 anyways.


-- 
Randell Jesup -- rjesup a t mozilla d o t com