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

[Christer Holmberg <[e-mail]>]

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