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

"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Tue, 06 October 2015 15:31 UTC

Return-Path: <albrecht.schwarz@alcatel-lucent.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 E96901B40F3 for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 08:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ctDtU_HC_ExV for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 08:31:19 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 16AA91B4104 for <mmusic@ietf.org>; Tue, 6 Oct 2015 08:31:19 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C87D26B0FA179; Tue, 6 Oct 2015 15:31:14 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t96FVG0Y005120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Oct 2015 17:31:16 +0200
Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.183]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 6 Oct 2015 17:31:16 +0200
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt
Thread-Index: AQHRAELfv6ltClEGFUCeThbLDrgWzZ5elYtA
Date: Tue, 06 Oct 2015 15:31:15 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1ACDF796CED@FR711WXCHMBA01.zeu.alcatel-lucent.com>
References: <786615F3A85DF44AA2A76164A71FE1ACDF796695@FR711WXCHMBA01.zeu.alcatel-lucent.com> <5613D9D6.3060009@alum.mit.edu>
In-Reply-To: <5613D9D6.3060009@alum.mit.edu>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/4DebfjziqVcG-uwX8R4duOcrQsA>
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 15:31:26 -0000

My understanding:
The websocket based transport would lead to separate, self contained TCP connections, hence in opposition to the goal in minimizing the number of L4 connections for a WebRTC call.

There might be many, but not "infinite" IP application protocols as candidates for a WebRTC data service, given the "RTC character" and conversational service category.

That set of IP application protocols might be divided in two classes: a) generic and b) application-specific protocols from SDP perspective. Preferably, the majority would belong to (a). Unfortunately, the first three are of type (b).

Paul, don't got a general view / answer on your question.

Regards,
Albrecht


-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Dienstag, 6. Oktober 2015 16:25
To: 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

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
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic