Re: [rtcweb] Is there room for a compromise?

John Leslie <john@jlc.net> Sat, 21 December 2013 02:00 UTC

Return-Path: <john@jlc.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE281AD84D for <rtcweb@ietfa.amsl.com>; Fri, 20 Dec 2013 18:00:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level:
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR49QiFarlnU for <rtcweb@ietfa.amsl.com>; Fri, 20 Dec 2013 18:00:49 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E9A131AD67C for <rtcweb@ietf.org>; Fri, 20 Dec 2013 18:00:48 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id AC123C94C1; Fri, 20 Dec 2013 21:00:43 -0500 (EST)
Date: Fri, 20 Dec 2013 21:00:43 -0500
From: John Leslie <john@jlc.net>
To: cowwoc <cowwoc@bbs.darktech.org>
Message-ID: <20131221020043.GX18851@verdi>
References: <52AE54F8.5070300@bbs.darktech.org> <CABcZeBNqE25O+BNLboXDrJ1ypp26uRAw8ehwtyor9gJccpuzGw@mail.gmail.com> <52AE759C.7020209@bbs.darktech.org> <CABcZeBMjTGs41t7y=xvaLdn4i63HxC2YQUkrd-itq=VkuKvpTA@mail.gmail.com> <52AE9129.8090702@bbs.darktech.org> <CABcZeBPOxqa2YQxOrTp9sVF-tQrpg-Kn=CbazBXOx_9dajhUZA@mail.gmail.com> <52AE9E0C.9060707@bbs.darktech.org> <20131216170820.GD82971@verdi> <20131220113631.GA70585@verdi> <52B47196.6060400@bbs.darktech.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <52B47196.6060400@bbs.darktech.org>
User-Agent: Mutt/1.4.1i
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Is there room for a compromise?
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: Sat, 21 Dec 2013 02:00:50 -0000

cowwoc <cowwoc@bbs.darktech.org> wrote:
> On 20/12/2013 6:36 AM, John Leslie wrote:
>>    Matthew Kaufman makes several good points in favor of no-MTI.
>>...
>> Most responses seem to rule out the no-MTI choice; but we _cannot_
>> rule it out. We can punt it to another WG, perhaps, if we can't
>> bring ourselves to consensus to put it in writing; but we're getting
>> no closer to consensus on any other choice, and at some point we
>> need to put this question to rest.
> 
> What's the point of a standard (any standard) that does not guarantee 
> interoperability?

   No standard _can_ "guarantee" interoperability.

   There are many standards that specify _part_of_ how to accomplish
something.

   WebRTC will, in any case, have to specify some way to propose codecs
which are _not_ MTI and negotiate their use. It would be silly to not
allow this same mechanism to propose codecs which _are_ MTI. This would
greatly simplify future upgrades to better codecs.

   And it would be many times more foolish to claim that the market
will not demand better codecs...

   (Please note that my "position" is to have two SHOULD codecs if we
cannot reach consensus on one or more MTI codecs -- in which case it
would be reasonably common for negotiation to succeed.)

   We seem to agree that there will be H.264-only devices attempting
to use WebRTC, and there will be VP8-only devices attempting to use
WebRTC. We have also been told that certain browsers expect to support
both. In those cases, the negotiation succeeds, whether or not we
ever agree on one or more MTI codecs.

   (Of course, it can't _actually_ succeed unless someone designs
the system for negotiation...)

   The point is, a standard which fully designs the negotiation
process is clearly useful -- even though that standard allows a
case where negotiation fails.

> In the worse case, we'd end up with two competing standards

   Perhaps -- but we don't _need_ two competing standards. We end
up with what I would call islands of connectivity within WebRTC.

> but (in my opinion) dropping MTI in the one-and-only standard 
> defeats its reason for existing.

   We aren't designing "the" one-and-only standard. We're designing
a standard to be useful in combination with other standards.

   (Is _that_ the reason so many folks seem to be wearing blinders?)

--
John Leslie <john@jlc.net>