Re: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)

[Christer Holmberg <[e-mail]>]

Hi,

>>>>>>>   [Section 7.3.1] as the answerer tagged "m=" section.  In the answer
>>>>>>>   the answerer BUNDLE-tag indicates the answerer tagged "m=" section.
>>>>>>>
>>>>>>> I'm having trouble reading this paragraph. How do you select an m= section that correspond to the selected m= section.
>>>>>>
>>>>>> The n:th m- line in an answer corresponds to the n:th m- line in the offer.
>>>>>>
>>>>>> There was some discussion about the terminology, and “corresponds” was the outcome.
>>>>>> 
>>>>>> I did find a small nit in the text, though:
>>>>>> 
>>>>>> s/”section in that”/”section that”
>>>>>
>>>>> My point is that this paragraph just is too hard to read. My problem isn't corresponds, it's
>>>>> "select" and "selected" together. Can you rewrite it so that it's clearer. Maybe just indicating
>>>>> that one is is the offer and one is in the answer?
>>>>
>>>> What about:
>>>>
>>>>   The answerer MUST select the "m=" section *in the answer* that corresponds to the
>>>>   selected offerer tagged "m=" section in the corresponding offer
>>>>   [Section 7.3.1] as the answerer tagged "m=" section.  In the answer
>>>>   the answerer BUNDLE-tag indicates the answerer tagged "m=" section.
>>>
>>> This seems clearer, but I'm not sure what "selected" is doing in "selected offerer tagged". Can you explain?
>>
>> The answerer first selects the offer tagged "m=" section, as described in section 7.3.1. After that, it selects 
>> the corresponding "m=" section in the answer as the answerer tagged "m=" section.
>
> Well, the use of "selected" here in both cases is super-confusing.
>
> I think what would be easiest would simply be to merge these two sections. I.e., the answerer determines (it actually doesn't "select") 
> the tagged m= section and then places it in its own answer.

"Selected" is a terminology we spent quite a bit of time discussing back in the days, and it is used throughout the document. 

But, below is a suggestion on to merge the sections, which hopefully will be more clear:


7.3.1.  Answerer Selection of tagged 'm=' sections

   When the answerer selects the offerer tagged "m=" section, it first
   checks the suggested offerer tagged "m=" section [Section 7.2.1].
   The answerer MUST check whether the "m=" section fulfils the
   following criteria:

   o  The answerer will not move the "m=" section out of the BUNDLE
      group [Section 7.3.3]; and

   o  The answerer will not reject the "m=" section [Section 7.3.4]; and

   o  The "m=" section does not contain a zero port value.

   If all of the criteria above are fulfilled, the answerer MUST select
   the "m=" section as the offerer tagged "m=" section. In addition, in
   the corresponding answer, the answerer MUST select the "m=" section that
   corresponds to the offerer tagged "m=" section as the answerer 
   tagged "m=" section. In the answer the answerer BUNDLE-tag indicates the 
   answerer tagged "m=" section.

   If one or more of the criteria are not fulfilled, the answerer MUST
   pick the next identification-tag in the identification-tag list in
   the offer, and perform the same criteria check for the "m=" section
   indicated by that identification-tag.  If there are no more
   identification-tags in the identification-tag list, the answerer MUST
   NOT create the BUNDLE group.  Unless the answerer rejects the whole
   offer, the answerer MUST apply the answerer procedures for moving an
   "m=" section out of a BUNDLE group [Section 7.3.3] or rejecting an
   "m=" section within a BUNDLE group [Section 7.3.4] to every bundled
   "m=" section in the offer when creating the answer.

   [Section 17.1] shows an example of an offerer BUNDLE address:port
   selection.

   [Section 7.3.5] and [Section 17.1] show an example of an answerer
   tagged "m=" section selection.

Regards,

Christer