IETF Logo Mail Archive

Re: [rtcweb] Sending of zero-length messages over data channels

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Mon, 04 August 2014 21:08 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9822B1A032E for <rtcweb@ietfa.amsl.com>; Mon, 4 Aug 2014 14:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8odI93A4FbW for <rtcweb@ietfa.amsl.com>; Mon, 4 Aug 2014 14:08:11 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD151A032C for <rtcweb@ietf.org>; Mon, 4 Aug 2014 14:08:10 -0700 (PDT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 4EC89C76C14C0; Mon, 4 Aug 2014 21:08:06 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s74L87so005717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 17:08:08 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 4 Aug 2014 17:08:07 -0400
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Harald Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Sending of zero-length messages over data channels
Thread-Index: AQHPpipfEWtPO6jXOES6Y6R7CwNaxJutiTxggAI5gwD//74D0IAATLYA///AneCAAFNggP//xY3gAej9c4AAExpK0AA3G/IAAAf73sA=
Date: Mon, 04 Aug 2014 21:08:06 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E4ED9F4@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <CAOJ7v-0F9pysYLehjTVDv1Sxz3TKaxi2y6J7RrpGqMdA=tiR_g@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E4BCC13@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAOJ7v-1r-vToAf-rUfZmKsBC4MX4ZXUcAkqahrskF1D3axOpuA@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E4C5974@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAOJ7v-1VPP8iAz+gr9h98QUzZnBVna84yPqtc0JZR=ehGgJL0A@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E4C5E94@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAOJ7v-2SkB3Pqctpu1S_wMY2b6jdOYyz8KxAYLA-q++2WdUbYw@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E4C61A5@US70UWXCHMBA02.zam.alcatel-lucent.com> <53DDFEC1.3020907@alvestrand.no> <E1FE4C082A89A246A11D7F32A95A17828E4EC8B4@US70UWXCHMBA02.zam.alcatel-lucent.com> <53DFF0C8.7000604@alvestrand.no>
In-Reply-To: <53DFF0C8.7000604@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E4ED9F4US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mIhT2rKq_Eo5duFNZS463md48YM
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Aug 2014 21:08:13 -0000

>Because WebSockets doesn't have any functionality corresponding to >PPID_OOB.

>Adding more functions that WebSockets doesn't have makes compatibility >with WebSockets worse.
<Raju>
Per the discussions I thought only backward compatibility with Websocket API is what's desired with data channel API. Does it also mean data channel API can't add new APIs while maintaining compatibility to existing ones? I don't see a reason why new APIs can't be added and be restricted by websocket API though! Such restriction will limit the data channel API and won't allow leveraging on the flexibility provided by data channel's SCTP transport only.

</Raju>

BR
Raju

v2.23.0 | Report a Bug | By Email