Re: [MMUSIC] AD Review: draft-ietf-mmusic-t140-usage-data-channel

[Gunnar Hellström <[e-mail]>]

Hi,

Please see comment on the priority and label parameters below.

Den 2020-01-24 kl. 12:30, skrev Christer Holmberg:

Hi Adam,

Thank You for the review!

I have removed the comments where I agree and will modify as suggested without further discussion. Please see inline for the rest.

    ---------------------------------------------------------------------------


    §4.1:

     >>  The offerer and answerer MAY include the priority attribute parameter
     >>  and the label attribute parameter in the 'dcmap' attribute value.  If
     >>  the offerer includes a label attribute parameter, the answerer MUST
     >>  NOT change the value in the answer.
    >
    > This should be explicit about whether the answerer is allowed to add a label
    > if the offerer did not. It should also be clear about whether the
    > priority is allowed to be different in the answer than in the offer.

If not explicitly included, the default value is 256, so there will always be a value (implicit or explicit). I guess we can point that out.

Perhaps something like:

OLD:

   The offerer and answerer MAY include the priority attribute parameter
   and the label attribute parameter in the 'dcmap' attribute value.  If
   the offerer includes a label attribute parameter, the answerer MUST
   NOT change the value in the answer.

NEW:

   The offerer and answerer MAY include the priority attribute parameter
   and the label attribute parameter in the 'dcmap' attribute value.  As
   defined in [I-D.ietf-mmusic-data-channel-sdpneg], in absence of the
   attribute parameter an attribute parameter value of 256 is assumed.
   The answerer MUST not change the value in the answer.

This is not clear enough. But the intention is to express exactly the same rules as specified in sdpneg.

So, it would then be best to just refer to sdpneg according to this alternative proposed

NEW wording alternative 1:

The offerer and answerer MAY include the priority attribute parameter
   and the label attribute parameter in the 'dcmap' attribute value as
   specified in [I-D.ietf-mmusic-data-channel-sdpneg].


Alternatively, if you want to spell it out, I suggest the following complete description:
NEW wording alternative 2.

   The offerer and answerer MAY include the priority attribute parameter
   and the label attribute parameter in the 'dcmap' attribute value.  As
   defined in [I-D.ietf-mmusic-data-channel-sdpneg], in absence of the
   priority attribute parameter a priority attribute parameter value of 256 is assumed.
   In the absence of the label attribute parameter a label attribute parameter value of the empty string is assumed.
   The answerer MUST not change the values in the answer.

I suggest to use alternative 1.

Regards

Gunnar




    ---------------------------------------------------------------------------

    §4.1:

    >>  The offerer and answerer MUST NOT include the max-retr and max-time
    >>  attribute parameters in the 'dcmap' attribute.
    >
    > Ideally, this would include text that indicates what a recipient of such
    > messages would do (with the obvious choices being ignoring them or treating
    > them as an error). I suggest the easiest thing to specify is that recipients
    > of either attribute for a T.140 section MUST ignore them.

Just to note:

- The draft defines that the T.140 data channel is reliable.
- max-retr and max-time are used to indicate that a data channel is partially reliable, so there would be a conflict.

So, the question is whether it is ok to just ignore, or whether it is a protocol error and the m- line therefore should be rejected.

If *both* attribute parameters are included in an offer (which would also create a conflict), draft-channel-sdpneg says that the offer must be rejected.

    ---------------------------------------------------------------------------

    §4.2:

     >>  An offerer and answerer MAY, in each offer and answer, include one or
     >>  more SDP 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in
    >
    > Since this appears to be restating behavior defined elsewhere, consider
    > changing the normative "MAY" to a simple English "may".

I suggest to use "can", because some reviewers don't want to use the normative words unless in capital letters.

    ---------------------------------------------------------------------------

    Regards.

Christer




_______________________________________________
mmusic mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic


--

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[e-mail]<mailto:[e-mail]>
[phone]