[rtcweb] MTI video codec, charter, RFC 3929

Stephan Wenger <stewe@stewe.org> Fri, 08 November 2013 02:58 UTC

Return-Path: <stewe@stewe.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8588521E8119 for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 18:58:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JMwOjhu-qFo6 for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 18:58:00 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com []) by ietfa.amsl.com (Postfix) with ESMTP id AFDE021E81A2 for <rtcweb@ietf.org>; Thu, 7 Nov 2013 18:57:54 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com ( by CO1PR07MB362.namprd07.prod.outlook.com ( with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 8 Nov 2013 02:57:51 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([]) by CO1PR07MB363.namprd07.prod.outlook.com ([]) with mapi id 15.00.0785.001; Fri, 8 Nov 2013 02:57:51 +0000
From: Stephan Wenger <stewe@stewe.org>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: MTI video codec, charter, RFC 3929
Thread-Index: AQHO3C5PKYlhQnrmxU2nAnCXMnJnig==
Date: Fri, 8 Nov 2013 02:57:50 +0000
Message-ID: <CEA19328.A9A84%stewe@stewe.org>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 00246AB517
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(57704003)(53754006)(52604005)(87266001)(83072001)(54316002)(81686001)(66066001)(81816001)(59766001)(56776001)(77982001)(79102001)(49866001)(80976001)(47736001)(50986001)(16236675002)(47976001)(83322001)(36756003)(76786001)(76176001)(56816003)(77096001)(76796001)(31966008)(46102001)(80022001)(81542001)(74662001)(65816001)(74502001)(47446002)(69226001)(63696002)(81342001)(54356001)(4396001)(76482001)(53806001)(74876001)(74706001)(51856001)(85306002)(74366001)(2656002)(87936001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB362; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_CEA19328A9A84stewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 08 Nov 2013 02:58:10 -0000

Hi all,

At the mike, I suggested that it is time to reconsider the currently standing WG's consensus to select at least one mandatory to implement video codec.  The chairs asked that such positions be stated on the list.  Here is my position, as usual as an individual (do I need to mention this?).

(1) Specifying one or more MTI video codecs is IMO desirable ONLY if the vast majority of the implementations, including both browser-based implementations and non-browser implementations would follow that requirement, and if the chosen MTI codec is technically suitable.  Both candidates under discussion are probably technically suitable, while old and reasonably patent-save stuff like H.261 probably is not.  However, today's statements and humms show, at least to me, rather convincingly that a decision for either of the two candidate codecs will be ignored by a significant part of the implementer community.  An SDO shouldn't mandate something of which it is clear that it is going to be widely ignored, for the same reason that no good manager issues orders that he knows will be ignored by the subordinate.

(2) Under the assumption that (1) is supported by rtcweb consensus, I think we need to take off the table the following options:

(2) a) Mandating one of the two candidate codecs, by RFC 3929.  Doing so will be painful, and will not lead to interoperability among most or all rtcweb devices/browsers, and is therefore a failure.  It will also damage the webrtc standard suite as a whole: who knows what else will be ignored when such a central part is being ignored...

(2) b) Mandating both candidate codecs.  Even more folks than under 2)a) would ignore the standard as written, because one would have to absorb cost and risk for both codecs, and not only for one.  Which is not good of the reasons stated above.  Oh, I would not rule out that there are a few bold guys who would faithfully implement both-Mozilla has announced that much-and those would be the interop stars.  Still, many more IMO would not, so I cannot help calling this a failure as well.

(3) Instead, the following options should be on the table:

(3) a) Mandating "at least one of VP8 / H.264" will slightly improve interoperability over saying nothing, and the standard will not be ignored by many.

(3) b) Mandating no video codec may well be the worst option for interoperability, but has the advantage of being future-proof.  How many folks implementing H.323 are unhappy with the requirement to implement H.261 QCIF and G.711???

(4) Structure of a decision making process

I would structure the decision making process as follows:

in a first step, see whether we can agree by consensus to overturn the previous consensus that we are to define at least one MTI video codec.  (For the procedure buffs: I looked at the charter and do not believe that it would need to be changed.  Nothing therein requires us to define an MTI video codec.  In fact, work item 6 could be interpreted as already achieved (through the audio codec selection), and even if we were not using such an interpretation, item 6 leaves us the option of "must or should".  That's a lot of wiggle room.  Wise choice at charter time.

If such a consensus could be reached, then I would seek consensus between options 3)a) and 3)b) above.

If such  consensus cannot be reached, it may indeed be time to invoke the RFC 3929 processes.

Contrary to what I said at the mike, after re-reading 3929, I do not care any more whether the question of invoking 3929 and the question of revoking previous WG consensus are decoupled and sequentially decided.  If the chairs want to deal with both issues in the same consensus call, that would be fine with me.  However, I would object if the previous WG consensus is not questioned at all.

Thanks for reading all the way down here.