Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

John Leslie <john@jlc.net> Wed, 13 November 2013 16:55 UTC

Return-Path: <john@jlc.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C153A11E8162 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 08:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.398
X-Spam-Level:
X-Spam-Status: No, score=-106.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbMYghTuUs3Q for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 08:55:28 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 80CDB21F9AE7 for <rtcweb@ietf.org>; Wed, 13 Nov 2013 08:55:28 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 1F50CC94C0; Wed, 13 Nov 2013 11:55:26 -0500 (EST)
Date: Wed, 13 Nov 2013 11:55:26 -0500
From: John Leslie <john@jlc.net>
To: Mike Linksvayer <ml@gondwanaland.com>
Message-ID: <20131113165526.GA13468@verdi>
References: <5282A340.7010405@gondwanaland.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5282A340.7010405@gondwanaland.com>
User-Agent: Mutt/1.4.1i
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
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: Wed, 13 Nov 2013 16:55:33 -0000

Mike Linksvayer <ml@gondwanaland.com>; wrote:
> 
> I strongly support VP8 for MTI, and oppose H.264. Undecided on which
> of both, either, or neither would be second best.

   I'm _very_ glad you care which is "second best!"

   I went into last week's session quite prepared to accept either, both
or neither. I came out unwilling to support _either_ as MTI.

   This is mostly because I came to understand the "cisco" postition.

   (Please excuse me for assigning names to the two main positions, but
it will make the discussion _much_ simpler.)

   The "cisco" position is:

- look at all the H.264 hardware out there: we must make use of it;
- if VP8 is MTI, we'll get sued and our customers will get hassled.

   The "linux" position is:

- look at all the VP8 software out there: we must make use of it;
- if H.264 is MTI, we'll get sued and our customers will get hassled.

   And, alas, they're both right.

   What I didn't understand before the presentations was why Cisco
believes they'll get sued over VP8, but not H.264.

   Basically H.264 has quite a consortium to slap down the likes of
Nokia in court should they sue anyone in the consortium. This greatly
reduces the chance of Nokia's lawyer suing.

   But this consortium won't lift a finger if Nokia sues Cisco over
VP8. Cisco is a _very_ attractive target over VP8.

   Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
MTI. They probably won't implement it.

   Conversely, of course, "linux" management would _very_much_ prefer
that H.264 not be MTI. They probably won't implement it.

   Understanding this, I now strongly recommend against making either
H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited
to choosing between them.)

   This issue has dragged on long enough already. We need to start
reading the riot act to the folks who claim we "need" either of these
as MTI in order to have "satisfied" users.

   Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
IMHO, will achieve consensus for "MUST implement" status. Yes, this
is a sorry state to find ourselves in. But the marketplace has
sorted out much worse problems in my memory.

   And I claim that both camps are actually more likely to implement
(or allow extensions for) the other side's codec if it is _not_ MTI,
simply because they can back out at the first sign of lawyers.

   I will not go into any details about how VP8 endpoints might talk
to H.264 endpoints, but I'm _very_ confident ways will be found if
we actually _publish_ an RFC saying both are "SHOULD implement".

   (Surely I'm not the _only_ person who'd like to see _both_ H.264
and VP8 legacy devices using our standard...)

--
John Leslie <john@jlc.net>;