Re: [rtcweb] revisiting MTI

Daniel-Constantin Mierla <miconda@gmail.com> Mon, 15 December 2014 22:53 UTC

Return-Path: <miconda@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F451A1F04 for <rtcweb@ietfa.amsl.com>; Mon, 15 Dec 2014 14:53:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzQ0XUSyfSBl for <rtcweb@ietfa.amsl.com>; Mon, 15 Dec 2014 14:53:30 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C631A1F02 for <rtcweb@ietf.org>; Mon, 15 Dec 2014 14:53:25 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id x12so15791859wgg.38 for <rtcweb@ietf.org>; Mon, 15 Dec 2014 14:53:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cPw/gAvV1ZANR0zR1IeQBPbrbKU5O7Oeqzqjn8q5wvM=; b=F+KqF3HUyoNzRIfTSy5YxuLDbPSJrdP6PnYCLfSxBhctvfDxcIk00RTCxwVsL/iFra 3iV/1L7MqZs/Axx9FIjf24W16Hrytk4HFZbYkIsULmim8v18ryMiU/UWBxO6t9DfxMJO 7JgCgYkoPDtdGeWpZhQDVNssekjC7LK1OFHLLlOa40MxcGB9c5VF7/bOgc9Q/EEwIpR7 Kp2vGzDwdWLrYWIfw5feYGyL9ziyTXtho5RcnREdov71BZND8zauT3bCLMfFEw0QzcNj 791M2imPEx3d4ga6bTpA/zoxgzJLp9k2RaKI6hVRlSqM11F6GZb+n6ZKkmsaucFb7VWi IRUA==
X-Received: by 10.180.221.201 with SMTP id qg9mr35447236wic.29.1418684004297; Mon, 15 Dec 2014 14:53:24 -0800 (PST)
Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id n5sm14887082wic.6.2014.12.15.14.53.22 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 14:53:23 -0800 (PST)
Message-ID: <548F6661.3020407@gmail.com>
Date: Mon, 15 Dec 2014 23:53:21 +0100
From: Daniel-Constantin Mierla <miconda@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, Ted Hardie <ted.ietf@gmail.com>
References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <CALiegfmH6hWp6nuArv8YyPcgq6SCd9x-dU0cxAaKJLrmb0hc_g@mail.gmail.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <CALiegfkMUzQVOKk433d4TZtvenQWQwChYF2vc7HMED2s2wHZ5Q@mail.gmail.com> <B52D8E91-5D96-4960-8DDE-DD970014DE5D@ieca.com> <CALiegfnRvgDK4EnDBSn76YKktWLMjShsQRP6byCRqZC07WaVqw@mail.gmail.com> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <CA+9kkMDNhRdbzCs9vrqDeD4CoWWK1xS5o0z3jL0DvNpDuLfCPw@mail.gmail.com> <548F5E22.2040605@andyet.net>
In-Reply-To: <548F5E22.2040605@andyet.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NBGma5lC0YrtsbJEChnZucMS9k8
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] revisiting MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: miconda@gmail.com
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: Mon, 15 Dec 2014 22:53:32 -0000

On 15/12/14 23:18, Peter Saint-Andre - &yet wrote:
> On 12/15/14, 3:03 PM, Ted Hardie wrote:
>> On Mon, Dec 15, 2014 at 1:37 PM, Peter Saint-Andre - &yet
>> <peter@andyet.net <mailto:peter@andyet.net>> wrote:
>>
>>     Not as far as I can see.
>>
>>     Ten years ago if we'd had this discussion, H.261 might have been
>>     MTI. Ten years from now, H.264 will seem ancient, too.
>>
>>     I fully expect that someone in the IETF (perhaps not us) will
>>     revisit the MTI decision once we have better alternatives.
>>
>>     Peter
>>
>>
>> ​The nice thing is that our current model allows us to have nice things
>> right away; as soon as they are in common, they may be selected by
>> negotiation.  What the MTI gives us is a way to avoid interoperability
>> failure.  So the key question isn't really "Is there something better?"
>> but "Is the current MTI so bad that folks aren't willing to use it, so
>> we are once again at risk of interoperability failure?".
>
> Some folks have expressed a concern that whatever we choose as an MTI
> codec now must always be an MTI codec. I'm trying to allay that
> concern by saying that yes, indeed, we can change our MTI codec(s) in
> the future if we please (naturally, keeping interoperability in mind
> at that future time).
>
Perhaps that concern was created by the phrasing of the current
proposal/draft that MTI is not going to be revisited for browsers.

On the other hand, if this is going to be adopted (not to be
misinterpreted, I don't agree with this proposal), is a quite "ugly"
compromise, probably the most unclean rough consensus so far, nothing
that is backed up with technical merits. I find it more fair to make it
explicit that this was a "last resort" compromise, with a trigger for
revisiting. It will accelerate the process for a RF codec, when having a
clear benefit out of it -- what interest would be to push money on a new
RF codec when you have to implement a paid one anyhow.

Moreover, IETF has an affinity of stating backward compatibility (see
RFC3261/SIP doing that for RFC2543), there will be always enough people
asking for that to get in the same kind of debate like here.

Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda