Re: [rtcweb] Open data channel issues

Martin Thomson <martin.thomson@gmail.com> Tue, 04 March 2014 07:00 UTC

Return-Path: <martin.thomson@gmail.com>
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 A3A5C1A01AE for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 23:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 DUst73QQgnQA for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 23:00:26 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C4F661A03B5 for <rtcweb@ietf.org>; Mon, 3 Mar 2014 23:00:21 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id t61so1905459wes.16 for <rtcweb@ietf.org>; Mon, 03 Mar 2014 23:00:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tLotNifnH/y8FxMTXDjhEz0TX15shUVep9mA/6sh4vE=; b=G5fXlFyBsA0wEJCbQO2Wma3DCrmQkFd6oNJNP3e1oJ59vqHFssrvkaojXMn0fquvX3 NVkkiVrcSbPo0g3Pf48NWtFRVPiG4O7WSJSqfrRh5j0oXK8iuovu38o7gz58RU3NjgWA JeiOfPE8QWrOLHhZzZfZ6hmd8mu7Yh8pQZ+sLDLjEdorYcteslkLitkgoMWs7s9pAXZE bqHdpiqbglWg8mS42bK2N8ISi/oE2CmxIJcC3sm7axufZJFP7JVzUGUSYpYefJsoYw4J qL8j+i7q8yJyqnyx6juadYS2COhWzwRbHaaRNezWR9VEXzpEI3c9Z3UgHYMd4f4txrC3 LBDw==
MIME-Version: 1.0
X-Received: by 10.194.2.194 with SMTP id 2mr12924874wjw.73.1393916418219; Mon, 03 Mar 2014 23:00:18 -0800 (PST)
Received: by 10.227.10.196 with HTTP; Mon, 3 Mar 2014 23:00:18 -0800 (PST)
In-Reply-To: <53154AA8.4000202@jesup.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>
Date: Tue, 4 Mar 2014 07:00:18 +0000
Message-ID: <CABkgnnVWESeVgrPjYnxuhB5w1QTjbXNW+zBLfYRwUL059Q0_hw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kYJmPXbaWUREbR6ocPZ-d4-l3XU
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 07:00:28 -0000

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);
}