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

Sean Turner <> Sat, 13 December 2014 16:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4FA331A064C for <>; Sat, 13 Dec 2014 08:36:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.267
X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o9H45EmmoZVF for <>; Sat, 13 Dec 2014 08:36:07 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 448F61A0461 for <>; Sat, 13 Dec 2014 08:36:07 -0800 (PST)
Received: by (Postfix, from userid 5007) id 845E5592075C9; Sat, 13 Dec 2014 10:36:06 -0600 (CST)
Received: from ( []) by (Postfix) with ESMTP id 4ABA0592074E3 for <>; Sat, 13 Dec 2014 10:36:06 -0600 (CST)
Received: from [] (port=63074 helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1Xzpfp-0001yq-Ck; Sat, 13 Dec 2014 10:36:05 -0600
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Turner <>
In-Reply-To: <>
Date: Sat, 13 Dec 2014 11:36:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Iñaki Baz Castillo <>
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Exim-ID: 1Xzpfp-0001yq-Ck
X-Source-Sender: ([]) []:63074
X-Email-Count: 2
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Cc: "" <>
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: Sat, 13 Dec 2014 16:36:08 -0000

On Dec 12, 2014, at 19:00, Iñaki Baz Castillo <> wrote:

> 2014-12-13 0:49 GMT+01:00 Peter Saint-Andre - &yet <>:
>> 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.
> Clear. H264 mandatory for browsers forever. Congrats patent holders.
> BTW this is the first specification/standard/draft/RFC that states how
> future revisions of itself should behave. A clear lock-in IMHO.

Just to be clear:  "No plan" does not mean that the requirement is immutable forever, just that we don't have a plan right now.  MTI requirements in IETF documents can always be updated, and they very frequently are.

In fact, coming from the security area the idea of an MTI for life is really odd to me.  MTI cipher suites get changed often enough that many security protocols don’t include the MTI algorithms in the base spec.  For ones that die hard they get the draft names like draft-ietf-krb-wg-des-die-die-die, which became RFC 6649, that deprecates the use of DES the original MTI in Kerberos 5.

On the flip side, there are plenty of RFCs that either hint at or specify future requirements (a non exhaustive list):
1) RFCs 4305/4835/7321, RFC 5750 and 5751 use MUST+/-, SHOULD+/-, etc. to telegraph what algorithms future versions are likely to support.
2) BGP-3/4(RFC 1163/4271) specify that future verions MUST retain the format of the OPEN and NOTIFICATION messages.
3) LDAP specifications (RFC 1487/1777) indicated new authentication mechanisms would be included.
4) Diameter (RFC 3588) says future versions may mandate that clients support SCTP.
5) DOCSIS (RFC 4131) says future versions are expected to support IPv6.
6) NETCONF over TLS (RFC 5539) applies to a particular version but says it applies to future versions as well and the later MTI cipher suite MUST be supported.
7) MRCPv2 (RFC6787) includes the following "If in the future voice biometric providers standardize on such a mechanism, then a future version of MRCP can mandate it.”