Subject: Re: [MMUSIC] rfc5888: Multigroup management

From: Bo Burman <[email-masked]>
Date: Wed, 13 Jul 2016 16:53:12 +0000

Hi,

Apologies for the delay in responding.

I still don't really understand what you are trying to do, or what you think is not possible today?

In your original mail you said that the problem occurs when there are several groups with the same semantic. To me, that seems per definition to result in (and be identical to) a single group containing the union of mid in all sub-groups.

Why is that not OK? If there would exist a need to recognize and separate out the sub-groups from the offer in the answer, the used (common) semantic could not really be sufficient for your grouping purposes, could it? One solution could thus be to introduce another sub-grouping semantic, in addition to the "union" semantic, which is something that 5888 already supports by simply allowing for multiple groupings. How to set this additional sub-grouping in the offer depends on your need for separation in the answer.

You can obviously look to the offer to see what groups and media that are offered, and to the answer to know what groups and medias that were accepted, even per group. Any media that were offered but not accepted in the answer is not included there, so you cannot get any information about non-accepted media from just looking the answer. Do you somehow want a track-record of non-accepted media and groups in the answer?

Regards,
/Bo

> -----Original Message-----
> From: Santiago Carot Nemesio [mailto:[email-masked]]
> Sent: den 21 juni 2016 10:58
> To: Bo Burman <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [MMUSIC] rfc5888: Multigroup management
> 
> Hi,
> 
> thanks a lot for your reply, see comments below.
> 
> 2016-06-20 15:39 GMT+02:00 Bo Burman <[email-masked]>:
> > Hi,
> >
> > I think this list should be capable to answer your question.
> >
> > It seems to me that you in general need to consider the semantics of
> > the grouping. Looking to your example below, I don't really understand
> > what you try to express with a=group:LS 1 2 3 a=group:LS 1 2
> > Obviously, if media lines with mid 1, 2, and 3 are lip-synchronized (LS), so are mid 1 and 2, since it is a true subset of the
> first group. The second "a=" line is redundant even to start with. As such, just removing or disregarding the resulting
> repeated line in the answer in your example does not cause any concern or ambiguity.
> 
> This is not a real case at all, I just wanted to raise awareness about this concern, so that's just a simple example of
> ambiguity in case any peer needs to distinguis this case, So the semantic regarding of the grouping of medias is
> application dependant you can not make assumptions about what application do or even what they are trying to do, but
> from the implementation point of view perhaps you need to distinguish what group was offered with what medias and
> what medias were accepted for any specific group.
> 
> So I suspects that just as it is right now this is not possible.
> Please, fixme if I'm wrong or I'm missing something.
> 
> Thanks