Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt

Harald Alvestrand <harald@alvestrand.no> Mon, 11 March 2013 19:22 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 A378C11E81EB for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 12:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.688
X-Spam-Level:
X-Spam-Status: No, score=-110.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 xMzMMkAlU+n1 for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 12:22:30 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 086EB11E8120 for <rtcweb@ietf.org>; Mon, 11 Mar 2013 12:22:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C04ED39E1C4 for <rtcweb@ietf.org>; Mon, 11 Mar 2013 20:22:27 +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 oOYmBBHZH4Lm for <rtcweb@ietf.org>; Mon, 11 Mar 2013 20:22:27 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482] (unknown [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8226939E1AD for <rtcweb@ietf.org>; Mon, 11 Mar 2013 20:22:26 +0100 (CET)
Message-ID: <513E2EEE.3050106@alvestrand.no>
Date: Mon, 11 Mar 2013 20:22:22 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <51376643.8090204@jesup.org> <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>
In-Reply-To: <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt
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, 11 Mar 2013 19:22:30 -0000

On 03/11/2013 07:51 PM, MARCON, JEROME (JEROME) wrote:
> Randell,
>
> Assuming that some day a spec defines the transport of T.140 (or whatever similar protocol) over RTCWeb data channels
> - with a registered subprotocol
> - with multiple reliability options supported
> - requiring some new data channel properties
> - of which some are assymetric between the endpoints (like the "characters per second" defined in [RFC4103].
>
> Then (in the current version of your proposal) it seems to me that
> * Because current DATA_CHANNEL_OPEN syntax is not extensible:
> - it is not possible to carry these new properties in DATA_CHANNEL_OPEN
>
> * Because the successful response to an open data channel request does not exist:
> - it is not possible to agree on assymetric property values
>
> * Because the error response to an open data channel has no payload (error):
> - an endpoint cannot easily know if this subprotocol is supported or which reliability properties are supported. Unless it sends as many DATA_CHANNEL_OPEN
>   messages as there are combinations of {subprotocol, property variants}

Is there any reason why the app that desires to use such a protocol over 
a data channel shouldn't send a new message (defined in the protocol) 
after the DATA_CHANNEL_OPEN saying what the desired properties are, and 
with an accept/reject message on the return channel?

One of the desirable properties of DATA_CHANNEL_OPEN is that it's 
simple. I'd like to keep it that way.