Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

Martin Thomson <martin.thomson@gmail.com> Thu, 07 November 2013 03:14 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41FD21E80EB for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 19:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.529
X-Spam-Level:
X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhzRNRw1gMSi for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 19:14:36 -0800 (PST)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D650721E80D5 for <rtcweb@ietf.org>; Wed, 6 Nov 2013 19:14:35 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id t61so351756wes.41 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 19:14:34 -0800 (PST)
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=yyQntJOEEsxFXgUg69dqK75yi31LEFicMS1qYcHmfO4=; b=p6zlwS9zh5mtUWLFo24T4QjdZtQiGL1KPg3BOMKpG5AUC3BLve4ppF0MWJPK9Scn1B YfJ2IpxIHal1xdo/HWCwut6M6OLgnK68MdHapw9QE+5OcAAQHfi9HvBMPE/s7qLXFI1H pgzJGcy2Ih6YnyPGVOPj7yDN3wrBVArkr/Jf8DZ+AYQifOn6dIBrY9ubMiIn9jcWEcOM 5NVC4SVSPHQanu5/Iga/4Ai/lQoczK1ZA1QQBN3enh4/kTsL7SYz6Uhf1GxbtwYzsGt8 /+bJulhsvvSoGN4XjNNWN0ssib4QMYFtbB0X6DBzI0T5bkqhBkoLOy2CEpCswt48dU4U h0Qw==
MIME-Version: 1.0
X-Received: by 10.180.109.75 with SMTP id hq11mr628766wib.30.1383794074740; Wed, 06 Nov 2013 19:14:34 -0800 (PST)
Received: by 10.227.202.194 with HTTP; Wed, 6 Nov 2013 19:14:34 -0800 (PST)
In-Reply-To: <527AFF89.3000408@alvestrand.no>
References: <527420FC.3070805@alum.mit.edu> <CAOJ7v-3tMLV0Zs5po_1daWuVaMPtrZK0g+L=kzPnLd0jGtfRXQ@mail.gmail.com> <CAPms+wQMN9+=wy5EJX0LUwZQRrJk2HebbJOADhhGeQpm2jzO8g@mail.gmail.com> <CAOJ7v-0UmZcuYbEzY5Z5WhFw7x_qP2pgntWEY_3byhNWTJqbnA@mail.gmail.com> <CAOJ7v-0c4F9i2Pkc0kjGkhcVDV227EiCH7PdLY--PKmcUMkG2Q@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> <CABkgnnUtjB3Up50nKpALFoG9i47MCXME-98Cju0XTp5r_7z57Q@mail.gmail.com> <527AFF89.3000408@alvestrand.no>
Date: Wed, 6 Nov 2013 19:14:34 -0800
Message-ID: <CABkgnnWpVr6QL-JEAL=gGyVDNZtTqUdhfcRqYGb6qqvLc-J2tw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2013 03:14:36 -0000

On 6 November 2013 18:48, Harald Alvestrand <harald@alvestrand.no> wrote:
> 2) X MUST offer A (only) if no particular constraint is set, but MUST
> offer A, B and C if some (to-be-defined) constraint is set.
...
>
> I like option 2, for the reasons stated (deterministic, seems to do the
> job).

Yes, I didn't precisely describe the issue, but the discussion and
disagreement was focused on the sub-options of that point.

I'm less concerned about determinism here.  It's SDP already, suck it
up.  The key point of determinism that I consider relevant here is
that A remains in the set (if possible).  I'm perfectly comfortable
with additional codecs appearing in the list.

I don't see a need for constraints, in fact, given that there is no
need to convey the extra options to the answerer.  SDP is mutable.  In
that sense, having all the options enumerated, every time, is actually
highly desirable.  (Note that as a browser vendor you can unilaterally
determine that B and C are no longer "viable options" and then not
include them.)