Re: [rtcweb] Alternative decision process in RTCWeb

Basil Mohamed Gohar <> Fri, 29 November 2013 20:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 261B31ADDAC for <>; Fri, 29 Nov 2013 12:41:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XRVKL9TsDzrW for <>; Fri, 29 Nov 2013 12:41:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E3CA31ADBCA for <>; Fri, 29 Nov 2013 12:41:37 -0800 (PST)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id D7B4265A278 for <>; Fri, 29 Nov 2013 15:41:35 -0500 (EST)
Message-ID: <>
Date: Fri, 29 Nov 2013 15:41:24 -0500
From: Basil Mohamed Gohar <>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <> <> <> <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz>
In-Reply-To: <20131129060936.GV3245@audi.shelbyville.oz>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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: Fri, 29 Nov 2013 20:41:40 -0000

On 11/29/2013 01:09 AM, Ron wrote:
> On Thu, Nov 28, 2013 at 02:39:49PM -0800, Bernard Aboba wrote:
>>> On Nov 28, 2013, at 2:27 PM, Michael Richardson <> wrote:
>>> That tells me that the participants are not willing to live with losing and
>>> move on, and so no voting process will work either.
>> [BA] The participants aren't willing to live with losing for business or
>> legal reasons that aren't within the jurisdiction of an IETF WG.  As an
>> example,  would an open source product that requires source code to be
>> provided without a license fee put that aside because IETF RTCWEB has agreed
>> upon H.264 as MTI?  Similarly, would a vendor who is concerned about
>> potential liability from incorporating VP8 put that concern aside because the
>> IETF RTCWEB WG has decided to make VP8 MTI?  
> I think EKR said this more succinctly with:
>  "it's important to understand that in in this case, many people more
>   don't want X than do want Y."
> And I think you both have clearly identified the problem, and why voting
> is clearly not a solution to it.
> The blocking issue is that many people have valid reasons why they _can't_
> deploy one or more of the possible choices.  You can't possibly solve that
> by taking a poll of what the majority of people would _prefer_, ignoring
> all other people's blocking constraints.
> However I think we can still resolve this by following normal consensus
> procedures, and walking our way up from the least troublesome options to
> the most, and seeing at what point consensus actually breaks down.
>  1. Do we want an MTI codec?
>    It's generally accepted there is consensus the answer to this is Yes.
>    We also have a list of codecs that we could possibly choose from.
>    It also seems generally accepted that IPR trouble is the least
>    negotiable  problem that is at the heart of many objections.
>  So let's start where that problem is the smallest, at the very bottom:
>  2. Can anybody show a sustainable objection for why we _can't_ use H.261.
>    If they can, we're probably doomed.  If they can't we have an initial
>    choice for MTI.
>  3. Can anybody show a sustainable objection for why <alternative>
>     can't replace H.261 as the MTI codec?
>    If they can, lather rinse repeat through the other alternatives.
>    If they can't, we have a new baseline to ask this question of
>    for the remaining alternatives.
> Yes, this may take some time (but surely less than we've already spent),
> but it clearly separates the question of what people _can't_ do, from
> what they would prefer to do if they had their druthers.
> We probably won't get the best possible codec as the MTI fallback,
> but we probably will get a decision that isn't fundamentally doomed.
> And that's fine, because people will still get their preferred codec
> through runtime negotiation if they use an implementation which does
> accept the risk of supporting it - and the safe interop fallback if
> it doesn't.
> Why would this one simple procedure not work to resolve the deadlock?
>   Ron

This is as good or better than anything else I've seen mentioned so far.
 Definitely a +1 from me, not that we're voting or anything...;)

Libre Video