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

Peter Saint-Andre - &yet <> Fri, 12 December 2014 23:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C66BC1A0149 for <>; Fri, 12 Dec 2014 15:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YzJZb9LXeieD for <>; Fri, 12 Dec 2014 15:49:22 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 860DE1A00FF for <>; Fri, 12 Dec 2014 15:49:22 -0800 (PST)
Received: by with SMTP id hl2so3343247igb.4 for <>; Fri, 12 Dec 2014 15:49:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f3ttlNIwz0hcIa69IsUDMxvXJzBNeu07S57cIY7ERbg=; b=AW7hw5y3K1UNL95naT8qGC44DT/LuxUsJ45IjFOiGN9CelDLIIfjuKSnsRSjBO3gkm yK0jj9tqeiQhrR6dXJmffT2TqhIWvDgevRnDyYDpHxo/lh+QA9iT1oxdNVKL2MWBEOnt kbvwat5XQTwCB4LXaz1b6XdNgcqdaV8dOTmYETc/gn9nJrnbhC3t5BSx85D+Pbx8YlOd u7cS1R7T2NYcUv26r1Z4MnutkOGiKpIwuov/pzV44RJZ/MYDz2L65KfCKkUT2hNGeA/Y ka/514Oh+dD+TAA76UgEtgIdxr2+MfYncCC0QgxJryRlg5W1cZPUvfB3DtV3Qq1PVazp uhbA==
X-Gm-Message-State: ALoCoQkX1bbTmbnstKoeUFyyj8J3kGGO9fAamCUJpBXEENmJ6tYsH0nM2W1pNiUpHv2xn+sq7+o+
X-Received: by with SMTP id a32mr18139515ioj.77.1418428161900; Fri, 12 Dec 2014 15:49:21 -0800 (PST)
Received: from aither.local ( []) by with ESMTPSA id 5sm289705iom.7.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 15:49:21 -0800 (PST)
Message-ID: <>
Date: Fri, 12 Dec 2014 16:49:19 -0700
From: Peter Saint-Andre - &yet <>
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: David Singer <>, "" <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] confirming sense of the room: mti codec
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: Fri, 12 Dec 2014 23:49:24 -0000

On 12/12/14, 4:33 PM, David Singer wrote:
>> On Dec 12, 2014, at 7:06 , Adam Roach <> wrote:
>> On 12/12/14 08:57, Iñaki Baz Castillo wrote:
>>> IMHO the door should remain open for, at least, the inclusion of a new 100% RF video codec.
>> Then you already have what you want: there's no way we could close that door, no matter how hard we tried.
> Quite.  I rather suspect that stating “If the situation changes, we may change this specification” is stating the obvious.  These forward-looking statements don’t seem to inform implementations, or constrain or de-constrain the group. I am unclear as to what purpose they serve.

Right now the spec makes forward-looking statements.

       To promote the use of non-royalty bearing video codecs,
       participants in the RTCWEB working group, and any successor
       working groups in the IETF, intend to monitor the evolving
       licensing landscape as it pertains to the two mandatory-to-
       implement codecs.  If compelling evidence arises that one of the
       codecs is available for use on a royalty-free basis, the working
       group plans to revisit the question of which codecs are required
       for Non-Browsers, with the intention being that the royalty-free
       codec will remain mandatory to implement, and the other will
       become optional.

       These provisions apply to WebRTC Non-Browsers only.  There is no
       plan to revisit the codecs required for WebRTC Browsers.

I am now thinking that if we're not going to define how all this is 
supposed to work (automatic triggers? RFC to replace this one? etc.), 
then it would be best to remove that text.

And yes, any future RFC that has IETF consensus can update or obsolete 
this one (should it become an RFC), so there's no reason to run through 
all the scenarios.

See you at the NETVC BoF! ;-)


Peter Saint-Andre
CTO @ &yet