Re: [rtcweb] revisiting MTI

John Leslie <> Mon, 15 December 2014 22:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5F8AC1A0461 for <>; Mon, 15 Dec 2014 14:24:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lQx30daS02pY for <>; Mon, 15 Dec 2014 14:24:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 89E981A0252 for <>; Mon, 15 Dec 2014 14:24:30 -0800 (PST)
Received: by (Postfix, from userid 104) id A49CFC94BD; Mon, 15 Dec 2014 17:24:27 -0500 (EST)
Date: Mon, 15 Dec 2014 17:24:27 -0500
From: John Leslie <>
To: Peter Saint-Andre - &yet <>
Message-ID: <20141215222427.GO47023@verdi>
References: <> <> <> <> <> <> <> <> <20141215192409.GN47023@verdi> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Subject: Re: [rtcweb] revisiting MTI
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: Mon, 15 Dec 2014 22:24:32 -0000

Peter Saint-Andre - &yet <> wrote:
> On 12/15/14, 12:24 PM, John Leslie wrote:
>> But we don't obsolete a MTI because "we have much better options":
>> we obsolete a MTI because "nobody's using it anymore".
> Actually we can obsolete an MTI for any reason we please, at long as 
> there's IETF consensus to do so.

   Technically, we "can"...

   In actual practice, though, as long as someone pipes up during
Last-Call saying "These folks are still using that!", we generally
back down from declaring things "Obsolete".

>> We are all trusting, I hope, that VP9, H.265, etc. will "just be
>> used in preference" as soon as two endpoints support them.
>> I don't expect to revisit the MTI selection...
> I do. It's a question of when.

   Well, Peter _is_ younger than me... ;^)

   But this is a sign of a pretty serious disconnect between "old-fogies"
and "young-turks" that I'd like to call attention to:

   Young-Turks want to "do it right" and have a standard ensure the
best possible outcome; old-fogies have been-there, done-that, and
gotten-the-T-shirt -- and things never ended up the way we expected.

   Old-fogies view the world as a continuum where small changes add up
to big progress over time, but too-large changes get mired and wander
in the weeds, tiring everybody and usually leave misguided folks as
the last-men-standing.

   A wise friend once told me that the true problem with democracy is
that the results are unstable: when the electorate wants a change,
the resultant changes goes too far; and walking it back to the middle
"stable-ground" takes too long.

   This is a big part of why I "just don't get the hint" when the
majority disagrees with me -- and I prize the IETF consensus-process
whenever we can get it to work. And it's why I would have been perfectly
happy with H.261 as the Mandatory-To-Implement codec.

   We cannot be effective if we have to turn around next month and say
that VP9 must replace VP8 as MTI or H.265 must replace H.264. Market
forces _really_can_ be trusted to get the better codec(s) used in
preference to whatever we designate as MTI.

>> (That is what we want, right?)
> Not as far as I can see.

   I honestly believe this "compromise" is getting majority approval
because folks are _really_ tired of the MTI discussions.

   But there _are_ young-turks who believe the MTI question is _so_
important that we have to discuss it every IETF-week until we reach

   "Are we there yet?"

John Leslie <>