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

cowwoc <> Wed, 13 November 2013 20:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2215021E80CA for <>; Wed, 13 Nov 2013 12:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.17
X-Spam-Status: No, score=-4.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vfaPl7L6uOKw for <>; Wed, 13 Nov 2013 12:54:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 005C721E80C3 for <>; Wed, 13 Nov 2013 12:54:43 -0800 (PST)
Received: by with SMTP id wp18so1141650obc.13 for <>; Wed, 13 Nov 2013 12:54:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=s8ocNr+EgSbI2p0nUppiH30wsUqb9W6tuNWHU37nQk0=; b=JfcRtrL2yt4vaIGjkhQ63guzOSs49ZLB4zDeYZGoaCQ/wj9ZotB30yvltts45NAAhI HDgBcis1N9UGlyDbfftqh2Gi+ZfK5/9sUfPBy3kk9ui1pOeOwsJ11DOYoVGdmjMKRoF9 1OqDWcoztVvdfOcA4NbyrB6nw5D9vHvzpB2BwOFbEYokggWj56nz+UWh3lVj44zxnBoq hxTmpK+4KUeNPoZ0ZxZG3HW/19a29sjs9japk+QNISFzD3VnCCj1v/Tmvd0YEGVWHeQg 5/vAJ/TwXuyrTiEYxVRdqF5sCgFUb6hCkzdtRCW8ZhIX/kxaOqQDHtnBMEQZ+I7LdKtZ 22IA==
X-Gm-Message-State: ALoCoQnafVcA/IqEk/woHsVJbP68hDUJ5yLgafQQpgRoQZDrmgtD/kIIIBlhAoqpgHhKN++TAitC
X-Received: by with SMTP id cm10mr2958716obb.95.1384376083083; Wed, 13 Nov 2013 12:54:43 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id s9sm919633obu.4.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 12:54:42 -0800 (PST)
Message-ID: <>
Date: Wed, 13 Nov 2013 15:54:24 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
References: <> <20131113165526.GA13468@verdi>
In-Reply-To: <20131113165526.GA13468@verdi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-Mailman-Version: 2.1.12
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: Wed, 13 Nov 2013 20:54:49 -0000

Hi John,

First, thanks for summarize the positions brought up in the meeting.

A few weeks ago I advocated making both H.264 and VP8 MTI with the 
reasoning that if an implementer gets sued they can simply drop the 
codec, notify the community, and have that codec removed en-mass from 
the specification. A few months later we would replace it with another 
MTI codec. According to what you wrote above, Cisco is under the 
impression that once a codec is MTI they cannot drop it even if they get 

Practically speaking, is that really true? I mean, if the specification 
requires everyone to implement both VP8 and H.264 and one implementer 
temporarily drops one of the codecs, shouldn't things keep on working 
until the lawsuit is over (codec returns) or the community replaces the 
codec with another?


On 13/11/2013 11:55 AM, John Leslie wrote:
> Mike Linksvayer <> 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 <>
> _______________________________________________
> rtcweb mailing list