Re: [rtcweb] DataChannels API and external negotiation
Peter Thatcher <pthatcher@google.com> Wed, 03 April 2013 16:06 UTC
Return-Path: <pthatcher@google.com>
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 8807121F8C9A for <rtcweb@ietfa.amsl.com>; Wed, 3 Apr 2013 09:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pwpyINEAm79x for <rtcweb@ietfa.amsl.com>; Wed, 3 Apr 2013 09:06:27 -0700 (PDT)
Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id EABCD21F8C08 for <rtcweb@ietf.org>; Wed, 3 Apr 2013 09:06:26 -0700 (PDT)
Received: by mail-pd0-f181.google.com with SMTP id y10so929006pdj.12 for <rtcweb@ietf.org>; Wed, 03 Apr 2013 09:06:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=DZDyF11f58Xt+0s3yWrHqyWsedizVtrasjJaT7R7Y6k=; b=fueNLc7OQhLg7z8ijwcIIowOVEDICnOIGibNpGqhbduTJHHPfFJACLhOUT7fgIBy9A FysAfIKaqSJwoUrnq5WU9YQ87MXkp3E6GnyCB0i0VspC4oO1vKfQVfPR64N/5ilE2J4T 6HfLmIJf0ab0Ij/0vJ0r172rvdKHUpq0y9vGvN/LqK/XPFEgIihrRsyt1SiYXVn8TYj6 Vm+G5VCPzJy7SrZSFSKb4FzyECnLidX3rNkYrupMTUPl8MzQUnEJ19icqkJ0j+z/qaEM M2bXGY4/reRXanYxM33nhJ+cAHJBxaixLj1lX6W8zycre392FFIPuOVC5wTUeb1/QyaD FD9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=DZDyF11f58Xt+0s3yWrHqyWsedizVtrasjJaT7R7Y6k=; b=ArvNjVaqfmDJ4E/lh/5JchHXX4Jn8R1MiVWuYnPx0IcV7biCUzVVVg3xZywXyuQTcW MGVNHqRUEqXp3RJmwWR85o6B6dM7X/xFWi1tsqc8c+UjXVMS0Ubiy1qeFOSfksRqFJZp 3qRfbzw4kh2Ms0j8Z2SPmcfSc/58HpM7yX+Gz4V/4wW3/2hFILgtsoZjLgoPOebRrAPv 9rCUtlJmOjEQTxi5ZHR10RXvgmLlXhfBc2ym4UGIIHnzYNXAbQ++BDh0USJlyBH0FvYO P7n2pENA2iiRu+jCbMXM8MZdjHH2YZqsWxX/WblanGLgDgva8hGmd9gxDHa8D0K/ZJTU RxVA==
X-Received: by 10.66.138.101 with SMTP id qp5mr4031703pab.127.1365005186621; Wed, 03 Apr 2013 09:06:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.248.196 with HTTP; Wed, 3 Apr 2013 09:05:46 -0700 (PDT)
In-Reply-To: <CABkgnnWe-+80WxD8==CxDhAu5+MEa-Tqi7Pr1x8sgkUkE9Z09Q@mail.gmail.com>
References: <5158F0FC.3070104@jesup.org> <CABkgnnWBR5SqOF6Ygp7AaEyG19yoG88hpUs4_mWbv59dyCm1gA@mail.gmail.com> <5159E6F9.4070808@jesup.org> <CABkgnnWe-+80WxD8==CxDhAu5+MEa-Tqi7Pr1x8sgkUkE9Z09Q@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 03 Apr 2013 09:05:46 -0700
Message-ID: <CAJrXDUGm-LuddkaUgMUp-p8-Bj-B-zBcqomHcDy+jm6WJtT9wQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Gm-Message-State: ALoCoQnBrfSR3oKJDjhZ58plkS/A/cAfVm5CNnjXTLNhSl2/7az6eWXPCU0o7WzmKpagIhvTgqPCpBhOsg28ddo6iTwodRGXnZxoibClDFeqGZKLAouFDla80TFpuO9caf4LJZ5ezpTCWyEDKN5owSZBbrkP5bnn+dEYYdU69Yy+Maz/eJN2qSJiIbPc7mYtAXeNJGzJm/4j
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] DataChannels API and external negotiation
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, 03 Apr 2013 16:06:27 -0000
I think moving protocol into the dictionary is a good idea. In fact, I'd like to see label move there as well, but that's probably asking too much. And now for a little of my own bikeshedding: I don't understand way we have "stream" and "preset", since you can only set "stream" if "preset" is true. Why not just make the rule "if stream is set, no in-band message is sent", and get rid of "preset" altogether? I really don't like the word "stream" sneaking in, since it's so overloaded (MediaStream, RTP Stream, etc). I'd prefer "sid" or just "id". I like the idea that reliable+ordered is the default, and both reliability and ordered can be set independently. I also prefer "ordered" over "outOfOrderAllowed", and along with that I like the idea of a "reliable" flag that, if false, is the equivalent of either maxRetransmitNum:0 or maxRetransmitTime:0. Finally, I think "maxRetransmitTime" should make its units clear, perhaps calling it "maxRetransmitMillis", and "maxRetransmitNum" could be shortened to simply "maxRetransmits". So the dictionary for my bikeshed would be: dictionary DataChannelInit { DOMString protocol; unsigned short id; boolean ordered; boolean reliable; unsigned short maxRetransmits; unsigned short maxRetransmitMillis; }; On Mon, Apr 1, 2013 at 1:24 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 1 April 2013 12:58, Randell Jesup <randell-ietf@jesup.org> 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. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] DataChannels API and external negotiation Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Michael Tuexen
- Re: [rtcweb] DataChannels API and external negoti… piranna@gmail.com
- Re: [rtcweb] DataChannels API and external negoti… piranna@gmail.com
- Re: [rtcweb] DataChannels API and external negoti… Martin Thomson
- Re: [rtcweb] DataChannels API and external negoti… Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Martin Thomson
- Re: [rtcweb] DataChannels API and external negoti… Peter Thatcher
- Re: [rtcweb] DataChannels API and external negoti… Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Michael Tuexen
- Re: [rtcweb] DataChannels API and external negoti… piranna@gmail.com
- Re: [rtcweb] DataChannels API and external negoti… Peter Thatcher
- Re: [rtcweb] DataChannels API and external negoti… MARCON, JEROME (JEROME)
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Adrian Georgescu
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Jordan
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Martin Thomson
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Gustavo Garcia Bernardo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Gustavo García
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Martin Thomson
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Marc Abrams
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Alexandre GOUAILLARD