IETF Logo Mail Archive

Re: [rtcweb] Non-media data service consensus and requirements

Matthew Kaufman <matthew.kaufman@skype.net> Mon, 27 June 2011 22:43 UTC

Return-Path: <matthew.kaufman@skype.net>
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 C82C91F0C58 for <rtcweb@ietfa.amsl.com>; Mon, 27 Jun 2011 15:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 skrOUniAPC65 for <rtcweb@ietfa.amsl.com>; Mon, 27 Jun 2011 15:43:46 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 96B0D1F0C49 for <rtcweb@ietf.org>; Mon, 27 Jun 2011 15:43:46 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 6870016F0; Tue, 28 Jun 2011 00:43:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=mx; bh=t9qt7ngnczAiEcWp+BsuxPSFRtY=; b=j6GXeNx a90xxMOSc6y8zSODfcazq6cw/pUhxQ2OfoEN4WpLg7h5/R3jep2/iq7FRq9EyzI1 E1aF953oQO83GrsuVrahOEZh2kiFGvxzV8FMO+ACDXQYFGmQHy4+lI5LeUTK6+ln J+3dqLsknhSZfbvcAH0rjx3wjIPI21huS8pY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to; q=dns; s=mx; b=Q24rcNvPwqA8YsRArHffqSIqQrBI6vGtKpRlGNXRHFx0sh7u mV4KV21kvGF5x1d63PHWb4iRJ2qmuPoYUIm88FGU2kerO7rwNj7ulvSxG9IRqvTW WQBB1lLy+2r32Vq6g+I3iGGwHaPX/xT8qGhuX+t69hCw67u2FsMeQGAfH98=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 66AB57F8; Tue, 28 Jun 2011 00:43:45 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 4BE163507DCF; Tue, 28 Jun 2011 00:43:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZjS-u6f4qOV; Tue, 28 Jun 2011 00:43:44 +0200 (CEST)
Received: from [172.17.61.96] (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id 7EDF03507DBA; Tue, 28 Jun 2011 00:43:43 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary="Apple-Mail-63-194939573"
From: Matthew Kaufman <matthew.kaufman@skype.net>
In-Reply-To: <blu152-w313AC2093422E0C005708093570@phx.gbl>
Date: Mon, 27 Jun 2011 15:43:41 -0700
Message-Id: <665F50A5-580D-47BD-93CB-903DC182F657@skype.net>
References: <blu152-w313AC2093422E0C005708093570@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
X-Mailer: Apple Mail (2.1082)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Non-media data service consensus and requirements
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, 27 Jun 2011 22:43:47 -0000

On Jun 27, 2011, at 3:35 PM, Bernard Aboba wrote:

> I do not support an unreliable datagram service that can be used to send arbitrary data.  

Mostly disagree. It should be possible to send arbitrary data from one browser to another.

> 
> For example, it seems dangerous for a Web browser under the control of an attacker to be able to send RIP, SNMP or DNS packets to arbitrary destinations. 
> 

Agreed, so the encapsulation must prevent this.

> For these transactional exchanges the overhead of ICE would be excessive and so there will be a very strong temptation to cut corners. 
> 

Disagree. Browser vendors will have a strong incentive to not cut corners.

> Assuming that the goal is not to send arbitrary data, then we need to dig into the transport requirements more. 
> 
> For example, is the non-media data to be synchronized with media (e.g. real-time text)?
> 

Maybe.

> Is there a session associated with the non-media data (e.g. XMPP or MSRP exchanges)? 
> 

Maybe.

> Is there a reliability requirement? 
> 

Maybe.

> Is it congestion-controlled? 
> 

This must be enforced.

> How long-lived are the flows? 
> 

Totally depends on the application.

Matthew Kaufman

v2.12.3 | Report a Bug | By Email