[rtcweb] revisiting MTI

Peter Saint-Andre - &yet <peter@andyet.net> Mon, 15 December 2014 21:37 UTC

Return-Path: <peter@andyet.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A5AF81A0062 for <rtcweb@ietfa.amsl.com>; Mon, 15 Dec 2014 13:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LchmL4kAEce3 for <rtcweb@ietfa.amsl.com>; Mon, 15 Dec 2014 13:37:43 -0800 (PST)
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F331A0020 for <rtcweb@ietf.org>; Mon, 15 Dec 2014 13:37:43 -0800 (PST)
Received: by mail-ig0-f169.google.com with SMTP id hl2so6682802igb.2 for <rtcweb@ietf.org>; Mon, 15 Dec 2014 13:37:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=c9G5c4Z27B8qvtfErCS+edq1U5EpskHXL8VJvAnwT7s=; b=a+as3M+5kPJR6I6mfXNPf0qBGR5BNPWE2GWGsfcfD2/A0R3oavLiTWY7GgRMrIL5ep FnxDmSJyC1cZO+kQ1uL2TXGViBeCsi9M5vSyA6qj6fVpAWhwNpnk++fSF2Mxmhhno2lV /vegohyg2IJO/tkonYI4/wZBQTvV5hiLGLXU8BkMsqzjukgLDY86Oz3ruZherwUrKtpL SOWTDzbLJWAY1k51iLVLLZ6btudpA50Gopkn/AASERaMpJxR/EKrSra/+wEHnmgeawmK VdDuvvUeaWHLJD9/1HQR7xN9Mtj8axIIqoxuZBsrDFqx8VHkCYCa+Yj9IzdtVujH1Go9 1IoA==
X-Gm-Message-State: ALoCoQlUbsCDCZXA5+IHJgVVXg2vxhvWgTbAY4DDkBn0N/Yd3zXfuRyRQtNFr4AObZR3RYIPX0lZ
X-Received: by with SMTP id y131mr31366864iod.11.1418679462769; Mon, 15 Dec 2014 13:37:42 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. []) by mx.google.com with ESMTPSA id j4sm1738496igx.14.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 13:37:42 -0800 (PST)
Message-ID: <548F54A5.2060105@andyet.net>
Date: Mon, 15 Dec 2014 14:37:41 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: John Leslie <john@jlc.net>
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>
In-Reply-To: <20141215192409.GN47023@verdi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7cg2vk2tWdJp81kxer4Q3nU2wsc
Cc: rtcweb@ietf.org
Subject: [rtcweb] revisiting MTI
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: Mon, 15 Dec 2014 21:37:44 -0000

On 12/15/14, 12:24 PM, John Leslie wrote:
> Peter Saint-Andre - &yet <peter@andyet.net> wrote:
>> The IETF can *always* obsolete one RFC (e.g., one that says "dual-MTI
>> for H.264 and VP8") with another RFC (e.g., one that says "no more
>> dual-MTI for H.264 and VP8, we have much better options now"). That's a
>> core aspect of the Internet Standards Process.
>     This is, of course, true...
>     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.

>     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.

> (That is what we
> want, right?)

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.