[rtcweb] Interop *and* robustness

Ron <ron@debian.org> Mon, 08 December 2014 21:38 UTC

Return-Path: <ron@debian.org>
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 86ABD1A88E9 for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 13:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hfQbN1AyXHTR for <rtcweb@ietfa.amsl.com>; Mon, 8 Dec 2014 13:38:53 -0800 (PST)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net []) by ietfa.amsl.com (Postfix) with ESMTP id 07FC81A8931 for <rtcweb@ietf.org>; Mon, 8 Dec 2014 13:38:52 -0800 (PST)
Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([]) by ipmail06.adl6.internode.on.net with ESMTP; 09 Dec 2014 08:08:51 +1030
Received: from localhost (localhost []) by mailservice.shelbyville.oz (Postfix) with ESMTP id 8A5B6FFC86; Tue, 9 Dec 2014 08:08:50 +1030 (ACDT)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([]) by localhost (mailservice.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id ycqlH9hgzIyJ; Tue, 9 Dec 2014 08:08:50 +1030 (ACDT)
Received: from hex.shelbyville.oz (hex.shelbyville.oz []) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 11613FFB47; Tue, 9 Dec 2014 08:08:50 +1030 (ACDT)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 05B7980470; Tue, 9 Dec 2014 08:08:49 +1030 (ACDT)
Date: Tue, 09 Dec 2014 08:08:49 +1030
From: Ron <ron@debian.org>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
Message-ID: <20141208213849.GG19538@hex.shelbyville.oz>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <D0AB64D8.3FA7A%mzanaty@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D0AB64D8.3FA7A%mzanaty@cisco.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ISZhl9i-jPA-OxGIB03NIwFAYWE
Cc: rtcweb@ietf.org
Subject: [rtcweb] Interop *and* robustness
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, 08 Dec 2014 21:38:54 -0000

On Mon, Dec 08, 2014 at 08:42:23PM +0000, Mo Zanaty (mzanaty) wrote:
> I support the rough consensus reached in the meeting. I support those
> willing to accept this compromise, and agree with the chair declaring that
> was the dominant sense of the room. I also support those unable to
> implement this compromise at this time for their stated reasons, in the
> sense that I understand their reasons for their reasonable positions.
> Despite the potential future importance of the current minority positions,
> I think proceeding with this compromise propels WebRTC forward on an
> important issue, because no other proposal has come remotely close to
> achieving even rough consensus.
> To reiterate another point from the meeting, there are technical
> advantages to supporting multiple codecs. Dynamic discovery of local
> capabilities, negotiation of remote capabilities, understanding how
> different error resilience mechanisms can work (or not) with different
> codecs, faster adoption of new (non-mandatory) codecs, easier path to
> deprecating old (mandatory) codecs, etc. All those legs never get
> exercised effectively in single-codec implementations, leaving land mines
> in browsers, apps, services and sometimes even specs. They become easier
> or free once the groundwork is laid for multiple codecs. While some have
> argued against that extra complexity, I see it as essential for any
> important standard.

I think this might actually be the most sensible and important new
thing anyone has actually said on the list on this topic for a long
time now :)

It gives me that warm fuzzy sense of hope that this is not just a
difficult compromise we've become resigned to, but actually something
with some real technical merits all of its own.  It hadn't really
crossed my mind in this discussion that there'd be some implementers
who really would just ignore the whole negotiation thing to hardcode
only their preferred codec -- which is kind of like saying I'd not
thought about what colour my hair is, I don't have to think for very
long to know what the real world answer to that would be.

Thanks for bringing this up for those of us who didn't make it to
the meeting and have been too busy to watch the recording yet!