Re: [rtcweb] Alternative decision process in RTCWeb

cowwoc <> Fri, 29 November 2013 15:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1CC0F1ADEA3 for <>; Fri, 29 Nov 2013 07:55:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YrCVtx0c0sJx for <>; Fri, 29 Nov 2013 07:55:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E6B491AE002 for <>; Fri, 29 Nov 2013 07:55:23 -0800 (PST)
Received: by with SMTP id tp5so16048327ieb.22 for <>; Fri, 29 Nov 2013 07:55:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gRoEWRkekSR35LyXEKiIbl+TDatXx2s470ywEl2QO8U=; b=CiISa4xao2qhEB1j8Klz2Y89drnFVSL2M8SGJ4rS4BHZYaN6892fIguwP21W1w0o86 +OMTyO/tBh2cN0Pf+I/+uwLkpeZleXkWWta0OIN2SE+he2nOCFfuxQZB/0SEUslReyyO 7eUEVk+dpYmF1YCWziBNFtombWagaOuLM6naa7K/FPJwmjb5L8CTpKNeL1vRYONmiJro F4Wk1MiBJN2ucwRzB3z00PYZ50Y3YKKauEkmh46KO3cKJmixDnVshPpSEkQ+Alv3hvcj dMm7ri+nQJNTVqpwE/bV/UeS0cJ1f87PLEdkWRfMjm1QGr+cqaoshG8XzfLq4qnSpiFg 4bNQ==
X-Gm-Message-State: ALoCoQnYYId0uB2VKwZaPt4pBVAy7s0T1MKOrREqmkKX/JiFvto9gVgiW+Mk7p8shhWA4EuQywUW
X-Received: by with SMTP id e10mr6844343igy.58.1385740522637; Fri, 29 Nov 2013 07:55:22 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id p14sm50845121igr.7.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 07:55:21 -0800 (PST)
Message-ID: <>
Date: Fri, 29 Nov 2013 10:54:35 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <> <> <> <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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 15:55:31 -0000

I'm in favor of this approach, with a fallback to voting if that fails, 
with a fallback to "No MTI" if that fails.


On 29/11/2013 3:30 AM, Maik Merten wrote:
> I very much agree with Ron here. Given that both H.264 and VP8 seem to 
> not be universally deployable by all participants in all scenarios I 
> guess many will agree that reaching consensus on one of those may not 
> be realistic.
> So it appears that we need $fallback (to be later used in something 
> like "all entities MUST implement $fallback" or "all entities MUST 
> implement at least two of {H.264, VP8, $fallback}" etc.). As far as I 
> can see following codecs have been mentioned as possible candidates 
> for $fallback:
> H.261, MPEG-1 Part 2, H.263, Theora (sorted by age and performance)
> I don't remember seeing an exploratory discussion to determine what 
> (if any) codecs are considered to have "acceptable risk" (this is 
> different from "no risk", which may not be achievable). However, it 
> may take some time for each participant to make their own risk 
> assessment. Thus I very much like Ron's proposal of starting 
> discussion with the codec with the lowest perceived IPR risk and 
> trying to move to higher performance levels until substantial 
> indication shows up that the next step brings "unacceptable risk".
> Maik
> Am 29.11.2013 07:09, schrieb Ron:
>> 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
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list