Re: [rtcweb] Proposed Video Selection Process

Adam Roach <> Thu, 21 November 2013 18:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 735B11AE0A0 for <>; Thu, 21 Nov 2013 10:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w1osvW1-SI96 for <>; Thu, 21 Nov 2013 10:59:08 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 677651AE001 for <>; Thu, 21 Nov 2013 10:59:08 -0800 (PST)
Received: from Orochi.local ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id rALIwuE8073692 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 21 Nov 2013 12:58:58 -0600 (CST) (envelope-from
Message-ID: <>
Date: Thu, 21 Nov 2013 10:58:52 -0800
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Magnus Westerlund <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] Proposed Video Selection Process
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Nov 2013 18:59:09 -0000

On 11/21/13 08:51, Magnus Westerlund wrote:
> We (WG chairs) are proposing that the working group consent to a method
> that will establish an MTI, even if the MTI chosen does not have rough
> consensus.

Although this is phrased very carefully, I think this email 
inadvertently glosses over the fact that this is a formal call for 
consensus around the proposed approach. I also think you need to be 
crystal clear -- and I'm going to borrow RFC 3929's language here -- 
"that the working group's consensus to use [this specific] method stands 
in for the working group's consensus on the technical issue."

I wanted to point this out because it would be very easy to accidentally 
read the email as an announcement for the way the codec will be 
selected, rather than a call for consensus around a proposed approach.