Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01

[Paul Kyzivat <[e-mail]>]

Hi Raju,

On 10/21/14 1:04 PM, Makaraju, Maridi Raju (Raju) wrote:
> Hi Paul,
>
> Thanks for the detailed and thorough comments.
> Please see my inline responses below.
>
>> This is in much better shape now - having caught up with changes in the
>> related drafts. Here are a few comments and suggestions:
>>
>> * Section 5.1.1.1:
>>
>> Rather than using 'unordered=1' for unordered, and 'unordered=0' for
>> ordered, it would be more obvious to simply use 'ordered' and 'unordered'.
> <Raju>
> Though I am ok with this style, but to my knowledge, so far none of the SDP properties are defined this way. The related properties are always defined as prop=value style (e.g. AMR octet-align=0/1, OPUS usedtx=0/1).

For attributes there are: sendrecv / sendonly / recvonly / inactive 
rather than sendrecv={0/1/2/3} or 
direction={sendrecv/sendonly/recvonly/inactive}.

> If unordered is confusing, how about using ordered=0 or 1 and make 1 as the default value?

That would be an improvement. It is similar to boolean callee 
capabilities. ('isfocus' is short for 'isfocus=true'.)

IMO this is mostly an esthetic choice. I'd appreciate hearing what 
others think.

> </Raju>
>
>>
>> Are all combinations of max_retr, max-time, unordered, [ordered]
>> allowed? (There are 8 such combinations, but there are only 6 data
>> channel types in rtcweb-data-protocol.)
>>
>> (The syntax for the dcmap attribute suggests that all combinations are
>> valid.)
>
> <Raju>
> Agreed. We will add text to indicate the combinations should be allowed per rtcweb-data-protocol spec.
> </Raju>

The two excluded ones are those that have both max-retr and max-time 
(ordered or unordered). Does SCTP exclude those combinations? (I don't 
think so.)

Is there a reason to exclude those? Perhaps simply note that webrtc 
doesn't support those two combinations.

>> Also, the syntax forces the fields to be entered in a particular order.
>> That is likely to be a source of errors.
> <Raju>
> Agreed. We will take the suggestion made below on new syntax which allows any order.
> </Raju>
>
>>
>> * Sections 5.1.1.2 & 5.1.1.3
>>
>> the definition 'text = byte-string' has to be wrong. That will suck up
>> the rest of the line, including following ";" separated items. The
>> examples show that you mean a quoted string, but 4566 doesn't have a
>> definition for that.
>
> <Raju>
> Good point. Will change it to quoted string.
> </Raju>
>
>> * Section 5.1.1.4
>>
>> The section title (and usage through the document) calls this parameter
>> 'max_retr", but the syntax defines it as 'maxretr'.
>
> <Raju>
> Will fix it.
> </Raju>
>
>> IMO a separator in this is good, but I would prefer it to be "-" rather
>> than "_".
>
> <Raju>
> Will change it.
> </Raju>
>
>>
>> I think maxretrvalue could be defined using 'integer' from 4566. That is
>> almost the same, but can't start with a zero. It would be good to
>> specify the valid range for this this parameter. That could be specified
>> by reference to rtcweb-data-protocol.
>
> <Raju>
> Will add the reference.
> </Raju>
>
>> * Section 5.1.1.5
>>
>> My comments on 5.1.1.4 apply here as well.
>>
>> Here is a proposal for updating the syntax to deal with all of the
>> above. (Note that I've also changed to use the format I have proposed in
>> rfc4566bis.)
>
> <Raju>
> Thanks. We will take this proposal.
> </Raju>
>
>>      Name: dcmap
>>
>>      Value: dcmap-value
>>
>>      Usage Level: media
>>
>>      Charset Dependent: no
>>
>>      Syntax:
>>
>>         dcmap-value     = dcmap-stream-id
>>                           [ SP dcmap-opt *(";" dcmap-opt) ]
>>         dcmap-opt       = ordering-opt / subprotocol-opt / label-opt
>>                           / maxretr-opt / maxtime-opt
>>
>>         dcmap-stream-id = 1*DIGIT
>>         ordering-opt    = "ordered" / "unordered"
>>         subprotocol-opt = "subprotocol=" quoted-string
>>         label-opt       = "label=" quoted-string
>>         maxretr-opt     = "max-retr=" maxretr-value
>>         maxretr-value   = integer
>>         maxtime-opt     = "max-time=" maxtime-value
>>         maxtime-value   = integer ; milliseconds
>>
>>         quoted-string   = DQUOTE *(quoted-char / escaped-char) DQUOTE
>>         quoted-char     = SP / quoted-visible
>>         quoted-visible  = %21 / %23-24 / %26-7E ; VCHAR without " or %
>>         escaped         = "%" HEXDIG HEXDIG
>>         DQUOTE          = <from-RFC5234>
>>         integer         = <from-RFC5234>
>>
>>      Examples:
>>
>>         a=dcmap:0
>>         a=dcmap:1 subprotocol="BFCP";max-time=60000
>>         a=dcmap:2 subprotocol="MSRP";ordered;label="MSRP"
>>         a=dcmap:3 label="Label 1";unordered;max-retr=5
>>         a=dcmap:4 label="foo%09bar";ordered;max-time=15000;max-retr=3
>>
>> Note that I made subprotocol optional, like the others. Also, I defined
>> quoted-string so that it can only contain SP and visible ascii
>> characters other that " and % as literals. Anything else must be in hex.
>> There are lots of other possibilities for how to do that, but at least
>> that one is clear when you look at it.
>
> <Raju>
> Making subprotocol optional is a good idea. This allows data channels to be negotiated without specifying the subprotocol for middle box use cases that is being discussed at rtcweb http://www.ietf.org/mail-archive/web/rtcweb/current/msg13206.html

> </Raju>
>
>>
>> * Section 5.1.2
>>
>>      Each sub-protocol specific SDP attribute that would normally be used
>>      to negotiate the subprotocol using SDP is replaced with an attribute
>>      of the form "a=dcsa:sctp-port:stream-id original-attribute", ...
>>
>> None of the examples include the sctp-port. I guess this should have
>> said: "a=dcsa:stream-id original-attribute".
>
> <Raju>
> Will fix that.
> </Raju>
>
>>
>> But that highlights the need for of a formal specification of the dcsa
>> attribute. E.g.,
>
> <Raju>
> We will use this syntax.
> </Raju>
>
>>
>>      Name: dcsa
>>
>>      Value: dcsa-value
>>
>>      Usage Level: media
>>
>>      Charset Dependent: no
>>
>>      Syntax:
>>
>>         dcsa-value      = stream-id SP attribute
>>         attribute       = <from-RFC4566>
>>
>>      Example:
>>
>>         a=dcsa:2 accept-types:text/plain
>>
>> * Section 5.2.1
>>
>>      This specification allows simultaneous use of external and internal
>>      negotiation.  However, a single stream is managed using one method at
>>      a time.  Stream ids that are not currently used in SDP can be used
>>      for internal negotiation.  Stream id determination per external
>>      negotiation may not align with DTLS based termination.  This could
>>      cause glare conditions when one side trying to do external
>>      negotiation on a stream id while the other end trying to open data
>>      channel on the same stream id using internal negotiation.  To avoid
>>      these glare conditions this specification recommends that the data
>>      channel stack user always selects stream ids per SDP offer/answer
>>      rule even when internal negotiation is used.  To avoid glare
>>      conditions, it is possible to come up with a different stream id
>>      allocation scheme, but such schemes are outside the scope of this
>>      specification
> <Raju>
>
> The intention of this section is to make it clear that external data channel
> negotiation does not preclude use of inband/internal DCEP. Both can be
> used simultaneously; but care should be taken while allocating stream ids.
> How about the following updated text? Hope this makes it clear.
>
>      This specification allows simultaneous use of external and internal
>      negotiation.  However, a single stream is managed using one method at
>      a time.  Stream ids that are not currently used in SDP can be used
>      for internal negotiation.  Stream id allocation per SDP based external
>      negotiation may not align with DTLS role based allocation.  This could
>      cause glare conditions when one side trying to do external
>      negotiation on a stream id while the other end trying to open data
>      channel on the same stream id using internal negotiation.  To avoid
>      these glare conditions this specification recommends that the data
>      channel stack user always selects stream ids per SDP offer/answer
>      rule even when internal negotiation is used.  To avoid glare
>      conditions, it is possible to come up with a different stream id
>      allocation scheme, but such schemes are outside the scope of this
>      specification.

OK.

	Thanks,
	Paul