Re: [MMUSIC] Simulcast worries: Fallback in the a=rid language

[Harald Alvestrand <[e-mail]>]

On 10/22/2015 12:23 AM, Martin Thomson wrote:
> On 21 October 2015 at 15:05, Peter Thatcher <[e-mail]> wrote:
>> But if you have max-goats and max-dogs and max-cats and the answerer
>> supports max-dogs but not max-goats or max-cats,  how can it structure it to
>> offer all the combinations of what might work and what might not?
> Yes, combinatorial explosion ensues.
>
> My view is that we aren't likely to add enough of these extensions
> that we will ever reach that explosion point.
>
> And if enough time lapses between introduction of different things,
> you can start to make assumptions about things, and do things like
> bundle max-dogs and max-cats together.  Sure, the guy who understands
> (not supports) only max-dogs falls back to the baseline, but as long
> as you have a baseline you don't suffer too badly.
>
> In practice, I think that this will only create a modest amount of
> pressure not to extend.  I can't actually think of a downside to that.
>
> BTW, this is a repeat of a similar discussion we had in HTTP.  There,
> we settled on having parameters be ignored if not supported.  I don't
> think that's feasible in this context because things like limits are
> important.
The logic is in fact different for the two directions.

If I tell someone I'm going to stick to a limit they don't know about
(send), no harm will come from ignoring the parameter - I can stick to
the limit anyway.

If I tell someone I can't take more than X from them (recv), it's
dangerous if they ignore it, because they can overrun my limitations
through ignorance.

That tells me that:

a) we need to think more about this
b) sendrecv is a bad idea





-- 
Surveillance is pervasive. Go Dark.