Re: [rtcweb] confirming sense of the room: mti codec

Adam Roach <adam@nostrum.com> Fri, 12 December 2014 14:45 UTC

Return-Path: <adam@nostrum.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 0AEC61ACD8D for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 06:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 YUwk_uy_W4NP for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 06:45:21 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59201ACD1A for <rtcweb@ietf.org>; Fri, 12 Dec 2014 06:45:21 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBCEjALO025034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2014 08:45:11 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Message-ID: <548AFF76.1010003@nostrum.com>
Date: Fri, 12 Dec 2014 08:45:10 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>, Iñaki Ba z Castillo <ibc@aliax.net>, Sean Turner <turners@ieca.com>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <CALiegfmuO6m=FfSQ9b9i_cu+_0eUSbxTtMh0_9kNCk9BLf-iuA@mail.gmail.com> <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net>
In-Reply-To: <548AFB1A.1040405@andyet.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/u7YaNJarl3ac7kqUGVeiuz4sKfU
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Fri, 12 Dec 2014 14:45:26 -0000

On 12/12/14 08:26, Peter Saint-Andre - &yet wrote:
> On 12/12/14, 4:31 AM, "Martin J. Dürst" wrote:
>> On 2014/12/12 20:14, Iñaki Baz Castillo wrote:
>>> Question: If the World gets a new "Opus for video" codec, will this WG
>>> make it MTI for WebRTC at the same time it removes both VP8 and H264
>>> from the list of MTI codecs?
>>
>> 1) This is a good question. I wish I knew :-).
>>
>> 2) This is conditional on a hypothetical event in the future ("Opus for
>> video"). At that point, this WG may no longer exist. Or it may do
>> whatever it pleases (as long as it is within its charter).
>
> Sure, but that can all happen through normal IETF processes (form a 
> new WG, write an I-D that obsoletes this dual-MTI solution, etc.).
>
> IMHO it would still be good to address some aspects of the various 
> possible scenarios...

I think that the future-looking clause is one of the wartiest parts of 
this proposal. On the other hand, it's the one thing that makes it 
different than things we've considered in the past, and is clearly a key 
part of what allowed it to gather the support that it has so far. So: 
ugly, necessary, and sufficient.

Given that it's sufficient to gain the current level of support, the 
need for change is unclear.

Given that it's necessary, we can't remove it, or the whole thing falls 
apart.

And, given that it's ugly, making it more expansive would only make the 
proposal qualitatively worse.

There's no point trying to map out large decision trees for the future, 
especially since we've had such a contentious time coming to some 
semblance of agreement on the current direction. Pushing more 
future-looking decisions into the text would only serve to give us more 
things to disagree about.

And, as you point out, if something comes up in the future that 
materially changes the landscape, it's completely within the purview of 
the IETF to apply rational analysis to make a decision based on the 
actual facts at that time.

/a