Re: [rtcweb] revisiting MTI

Adam Roach <> Mon, 15 December 2014 22:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7AE821A01CB for <>; Mon, 15 Dec 2014 14:45:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9gU-AcKuDiJj for <>; Mon, 15 Dec 2014 14:45:15 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 622261A0248 for <>; Mon, 15 Dec 2014 14:45:05 -0800 (PST)
Received: from Orochi.local ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id sBFMj10r066609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 16:45:01 -0600 (CST) (envelope-from
X-Authentication-Warning: Host [] claimed to be Orochi.local
Message-ID: <>
Date: Mon, 15 Dec 2014 16:45:00 -0600
From: Adam Roach <>
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 <>, Ted Hardie <>
References: <> <> <> <> <> <> <> <> <> <> <20141215192409.GN47023@verdi> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
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:45:17 -0000

On 12/15/14 16:24, Peter Saint-Andre - &yet wrote:
> On 12/15/14, 3:22 PM, Adam Roach wrote:
>> On 12/15/14 16:18, Peter Saint-Andre - &yet wrote:
>>> 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).
>> I agree 100%, but I don't think we need to get consensus on what this
>> effort might look like 10 years in the future. Let's leave tomorrow's
>> battles for tomorrow, or we'll never make progress.
> Yes, that's why I'm now saying to leave out all future-oriented text.

I take the point, but there is one key future-looking component of the 
current accord. Leaving it undocumented basically violates the agreement 
that many people have signed up for. As I pointed out in a previous 
message, this particular little wart is necessary [1], even if untidy.

Which basically points to a need to document this intention (which, as 
Sean pointed out, has a non-trivial body of precedent), and to hold the 
line against documenting any further intended decision trees.

I suppose we could, without harm, document obvious points of IETF 
process like "RFCs can be obsoleted by other RFCs, and those new RFCs 
can say anything that the IETF comes to consensus around," but I doubt 
it's useful to do so, and it seems somewhat outside the purview of this 
WG to do so anyway.


[1] To put a finer point on the necessity I mention here: in the straw 
poll last year, this option *without* the forward-looking provision 
received a mere 9% of participants supporting it, with 53% actively 
opposing it. The forward-looking provision is basically the "special 
sauce" that makes this approach palatable for some significant number of 
WG participants.