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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 06 October 2015 14:25 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 6DD8A1B406B for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 07:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
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 NG6twpnpevYD for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 07:25:28 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73591ACDBC for <mmusic@ietf.org>; Tue, 6 Oct 2015 07:25:27 -0700 (PDT)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-08v.sys.comcast.net with comcast id RqRK1r00529Cfhx01qRTXN; Tue, 06 Oct 2015 14:25:27 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-03v.sys.comcast.net with comcast id RqRS1r00K3Ge9ey01qRSAW; Tue, 06 Oct 2015 14:25:27 +0000
To: mmusic@ietf.org
References: <786615F3A85DF44AA2A76164A71FE1ACDF796695@FR711WXCHMBA01.zeu.alcatel-lucent.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <5613D9D6.3060009@alum.mit.edu>
Date: Tue, 6 Oct 2015 10:25:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <786615F3A85DF44AA2A76164A71FE1ACDF796695@FR711WXCHMBA01.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1444141527; bh=rtzaEKhrkRUihzCkgs86WIlWVzePXG+xHBbRDaG6AWo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=tDkF6zTVp3L4p2viGGiWkMNr6vPry6T8qmmKQmYNmS7lYKk0o9/lFoqnSFJokntOm kcRMR/X9h3MziGdMjR4iPfSSm0TEAUmbgc0j/U+KwbeI5k9anTIOoLimfWPA3aINPC 5DxhjaW/j9bbw4z0kUm55c5qOFFbmdo/NoOBZQ1EoJvy1/cCe0/yZBsjKDgcuoCfg7 JcXJr9NToINvSKs1gWKZ/NVIZ2s1mudQTjWRDdQu7EQq1bS+ud+qIisw6DL/nncfIW pUgEUbjI6fkHczRVbArltkGS/gXdl9mXMlTg6I/ILU9+NddtsXjc5iFFHwOhCN5RPL FXcFk0yX/Vg/g==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/43BCWloF5crNkSy4FYYJ94im1X4>
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 14:25:29 -0000

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.)

	Thanks,
	Paul

On 10/6/15 3:47 AM, Schwarz, Albrecht (Albrecht) wrote:
> Dear All,
>
> like too remind that there are three first WebRTC data channel applications,
> 1) MSRP based instant messaging,
> 2) T.140 based text conversation and
> 3) BFCP based floor control within a WebRTC conference service.
>
> draft-ietf-mmusic-msrp-usage-data-channel was/is the precedent for getting a common understanding about application protocol specific SDP usage (on top of the generic control of a DC).
> The discussion and protocol design are fairly mature in the meanwhile, hence it is time to start the work on the two other applications.
> We've prepared initial drafts, derived from the "MSRP draft", see:
>
> T.140 Text Conversation over Data Channels
> draft-schwarz-mmusic-t140-usage-data-channel-02.txt
>
> BFCP floor control signalling over Data Channels
> draft-schwarz-mmusic-bfcp-usage-data-channel-01.txt
>
> We'd like to request MMUSIC for adoption of these drafts.
>
> Regards,
> Albrecht
>
>
>
> Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>
> Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com> Wed, 09 September 2015 14:45 UTCShow header
>
> Hello,
>
> Version 02 of draft-ietf-mmusic-msrp-usage-data-channel addresses Christian's comments to version 01,
> http://www.ietf.org/mail-archive/web/mmusic/current/msg14537.html,
> except for the "setup" attribute related one.
>
> We'll come back regarding the SDP setup attribute, which can be part of an MSRP over data channel
> related SDP media description as media level "a=setup" attribute and/or as MSRP sub-protocol specific
> attribute "a=dcsa:x setup".
>
> Thanks,
> Juergen
>
> On 09.09.2015 16:33, internet-drafts@ietf.org wrote:
>> A new version of I-D, draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>> has been successfully submitted by Juergen Stoetzer-Bradler and posted to the
>> IETF repository.
>>
>> Name:		draft-ietf-mmusic-msrp-usage-data-channel
>> Revision:	02
>> Title:		MSRP over Data Channels
>> Document date:	2015-09-09
>> Group:		mmusic
>> Pages:		15
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-02
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-02
>>
>> Abstract:
>>      This document specifies how the Message Session Relay Protocol (MSRP)
>>      can be instantiated as a data channel sub-protocol, using the SDP
>>      offer/answer exchange-based generic data channel negotiation
>>      framework.  Two network configurations are documented: a WebRTC end-
>>      to-end configuration (connecting two MSRP over data channel
>>      endpoints), and a gateway configuration (connecting an MSRP over data
>>      channel endpoint with an MSRP over TCP endpoint).
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>