Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

Roman Shpount <roman@telurix.com> Tue, 06 October 2015 18:07 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3451AD1A6 for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 11:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Lmmohv3L1EsI for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 11:07:32 -0700 (PDT)
Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD0A1ACE9B for <mmusic@ietf.org>; Tue, 6 Oct 2015 10:58:46 -0700 (PDT)
Received: by iofh134 with SMTP id h134so231284143iof.0 for <mmusic@ietf.org>; Tue, 06 Oct 2015 10:58:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kfuh/1/XJmx53bU6GyeIMpsnCqLhxDx+Pyj9tgKlcqA=; b=dHGRoIB8TzqjKt2R9VkfdKg1HAWHXMt92Zo8G9DGZWmR8G6QCHTkFU7qQB3+5oh4qK yevJA8tnETnAcqIH8OLBq+83y7AGqkCxTx2koyqah7epzLlKCFgSMZYhgrYDcsl+YsRh rTGxXPOOhqxmWBNRvFY40A6AqSsLPPMvcJHBWMQaJ1WhJdnThldGu0Y1QJRY7Os/526v fL85U3IVlgnHflfwXS/1DsD1DhWtyihKTBdmEazx4EVwrFYa90aksNbrUst6X5TEiLBD B4wr+oHoVfgLM+GvrNcxjKsxeoLmbg1yGE+BUff48p5xoG3mYKMHpPrGjJzcrqSb0u42 iGDw==
X-Gm-Message-State: ALoCoQmsSXcsnpFCgykHZOjnhTvPCsAvK53c66kacbbtBZf66v6qZJWdh/1/GbrFz2DL3OjrMNtT
X-Received: by 10.107.10.14 with SMTP id u14mr33589901ioi.94.1444154325536; Tue, 06 Oct 2015 10:58:45 -0700 (PDT)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com. [209.85.213.174]) by smtp.gmail.com with ESMTPSA id o74sm12693666ioo.8.2015.10.06.10.58.43 for <mmusic@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2015 10:58:44 -0700 (PDT)
Received: by igcpe7 with SMTP id pe7so30244603igc.0 for <mmusic@ietf.org>; Tue, 06 Oct 2015 10:58:43 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.79.166 with SMTP id k6mr17455911igx.24.1444154323338; Tue, 06 Oct 2015 10:58:43 -0700 (PDT)
Received: by 10.36.205.67 with HTTP; Tue, 6 Oct 2015 10:58:43 -0700 (PDT)
In-Reply-To: <5613D9D6.3060009@alum.mit.edu>
References: <786615F3A85DF44AA2A76164A71FE1ACDF796695@FR711WXCHMBA01.zeu.alcatel-lucent.com> <5613D9D6.3060009@alum.mit.edu>
Date: Tue, 6 Oct 2015 13:58:43 -0400
Message-ID: <CAD5OKxscPEakS9YZTN016SqD_d9qUt37PrSaDdg_ReGvu_w49w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=089e013a114e718dd20521736139
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Ti-SIx_8IMqLYSpaLFjABIScy64>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2015 18:07:33 -0000

On Tue, Oct 6, 2015 at 10:25 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> This motivates me to ask a question:
>
> How do we decide that an existing protocol should be extended to work
> using a data channel as its transport?
>
> Do we just do it for every protocol we can think of that could work that
> way?
>
> Note that many protocols that could run over a data channel could also run
> over a websocket transport. Should we define all of those too?
>
> (One "answer" to why we should define things over data channel is that
> this is a path to make them usable from webrtc clients. But such clients
> can also use websockets.)


One criteria would be that this protocol would benefit from peer-to-peer
support. Websockets protocol is client to server only, while data channel
supports both peer-to-peer and client to server. Another criteria would be
if the protocol can be negatively affected by front of the line blocking or
only requires unreliable messaging. T140 seems like the perfect example
where the protocol would benefit if it is transmitted over data channel vs
websocket.
_____________
Roman Shpount