Re: [MMUSIC] New version draft-ietf-mmusic-data-channel-sdpneg-04

Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com> Mon, 10 August 2015 15:44 UTC

Return-Path: <juergen.stoetzer-bradler@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 321211B371A for <mmusic@ietfa.amsl.com>; Mon, 10 Aug 2015 08:44:29 -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 tmPB6GP-TVm2 for <mmusic@ietfa.amsl.com>; Mon, 10 Aug 2015 08:44:26 -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 405FA1B371B for <mmusic@ietf.org>; Mon, 10 Aug 2015 08:44:26 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id F153C1D81B645 for <mmusic@ietf.org>; Mon, 10 Aug 2015 15:44:21 +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 t7AFiOmu007384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Mon, 10 Aug 2015 17:44:24 +0200
Received: from [135.244.193.186] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 10 Aug 2015 17:44:23 +0200
To: mmusic@ietf.org
References: <55C0C16D.9060809@alcatel-lucent.com> <55C83172.9020309@nteczone.com>
From: Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com>
Message-ID: <55C8C6D5.2060502@alcatel-lucent.com>
Date: Mon, 10 Aug 2015 17:44:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55C83172.9020309@nteczone.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070103070801030504010707"
X-Originating-IP: [135.239.27.38]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/mJQtqjZLTvcJojc7l2z0Gs67RL0>
Subject: Re: [MMUSIC] New version draft-ietf-mmusic-data-channel-sdpneg-04
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: Mon, 10 Aug 2015 15:44:29 -0000

Hello Christian,

Thank you for your comment.
Agree to adding information to 5.1.1.4 regarding the relationship of the "subprotocol" parameter's 
value and
DCEP DATA_CHANNEL_OPEN message's "Protocol" value. We could then also explicitly add text related
to empty "subprotocol" strings, similar to the "label" parameter related text in 5.1.1.3.
For instance:

"The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel.
This parameter maps to the 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol].
Section 8.1 specifies how new subprotocol parameter values are registered.
'Subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its 
value defaults to the empty string.

Note: The empty string MAY also be explicitly used as 'subprotocol' value,  such that 
'subprotocol=""' is equivalent to the 'subprotocol' parameter not being
present at all.  [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's 
'Subprotocol' value to be an empty string."

Would that be ok for you?

Thank you,
Juergen

On 10.08.2015 07:06, Christian Groves wrote:
> Hello Juergen,
>
> Looks good, only a minor comment:
> Cl.5.1.1.4 - The others clauses mention the mapping DCEP protocol parameter. This clause could 
> also provide a linkage given that we agreed to use the same registry as DCEP.
>
> Regards, Christian
>
> On 4/08/2015 11:43 PM, Juergen Stoetzer-Bradler wrote:
>> Have submitted version 04 of draft-ietf-mmusic-data-channel-sdpneg.
>> This version solves Paul's and Albrecht's comments to -03,
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg14917.html
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg14922.html
>>
>> Especially, I've moved the old section 5, which contained SDP offer/answer independent 
>> considerations
>> and into which I had inserted a couple of editor's notes, to a new Appendix A.
>> Additionally, I've modified this moved text in order to make it as far (JavaScript) API 
>> independent as possible.
>> Former section 6 is therefore now section 5.
>>
>> Thanks,
>> Juergen
>>
>> _______________________________________________
>> 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