Subject: [MMUSIC] Initial comments on draft-ietf-mmusic-data-channel-sdpneg-00

From: Christer Holmberg <[email-masked]>
Date: Sun, 8 Feb 2015 14:11:54 +0000

Hi,

A few initial comments on draft-ietf-mmusic-data-channel-sdpneg-00:

Q1: SCTP over DTLS terminology

The draft mentions "SCTP over DTLS" in a few places. If we, in some introduction/overview, want to inform the reader that data channels are realized using SCTP over DTLS associations, fine. But, other than that, I think we should talk about data channels - because otherwise people may think that the mechanism can also be used for non-data channel "SCTP over DTLS" applications.

I also suggest to remove "SCTP over DTLS" from the draft title.

Q2: SDP dcep attribute ordered parameter.

Do we need to define values ("0" and "1") for the attribute ordered parameter. Why not e.g. simply define the parameter name, without a value, and not including the parameter would mean unordered?

Q3: IANA registry

As defined in Section 8, the subprotocol values are registered in the IANA WebSocket protocol registry - i.e. the same registry also used by DCEP.

My question is: if I register a protocol value, "X", that I want to use with DCEP, should I also provide the needed information needed for usage of the SDP-NEG mechanism? Otherwise, if someone wants to negotiate "X" using the SDP-NEG mechanism, he/she either has to register a new value - or update the previously registered "X" value.

(I guess Q3  needs to be discussed with the RTCWEB folks)

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 9 Feb 2015 20:22:08 +0000

Hi Christer,
Thanks for the comments. Please see inline responses.

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Sunday, February 08, 2015 8:12 AM
To: [email-masked]
Subject: [MMUSIC] Initial comments on draft-ietf-mmusic-data-channel-sdpneg-00

Hi,

I also suggest to remove "SCTP over DTLS" from the draft title.
[Raju] Ok, we will use "Data Channels" terminology instead and also change the title as well.

Do we need to define values ("0" and "1") for the attribute ordered parameter. Why not e.g. simply define the parameter name, without a value, and not including the parameter would mean unordered?
[Raju] We discussed this in the past at http://www.ietf.org/mail-archive/web/mmusic/current/msg13878.html
Can you please go thru it and let us know your decision.

Q3: IANA registry

My question is: if I register a protocol value, "X", that I want to use with DCEP, should I also provide the needed information needed for usage of the SDP-NEG mechanism? Otherwise, if someone wants to negotiate "X" using the SDP-NEG mechanism, he/she either has to register a new value - or update the previously registered "X" value.
[Raju] Keith Drage will respond to this comment.

BR
Raju

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 10 Feb 2015 01:30:47 +0000

Your question is not clear as to which attribute you are referring to.

I have been thinking about what to write in the IANA registration subclause.

In regard of the dcmap attribute, then we obviously need to register values, which are strings of characters, and a reference to where they are defined.

This list will not be the same as the registration table created by RFC 6455 for websocket subprotocols,

http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name

as different needs will mean that websocket protocols are defined at different times, and maybe not at all, to the data channel sub-protocol label. That also means that the existence of a value in a combined table would not necessarily be valid as a label in websocket and data channel sub-protocol. Also the reference would be different.

That means that I am not convinced of any benefit of having a combined table for websocket sub-protocol and data channel sub-protocol.

I would also seek input as to what would be considered an appropriate registration policy for such labels. Would specification required be sufficient? Does it require expert review - personally I think not? Is it as low as first come first served?

As regards the dcsa attribute, I do not think this requires any IANA registration of contents. The attribute consists of a value identifying the channel and the an existing defined attribute. I do not see any attributes needing to be defined solely for use when used in data channel that are not valid for use when used outside of data channel. Thoughts?

regards

Keith

________________________________
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 08 February 2015 14:12
To: [email-masked]
Subject: [MMUSIC] Initial comments on draft-ietf-mmusic-data-channel-sdpneg-00

Hi,

Q3: IANA registry

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Tue, 10 Feb 2015 15:49:07 +1100

Hello Keith,

I guess I don't understand why 
http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name 
couldn't be used when it is used for the DCEP protocol? My understanding 
of draft-ietf-mmusic-data-channel-sdpneg-00 was that it basically 
emulated what DCEP does except that it is out of band using SDP. If 
there's a concern that the sub-protocol would not be valid for websocket 
doesn't that also apply to the DCEP usage?

Regards, Christian

On 10/02/2015 12:30 PM, DRAGE, Keith (Keith) wrote:
> In regard of the dcmap attribute, then we obviously need to register 
> values, which are strings of characters, and a reference to where they 
> are defined.
> as different needs will mean that websocket protocols are defined at 
> different times, and maybe not at all, to the data channel 
> sub-protocol label. That also means that the existence of a value in a 
> combined table would not necessarily be valid as a label in websocket 
> and data channel sub-protocol. Also the reference would be different.
> That means that I am not convinced of any benefit of having a combined 
> table for websocket sub-protocol and data channel sub-protocol.
> I would also seek input as to what would be considered an appropriate 
> registration policy for such labels. Would specification required be 
> sufficient? Does it require expert review - personally I think not? Is 
> it as low as first come first served?
> As regards the dcsa attribute, I do not think this requires any IANA 
> registration of contents. The attribute consists of a value 
> identifying the channel and the an existing defined attribute. I do 
> not see any attributes needing to be defined solely for use when used 
> in data channel that are not valid for use when used outside of data 
> channel. Thoughts?
> regards
> Keith
>
>     ------------------------------------------------------------------------
>     *From:* mmusic [mailto:[email-masked]] *On Behalf Of
>     *Christer Holmberg
>     *Sent:* 08 February 2015 14:12
>     *To:* [email-masked]
>     *Subject:* [MMUSIC] Initial comments on
>     draft-ietf-mmusic-data-channel-sdpneg-00
>
>     Hi,
>
>     The draft mentions “SCTP over DTLS” in a few places. If we, in
>     some introduction/overview, want to inform the reader that data
>     channels are realized using SCTP over DTLS associations, fine.
>     But, other than that, I think we should talk about data channels –
>     because otherwise people may think that the mechanism can also be
>     used for non-data channel “SCTP over DTLS” applications.
>
>     I also suggest to remove “SCTP over DTLS” from the draft title.
>
>     Do we need to define values (“0” and “1”) for the attribute
>     ordered parameter. Why not e.g. simply define the parameter name,
>     without a value, and not including the parameter would mean unordered?
>
>     Q3: IANA registry
>
>     As defined in Section 8, the subprotocol values are registered in
>     the IANA WebSocket protocol registry – i.e. the same registry also
>     used by DCEP.
>
>     My question is: if I register a protocol value, “X”, that I want
>     to use with DCEP, should I also provide the needed information
>     needed for usage of the SDP-NEG mechanism? Otherwise, if someone
>     wants to negotiate “X” using the SDP-NEG mechanism, he/she either
>     has to register a new value – or update the previously registered
>     “X” value.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Feb 2015 07:27:27 +0000

Hi,

> couldn't be used when it is used for the DCEP protocol? My understanding of draft-ietf-mmusic-data-channel-sdpneg-00 was 
> that it basically emulated what DCEP does except that it is out of band using SDP. If there's a concern that the sub-protocol 
> would not be valid for websocket doesn't that also apply to the DCEP usage?

I agree with Christian. I think we should use the same protocol values (and same registry) as DCEP.

> table for websocket sub-protocol and data channel sub-protocol.

As far as I know, we already have that.

Regards,

Christer

On 10/02/2015 12:30 PM, DRAGE, Keith (Keith) wrote:
> http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-
> name as different needs will mean that websocket protocols are defined 
> at different times, and maybe not at all, to the data channel 
>     The draft mentions "SCTP over DTLS" in a few places. If we, in
>     But, other than that, I think we should talk about data channels -
>     used for non-data channel "SCTP over DTLS" applications.
>
>     Do we need to define values ("0" and "1") for the attribute
>     the IANA WebSocket protocol registry - i.e. the same registry also
>     used by DCEP.
>
>     My question is: if I register a protocol value, "X", that I want
>     wants to negotiate "X" using the SDP-NEG mechanism, he/she either
>     has to register a new value - or update the previously registered
>     "X" value.
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Feb 2015 07:57:42 +0000

Hi,

[Christer] Perhaps we should use "WebRTC Data Channels", because that seems to be the "official" name.

[Christer] Well, IF we want to use a value, then I'd suggest to use "true" and "false" instead of "1" and "0" (similar to isFocus).

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 10 Feb 2015 16:27:43 +0000

>seems to be the "official" name.
[Raju] Ok, we will use that. I initially had a concern about use of "WebRTC" in the name, but after thinking a bit more it appears to me "WebRTC" here does not represent the name of the application, but rather represents the data channel implementation level.

>[Christer] Well, IF we want to use a value, then I'd suggest to use "true" >and "false" instead of "1" and "0" (similar to isFocus).
[Raju] I am sorry, I could not find isFocus SDP definition. I only found isFocus media feature tag (https://tools.ietf.org/html/rfc4579) to be used in SIP contact hdr, which is not SDP. Can you please point me to the definition?

BR
Raju

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, February 10, 2015 1:58 AM
To: Makaraju, Maridi Raju (Raju); [email-masked]
Subject: RE: [MMUSIC] Initial comments on draft-ietf-mmusic-data-channel-sdpneg-00

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Feb 2015 08:54:07 +0000

Hi,

> [Raju] Ok, we will use that. I initially had a concern about use of "WebRTC" in the name, but after thinking a bit more it appears to me "WebRTC" here does not 
> represent the name of the application, but rather represents the data channel implementation level.

Some people, including myself, have commented on the usage of "WebRTC" in RTCWEB. But, it's still there :)

> [Raju] I am sorry, I could not find isFocus SDP definition. I only found isFocus media feature tag (https://tools.ietf.org/html/rfc4579) to be used in SIP contact hdr, which is not SDP. Can you ple…

Ok, I mixed attributes with media feature tags. But, never the less, I still think "true" and "false" is more clear than "1" and "0", eventhough my personal preference would be to only use "ordered", and not including it would mean unordered.

Regards,

Christer

Hi,

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 12 Feb 2015 13:08:41 +0000

> >
> > [Raju] I am sorry, I could not find isFocus SDP definition. I only found
> isFocus media feature tag (https://tools.ietf.org/html/rfc4579) to be used
> in SIP contact hdr, which is not SDP. Can you please point me to the
> definition?
> 
> Ok, I mixed attributes with media feature tags. But, never the less, I still
> think "true" and "false" is more clear than "1" and "0", eventhough my
> personal preference would be to only use "ordered", and not including it
> would mean unordered.
[Raju] In the past, Paul also showed similar interest for using ordered, unordered.
So, yielding to popular demand we will change drafts to use ordered, unordered 
unless we see any objections on the list.

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Feb 2015 13:22:53 +0000

Hi,

>>> isFocus media feature tag (https://tools.ietf.org/html/rfc4579) to be 
>>> used in SIP contact hdr, which is not SDP. Can you please point me to 
>>> the definition?
>> 
>> Ok, I mixed attributes with media feature tags. But, never the less, I 
>> still think "true" and "false" is more clear than "1" and "0", 
>> eventhough my personal preference would be to only use "ordered", and 
>> not including it would mean unordered.
> So, yielding to popular demand we will change drafts to use ordered, unordered unless we see any objections on the list.

Do we need both? For example, if we only define "ordered", not including it would mean "unordered".

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 12 Feb 2015 15:48:10 +0000

> > So, yielding to popular demand we will change drafts to use ordered,
> unordered unless we see any objections on the list.
> 
[Raju] I think it is preferred to have both so that one can explicitly include either.
However, I do see the value of just defining "ordered" which avoids ambiguity of including 
both the tokens. 
I would like to hear what others (especially Paul) think about defining just "ordered". 

BR
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Feb 2015 12:18:59 -0500

> Do we need both? For example, if we only define "ordered", not including it would mean "unordered".

I prefer to have both - to have an affirmative way to identify which you 
want.

This change should help, since currently I still can't tell whether is 
is 0 or 1 that means ordered. :-)

	Thanks,
	Paul

---

From: [email-masked]
Date: Thu, 12 Feb 2015 15:40:17 -0600

Hi Raju

Instead of assuming that if "ordered" is not included means that it is 
unordered, ordered=true or ordered=false is better.  E.g. a=dcmap:2 
subprotocol="MSRP";ordered="true";label="MSRP"

Regards
Ranjit

On 2015-02-12 9:48 am, Makaraju, Maridi Raju (Raju) wrote:
>> Do we need both? For example, if we only define "ordered", not 
>> including it
>> would mean "unordered".

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Feb 2015 12:01:16 +0000

Hi,

> Instead of assuming that if "ordered" is not included means that it is unordered, ordered=true or ordered=false is better.  E.g. a=dcmap:2 subprotocol="MSRP";ordered="true";label="MSRP"

If that's what people want, I can live with it :)

However, would we then need to define a default value, in case the parameter is not present?

Regards,

Christer

On 2015-02-12 9:48 am, Makaraju, Maridi Raju (Raju) wrote:
>> >>> [Raju] I am sorry, I could not find isFocus SDP definition. I 
>> >>> only found isFocus media feature tag 
>> >>> (https://tools.ietf.org/html/rfc4579) to be used in SIP contact 
>> >>> hdr, which is not SDP. Can you please point me to the definition?
>> >>
>> >> Ok, I mixed attributes with media feature tags. But, never the 
>> >> less, I still think "true" and "false" is more clear than "1" and 
>> >> "0", eventhough my personal preference would be to only use 
>> >> "ordered", and not including it would mean unordered.
>> > [Raju] In the past, Paul also showed similar interest for using 
>> > ordered,
>> unordered.
>> including it would mean "unordered".
> However, I do see the value of just defining "ordered" which avoids 
> ambiguity of including both the tokens.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Feb 2015 11:51:34 -0500

> If that's what people want, I can live with it :)

I am ok with either ordered={true/false} or ordered/unordered.
I'm not ok with ordered={0/1}.

> However, would we then need to define a default value, in case the parameter is not present?

Either way there needs to be a default.
I'm inclined to think that "ordered" (or ordered=true) should be the 
default, but I don't feel strongly about it.

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 13 Feb 2015 18:22:17 +0000

> However, would we then need to define a default value, in case the parameter

[Raju] Correct.
I see consensus for the use of "ordered" parameters with values of "true" and "false" with a default value of "true".
Since only true and false keywords are allowed (and no spaces) I am thinking no quotes are needed around those. So, the earlier stated example will become:

a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP"
which is same as (default assumed):
a=dcmap:2 subprotocol="MSRP";label="MSRP"

If ordered parameter has value other than true or false then default true is assumed. This also means if quoted "true" or "false" are used then the value is ignored and true is assumed. I believe this keeps it simple. Please let me know if you don't agree.

Thank you all for the comments.

BR
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Feb 2015 13:37:58 -0500

> If ordered parameter has value other than true or false then default true is assumed. This also means if quoted "true" or "false" are used then the value is ignored and true is assumed. I believe t…

IMO it is neither necessary, nor desirable, to define the behavior when 
invalid values are used. Doing so simply makes those into defacto 
synonyms for true.

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 13 Feb 2015 19:26:38 +0000

> > If ordered parameter has value other than true or false then default true
> is assumed. This also means if quoted "true" or "false" are used then the
> value is ignored and true is assumed. I believe this keeps it simple. Please
> let me know if you don't agree.
> 
> synonyms for true

[Raju] Thanks for the quick comment.
I am ok to not define behavior for invalid values, i.e. the behavior is "undefined". That seems to be the general philosophy with other SDP related RFCs/drafts as well anyways.
I will wait for more feedback from others as well.

BR
Raju

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 13 Feb 2015 19:40:07 +0000

This does raise the question of what the error handling is for malformed syntax.

I assume the RFC 4566 action would be to ignore the entire a=dcmap line, but at moment cannot find a statement in RFC 4566 indicating that.

I suspect there are problems with trying only to ignore the malformed parameter and using the remainder of the line. 

Regards

Keith

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of 
> Makaraju, Maridi Raju (Raju)
> Sent: 13 February 2015 19:27
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [MMUSIC] Initial comments on 
> > > If ordered parameter has value other than true or false 
> then default 
> > > true
> > is assumed. This also means if quoted "true" or "false" are 
> used then 
> > the value is ignored and true is assumed. I believe this keeps it 
> > simple. Please let me know if you don't agree.
> > 
> > IMO it is neither necessary, nor desirable, to define the behavior 
> > when invalid values are used. Doing so simply makes those 
> into defacto 
> > synonyms for true
> 
> I am ok to not define behavior for invalid values, i.e. the 
> behavior is "undefined". That seems to be the general 
> philosophy with other SDP related RFCs/drafts as well anyways.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Feb 2015 16:04:37 -0500

> I suspect there are problems with trying only to ignore the malformed parameter and using the remainder of the line.

I don't know if there has ever been a statement about this. (I haven't 
searched 4566 for a statement on this, but am not aware of one.)

The expectations could be different for SDP used in O/A than for SDP 
used declaratively.

In the case of SDP used with SIP, badly formed SDP received in a request 
can be rejected with a 488 or 606 response. But that doesn't work for 
badly formed SDP in an response or ACK.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Feb 2015 23:26:02 +0000

Hi,

>> is assumed. This also means if quoted "true" or "false" are used then 
>> when invalid values are used. Doing so simply makes those into defacto 
>> synonyms for true
>
> I am ok to not define behavior for invalid values, i.e. the behavior is "undefined". That seems 
> to be the general philosophy with other SDP related RFCs/drafts as well anyways.

I also suggest you define the values as TOKENs, not strings.

So, e.g. ordered=true instead of ordered="true"

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 13 Feb 2015 23:29:05 +0000

> So, e.g. ordered=true instead of ordered="true"
[Raju] Yes, tokens will be used not quoted strings, which I thought I already indicated in my earlier response. :-)

Thanks
Raju