Re: [rtcweb] Data Channel Negotiation and reopening of decisions

Harald Alvestrand <harald@alvestrand.no> Mon, 18 February 2013 12:39 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 D0C5C21F8810 for <rtcweb@ietfa.amsl.com>; Mon, 18 Feb 2013 04:39:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.369
X-Spam-Level:
X-Spam-Status: No, score=-110.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VbpCqbBpvam for <rtcweb@ietfa.amsl.com>; Mon, 18 Feb 2013 04:39:25 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8D48F21F8806 for <rtcweb@ietf.org>; Mon, 18 Feb 2013 04:39:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 43F2539E0F3 for <rtcweb@ietf.org>; Mon, 18 Feb 2013 13:39:24 +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 q6v0c+1GqM93 for <rtcweb@ietf.org>; Mon, 18 Feb 2013 13:39:23 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5B88539E0E1 for <rtcweb@ietf.org>; Mon, 18 Feb 2013 13:39:23 +0100 (CET)
Message-ID: <512220FA.6050608@alvestrand.no>
Date: Mon, 18 Feb 2013 13:39:22 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABkgnnWUpMSBLioSD2+p82vGszX9R0Q4WFfME5j-DuK+B7KVJw@mail.gmail.com> <5113CD16.6090806@jesup.org> <CABkgnnW792o76t9dKhidOMJpa21VcbPQZFU1HYnY_yjTPCWhYw@mail.gmail.com> <51166A3C.4000604@jesup.org> <CABkgnnV2m=m+qtM1YR4CPse=gyekvWThon_Nxbf8YMVaNuvq6Q@mail.gmail.com> <511B6C9A.4090904@jesup.org> <CABkgnnUiCKuv_=mgLFf4sRnOb1bY190N7E_+V8gfTbKEUTBnDw@mail.gmail.com> <511CB20C.7020003@jesup.org> <CABkgnnU0idt+ntpKjTCMUCVFO9=_fSjGRPikD6Nk_Uem3L7E8g@mail.gmail.com> <89FAFB5C-9D03-4B76-A306-01F9E4EC4105@lurchi.franken.de> <CABkgnnXFrqTo2QpLhjWt5CmcQc6Kv4=vAgd3DgyndNtL1ewm7g@mail.gmail.com> <8E2722E7-F82A-48D4-80FB-C76929A2E324@lurchi.franken.de> <CABkgnnWzX2tpbadnB3DjhmB7cm6poCDvmxdAW2Z_stMbovJ3gw@mail.gmail.com> <A0FDFC7C-2C85-431C-A03E-0E486F9378D1@lurchi.franken.de>, <CABkgnnWdjV7F9jkbap91q-pLygzWJsTvAOh-m=-9q4VrU9DGUg@mail.gmail.com> <DA07C056-3E80-4E30-B078-5547A174549D@skype.net>
In-Reply-To: <DA07C056-3E80-4E30-B078-5547A174549D@skype.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Data Channel Negotiation and reopening of decisions
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, 18 Feb 2013 12:39:27 -0000

On 02/15/2013 10:56 PM, Matthew Kaufman (SKYPE) wrote:
> None if this would be a problem if we weren't making the mistake of using SCTP, which itself made the mistake of doing full-duplex channels instead of unidirectional channels with optional one-to-one or even many-to-one associations (as RTMFP has, as an example)

Correction: SCTP has unidirectional channels. This WG made the decision 
that it wanted something that looked like WebSockets, which are 
bidirectional. This required something to be layered on top of SCTP; 
that's what we're currently discussing.