Re: [rtcweb] DataChannels API and external negotiation

Martin Thomson <> Mon, 01 April 2013 20:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DE3621E80AA for <>; Mon, 1 Apr 2013 13:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pvc8elc2rEzl for <>; Mon, 1 Apr 2013 13:24:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22a]) by (Postfix) with ESMTP id 1A6DC21E80B2 for <>; Mon, 1 Apr 2013 13:24:52 -0700 (PDT)
Received: by with SMTP id k13so2476571wgh.3 for <>; Mon, 01 Apr 2013 13:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=P/L2Mlnb/ad0ipnECDzuzp/Fke7MJXVWi7gfgA6t1qY=; b=u82XysjkLUcY0b9/ezS8xluQXfOr+v6AOPFReKUDIGQ0IuPCDZsCxdXfNSrskD6LON p7W5gcdE5DETy8YPZsoM+3MAHp4RCV3Vuv1Codxy7lmwCLBdxRlAfDh5vOSH3xMFw2dg u085EGyxuPs1Nuo6yJGOCbStjVdE/9W67TbBLtapMpvBYTgARgXtstBjPYK6Ttpo4/3k URGo7ErnA+lxoYcOLfWTpgRMtDKW+wXnrDktaOp9SWFMMsxDx90SDz6BRNlUTfTFEk9F HKw2+n/tuY0jBXw9Ma8ACu31yM5n6BkFgpLvgLyxhoXmNFBiUUL4RSW7D7rHTmuuu/6I 6JRg==
MIME-Version: 1.0
X-Received: by with SMTP id cp7mr17458622wjb.19.1364847887821; Mon, 01 Apr 2013 13:24:47 -0700 (PDT)
Received: by with HTTP; Mon, 1 Apr 2013 13:24:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 1 Apr 2013 13:24:47 -0700
Message-ID: <>
From: Martin Thomson <>
To: Randell Jesup <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>, "" <>
Subject: Re: [rtcweb] DataChannels API and external negotiation
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Apr 2013 20:25:02 -0000

On 1 April 2013 12:58, Randell Jesup <> wrote:
> I don't know that removing 'max' helps here or hurts.  Also, sorta-acronyms
> like rtx are obvious to networking people; not so much to JS app developers.
> I see only minimal advantage here to brevity.  Count might be an improvement
> on Num.

Yeah, 'rtx' is probably too aggressively short.

>> 'preset' doesn't sound right, maybe you could have 'inlineOpen'
>> (default: true) to convey what is really happening here.
> externallyNegotiated (default: false)?  Not great, but "inlineOpen" will be
> pretty meaningless to most developers who probably could care less if
> there's an in-band open message for a channel (whether externally negotiated
> or not) - or even know there's an in-band message.  Then again, 99% of
> developers don't need to care about this anyways.

Yes, I didn't get a warm fuzzy from my suggested name either, but you
are right about the impact being relatively low.

Other ideas: "announceSettings" (default: true), "prearranged"
(default: false), "thisIsNotATest" (default: "yesItIs").

> Unsigned short has been the type in the protocol fields since the first
> draft (like a year).  Perhaps a silly optimization, though I think if you
> want partial reliability with >64K resends, or >64 seconds of retry that you
> *really* want reliable transmission (perhaps unordered, but reliable).   If
> we want to change it, now's the time, since we're breaking binary
> compatibility in FF with my landing today anyways.

Well, you'll be accepting a JS number, so it doesn't really matter
what the spec says.