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

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

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).
If unordered is confusing, how about using ordered=0 or 1 and make 1 as the default value?

</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>
 
> 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.

</Raju>

Thanks
Raju