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

Martin Thomson <martin.thomson@gmail.com> Wed, 21 October 2015 22:23 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3EF1B32AD for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 15:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C7NZ3EdkKRU for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 15:23:23 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA071B32AC for <mmusic@ietf.org>; Wed, 21 Oct 2015 15:23:22 -0700 (PDT)
Received: by ykaz22 with SMTP id z22so65263736yka.2 for <mmusic@ietf.org>; Wed, 21 Oct 2015 15:23:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LMuOkXbp2YykpSjvfcUYYmw3CGH6OgmqM6qxz8ozx8o=; b=W4ZMIibK7yKym/rbXWCBeZ8UgKky7OXS9EKeEo/nBcTEQDxj7lpTTkUGrWad9qgblH yCVIR/gllhvA1ovFxcttL8ZInXOPwJU4l9GJsV9Y0c5mAzIjQGKETA3UuIzbKri7vQe9 TiI6+MjQNxxkmeTNLd4Vm2uORsZQkW4HcaIBHEGnnA5I+M/YiJ3ey3TMTEVpYtMI9TMP WBPSSq9jaCjsevvZFf8nwreiR4nNTV5K144UYRQxMttVd6GsDvofgBpIsf21SSkZE5+P vok4v+yPUUDkBS+IbPTMKMmNqBC19ge/iHtlQYQl/8ivJIAVJjiivIDgPYE7qGOEUMBE jlLg==
MIME-Version: 1.0
X-Received: by 10.129.55.209 with SMTP id e200mr9595624ywa.120.1445466201521; Wed, 21 Oct 2015 15:23:21 -0700 (PDT)
Received: by 10.129.132.145 with HTTP; Wed, 21 Oct 2015 15:23:21 -0700 (PDT)
In-Reply-To: <CAJrXDUHzMPibW0pzGqabeuGo0aNsMwPg+RGREj4T+PbZLnhCRQ@mail.gmail.com>
References: <562799B8.9080609@alvestrand.no> <CABkgnnXsd0kr0T43Eu2CeC9Rg9Z9w-QBKw2L7aMub_oVyJWL3g@mail.gmail.com> <CAJrXDUHzMPibW0pzGqabeuGo0aNsMwPg+RGREj4T+PbZLnhCRQ@mail.gmail.com>
Date: Wed, 21 Oct 2015 15:23:21 -0700
Message-ID: <CABkgnnXPmubr_yCAuVzdYEXutDUrNrPYdTkRfzN7jBH9Fy1YJA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/JW7SOVVMQkXXeEW-_eS6A1FDlGY>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Simulcast worries: Fallback in the a=rid language
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2015 22:23:25 -0000

On 21 October 2015 at 15:05, Peter Thatcher <pthatcher@google.com> 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.