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

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 4 Aug 2015 15:43:09 +0200

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

---

From: Christian Groves <[email-masked]>
Date: Mon, 10 Aug 2015 15:06:58 +1000

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:
> Additionally, I've modified this moved text in order to make it as far 
> (JavaScript) API independent as possible.
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Mon, 10 Aug 2015 17:44:21 +0200

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:
> 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
>
>> Additionally, I've modified this moved text in order to make it as far (JavaScript) API 
>> independent as possible.

---

From: Christian Groves <[email-masked]>
Date: Tue, 11 Aug 2015 11:32:59 +1000

Hello Juergen,

The proposed update is OK for me.

Regards, Christian

On 11/08/2015 1:44 AM, Juergen Stoetzer-Bradler wrote:
> Agree to adding information to 5.1.1.4 regarding the relationship of 
> the "subprotocol" parameter's value and
> '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."
>
>> parameter. This clause could also provide a linkage given that we 
>> agreed to use the same registry as DCEP.
>>
>> Regards, Christian
>>
>>> Additionally, I've modified this moved text in order to make it as 
>>> far (JavaScript) API independent as possible.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Aug 2015 10:14:04 -0400

Sounds good.

On 8/10/15 11:44 AM, Juergen Stoetzer-Bradler wrote:
> Agree to adding information to 5.1.1.4 regarding the relationship of the
> "subprotocol" parameter's value and