Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel

[Christian Groves <[e-mail]>]

Hello Juergen,

Thanks for your reply. Please see below.

Regards, Christian

..snip..
>> Hello
>>
>> I had a chance to look over the latest draft in more details. Some 
>> comments/questions:
>>
>> 5.1.1.1: To enforce the text about dcmap-opt the ABNF could be updated:
>>    dcmap-opt       = ordering-opt / subprotocol-opt / label-opt
>>                      / ( maxretr-opt / maxtime-opt )
>
> [Juergen] Actually, I am not sure if this would formally prevent 
> maxretr-opt and maxtime-opt  from both being present simultaneously, 
> as we would still have
>     dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ]
> (allowing an arbitrary number of "dcmap-opt").
> My understanding of RFC 5234's definition of "alternation" has so far 
> been that
>      dcmap-opt = ordering-opt / subprotocol-opt / label-opt / 
> maxretr-opt / maxtime-opt
> and
>     dcmap-opt = ordering-opt / subprotocol-opt / label-opt / ( 
> maxretr-opt / maxtime-opt )
> are actually equivalent.
> Right now don't see a "compact" way of strengthening the actual ABNF 
> rules without having to list all possible parameter combinations and 
> permutations.
[CNG] Yes you're right. In other protocols this has been covered by an 
"At most once" statement on the ABNF. The ( ) would ensure that only one 
would be used.

>
> ..snip..
>>
>>
>> 5.1.1.4. max-retr parameter: This draft seems to use the absence of 
>> the "max-retr" parameter to indicate the use of a reliable channel It 
>> also indicates a default value of "unbounded". 
>> draft-ietf-rtcweb-data-protocol indicates "For reliable Data Channels 
>> this field MUST be set to 0 on the sending side and MUST be ignored 
>> on the receiving side."
>> To better align with the data channel protocol i'd suggest changing 
>> the of 5.1.1.4 to indicate that "The max-retr parameter is optional 
>> with the default value equal to 0 indicating that no retramsmission 
>> is used.
>
> [Juergen] Our current intention is that the absence of "max-retr" and 
> "max-time" in the a=dcmap attribute value would indicate a reliable 
> data channel, similar as channel types "DATA_CHANNEL_RELIABLE" and 
> "DATA_CHANNEL_RELIABLE_UNORDERED" in DCEP's DATA_CHANNEL_OPEN message.
> And that "max-retr=0" would actually indicate a partial reliable data 
> channel with the maximal number of retransmissions set to zero 
> (similar to DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT(_UNORDERED) and 
> "Reliability Parameter" = 0 in the DATA_CHANNEL_OPEN message).
> If we kept this semantic of "max-retr=0", then a default value equal 
> to 0 would result in an a=dcmap attribute without "max-retr" parameter 
> actually indicating a correspondingly partial reliable data channel, 
> such that then the data channel would actually not be reliable as far 
> as I understand.
[CNG] OK my point was that the behaviour should be defined better and 
your comment below covers it.

As an aside, is there a reason why the draft doesn't follow the 
parameter structure of I-D.ietf-rtcweb-data-channel if its trying to 
emulate the information? i.e. a channel type and a reliability 
parameter. With these two parameters it's clear what type of data 
channel is being asked for rather than relying on the absence of 
parameters and also avoids having to specify valid combinations. It 
would allow support of new types (via the IANA registry) without new 
parameters.

>
> ..snip..
>>
>> 5.1.1.5 similar to 5.1.1.4 I think it would be better to talk about 
>> specific behaviour when the parameter is omitted rather than saying 
>> "unbounded".
>
> [Juergen] Agree. We should make this case more explicit and e.g. refer 
> to RFC 4960 and say:
> "The max-time parameter is optional. If the max-time parameter is not 
> present, then the generic SCTP retransmission timing rules apply as 
> specified in [RFC 4960]."
>
> Similarly in 5.1.1.4; there we could e.g. say:
> "The max-retr parameter is optional. If the max-retr parameter is not 
> present, then the maximal number of retransmissions is determined as 
> per the generic SCTP retransmission rules as specified in [RFC 4960]."
>
> Would you agree to this?
[CNG] Yes
>
>>
..snip..