Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-rfc8843bis-04: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Wed, Sep 01, 2021 at 09:48:12AM +0000, Christer Holmberg wrote:
> Hi Benjamin,
> 
> I will not reply to your input on Lars' comments, as there are no further issues.
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>  
[...]
>  
> >> Section 9.3.1.2
> >> 
> >>>   In an initial BUNDLE offer, if the suggested offerer-tagged "m="
> >>>   section contained an SDP 'rtcp-mux-only' attribute, the "m=" section
> >>>   was for RTP-based media; thus, the answerer does not accept the "m="
> >>>   section in the created BUNDLE group, and the answerer MUST move the
> >>>   "m=" section out of the BUNDLE group (Section 7.3.2); include the
> >>>   attribute in the moved "m=" section and enable RTP/RTCP multiplexing
> >>>   for the media associated with the "m=" section; or reject the "m="
> >>>   section (Section 7.3.3).
> >>>
> >>> I'm having a hard time parsing this (long!) sentence.  The first 
> >>> semicolon seems to be used to join related sentences, but the latter 
> >>> two seem to be acting as list separators (where the list members have internal commas), and that's a little jarring to have the different semicolon uses in the same sentence.  
> >>> Additionally, if I keep that parsing, this seems to say that all "m=" sessions for RTP-based media cannot be included in the BUNDLE group by the answerer, which is quite surprising.
> >>> If we applied s/thus,/thus, if/ and s/, and/,/, then this parsing would make more sense to me, but I don't know if that would provide the intended semantics.
> >> 
> >> What about:
> >> 
> >>    "In an initial BUNDLE offer, if the suggested offerer-tagged "m="
> >>    section contained an SDP 'rtcp-mux-only' attribute, the "m=" section
> >>    was for RTP-based media. If the answerer does not accept the "m="
> >>    section in the created BUNDLE group, and moves the
> >>    "m=" section out of the BUNDLE group (Section 7.3.2), the answerer
> >>    MUST include the attribute in the moved "m=" section and enable RTP/RTCP
> >>    multiplexing for the media associated with the "m=" section. If the answerer
> >>    rejects the "m=" section (Section 7.3.3) the answerer MUST NOT include
> >>    the attribute."
> >
> > That seems to make sense; thanks!
> > This does allow the answere to accept the "m=" section in the BUNDLE group, which may or may not have been
> > allowed by the old text.  I assume you will know if that's okay.
> 
> I think the old text also allowed that, but I agree that the lack of "and" before "the answerer does not accept" might make that unclear.
> 
> Or, did you refer to something else?

That was it.  (I didn't know what the old text was trying to say, so
couldn't make claims about whether this was a change in behavior.)

Thanks again,

Ben