Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 02 November 2014 16:36 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 CDBA81A8946 for <mmusic@ietfa.amsl.com>; Sun, 2 Nov 2014 08:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.972
X-Spam-Level:
X-Spam-Status: No, score=0.972 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.972] 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 hLccxzG3g17f for <mmusic@ietfa.amsl.com>; Sun, 2 Nov 2014 08:36:58 -0800 (PST)
Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E156E1A0065 for <mmusic@ietf.org>; Sun, 2 Nov 2014 08:36:55 -0800 (PST)
Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-12v.sys.comcast.net with comcast id Agc51p00B516pyw01gcv5X; Sun, 02 Nov 2014 16:36:55 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-08v.sys.comcast.net with comcast id Agcu1p00H3Ge9ey01gcuqm; Sun, 02 Nov 2014 16:36:55 +0000
Message-ID: <54565DA6.7060706@alum.mit.edu>
Date: Sun, 02 Nov 2014 11:36:54 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <949EF20990823C4C85C18D59AA11AD8B26DC50@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B26DC50@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414946215; bh=lvIupg8IGCr3oylv02/ZD4x3DkechglAjVUnekyy+kk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QVL0z10Bj/vZJOhEiUufs6KqGFNhPb7gbRyEGckRPOZUr9xejlPdvRZYRvDv0mHAe lZNMRblCwXajlMzoiVSrLP7muht79s8fa4F0keEsliq9XYZAN5B2Km/x0ow/BFwy+u u5YiMwjBflJaKw+Bz4JjPmFMbkuYWX93il6n034T68gUcTWSw3fOjZwRIkLQh7DTcS 9VsZTB61RXMumHo2o2LhJCSdMuWYW61GES8bMHSrvgWws2FehCzlO0QG0imqCvZg51 HqMk4B9pv1Cl3HHkGfPX994uFc7IBhpTIYmpzfXPeldHGDz2hXBFqnpeOjWHPb2C3H nP5qEJr8qoLNg==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8yAWNrE0o1JHV48RbJQY-ESzW0k
Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel
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: <http://www.ietf.org/mail-archive/web/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: Sun, 02 Nov 2014 16:37:00 -0000

On 11/2/14 10:07 AM, DRAGE, Keith (Keith) wrote:
> At the London IETF meeting, we were not quite at the point of asking for adoption of draft-ejzak-mmusic-data-channel-sdpneg. There was a request that certain revisions should be made and a couple of issues addressed.
>
> That has now occurred.
>
> I would like to ask if we can now moved forward to adoption of this draft as a working group item. While it is the responsibility of the chairs to make a formal call, I have asked for a small amount of time in Honolulu with this intent, and it would be useful if people could start to express their opinions one way or other on the list, i.e. whether they think the draft is generally useful, or alternatively, just a bad idea!

I support adopting this draft.

	Thanks,
	Paul

> Regards
>
> Keith
>
>> -----Original Message-----
>> From: DRAGE, Keith (Keith)
>> Sent: 27 October 2014 14:39
>> To: mmusic@ietf.org
>> Subject: draft-ejzak-mmusic-data-channel-sdpneg and
>> draft-ejzak-mmusic-msrp-usage-data-channel
>>
>> Based on the discussion on list over the last few days, I
>> have submitted revised versions of the two SDP negotiation
>> over data channel drafts as follows:
>>
>> A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt
>> has been successfully submitted by Keith Drage and posted to
>> the IETF repository.
>>
>> Name:		draft-ejzak-mmusic-data-channel-sdpneg
>> Revision:	02
>> Title:		SDP-based "SCTP over DTLS" data channel
>> negotiation
>> Document date:	2014-10-27
>> Group:		Individual Submission
>> Pages:		22
>> URL:
>> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-ch
>> annel-sdpneg-02.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-chann
>> el-sdpneg/
>> Htmlized:
>> http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-chann
>> el-sdpneg-02
>>
>> Abstract:
>>     The Real-Time Communication in WEB-browsers (RTCWeb)
>> working group is
>>     charged to provide protocols to support direct interactive rich
>>     communications using audio, video, and data between two peers' web-
>>     browsers.  For the support of data communication, the
>> RTCWeb working
>>     group has in particular defined the concept of bi-directional data
>>     channels over SCTP, where each data channel might be used to
>>     transport other protocols, called sub-protocols.  Data
>> channel setup
>>     can be done using either the internal in-band band (also
>> referred to
>>     as 'internal' for the rest of the document) WebRTC Data Channel
>>     Establishment Protocol or some external out-of-band simply referred
>>     to as 'external negotiation' in the rest of the document . This
>>     document specifies how the SDP offer/answer exchange can be used to
>>     achieve such an external negotiation.  Even though data
>> channels are
>>     designed for RTCWeb use initially they may be used by
>> other protocols
>>     like, but not limited to, the CLUE protocol.  This document is
>>     intended to be used wherever data channels are used.
>>
>>
>> A new version of I-D,
>> draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
>> has been successfully submitted by Keith Drage and posted to
>> the IETF repository.
>>
>> Name:		draft-ejzak-mmusic-msrp-usage-data-channel
>> Revision:	01
>> Title:		MSRP over SCTP/DTLS data channels
>> Document date:	2014-10-27
>> Group:		Individual Submission
>> Pages:		11
>> URL:
>> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-us
>> age-data-channel-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage
>> -data-channel/
>> Htmlized:
>> http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-
>> channel-01
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage
>> -data-channel-01
>>
>> Abstract:
>>     This document specifies how the Message Session Relay
>> Protocol (MSRP)
>>     can be instantiated as a data channel sub-protocol, using
>> the the SDP
>>     offer/answer exchange-based external negotiation defined in
>>     [I-D.ejzak-mmusic-data-channel-sdpneg].  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).
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>