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

"MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com> Mon, 11 March 2013 22:09 UTC

Return-Path: <jerome.marcon@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8E03C21F9044 for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 15:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.865
X-Spam-Status: No, score=-9.865 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vAuRosbSagab for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 15:09:02 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr []) by ietfa.amsl.com (Postfix) with ESMTP id 9ABBD21F9097 for <rtcweb@ietf.org>; Mon, 11 Mar 2013 15:09:02 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com []) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BM8iA1008571 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 23:08:58 +0100
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com ( by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ( with Microsoft SMTP Server (TLS) id; Mon, 11 Mar 2013 23:08:53 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 23:08:53 +0100
From: "MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com>
To: Harald Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOHo3R0WBnkelXBEOrl0OojyYzLZihCmJR
Date: Mon, 11 Mar 2013 22:08:53 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A024756@FR711WXCHMBA02.zeu.alcatel-lucent.com>
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>, <513E2EEE.3050106@alvestrand.no>
In-Reply-To: <513E2EEE.3050106@alvestrand.no>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_39821B4C400EC14DAD4DB25330A9271A024756FR711WXCHMBA02zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on
Subject: [rtcweb] RE : 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 22:09:03 -0000

De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de Harald Alvestrand [harald@alvestrand.no]
Date d'envoi : lundi 11 mars 2013 20:22
À : rtcweb@ietf.org
Objet : Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt

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.

[JM1] All right, this would work in many cases (brand-new protocols, and protocols "adapted" over RTCWeb data channels, which have or can easily integrate capabilities negotiation). In some cases though, that would be challenging: e.g. the character-oriented T.140 protocol.

rtcweb mailing list