Re: [rtcweb] H.261

Ron <ron@debian.org> Fri, 22 November 2013 21:01 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B22F1AE0C2 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 13:01:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6ZXpMKMONv9G for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 13:01:25 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADFE1AE073 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 13:01:25 -0800 (PST)
Received: from ppp14-2-50-7.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.50.7]) by ipmail07.adl2.internode.on.net with ESMTP; 23 Nov 2013 07:31:16 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 51A3E4F8F3 for <rtcweb@ietf.org>; Sat, 23 Nov 2013 07:31:14 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eqB12UwljqYa for <rtcweb@ietf.org>; Sat, 23 Nov 2013 07:31:13 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 1ADA84F902; Sat, 23 Nov 2013 07:31:13 +1030 (CST)
Date: Sat, 23 Nov 2013 07:31:13 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20131122210113.GB3245@audi.shelbyville.oz>
References: <CEB4350B.1E7B2%mzanaty@cisco.com> <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <20131122192641.GZ3245@audi.shelbyville.oz> <064C9CF2-F291-40C9-B2B8-826AEACFFE5D@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <064C9CF2-F291-40C9-B2B8-826AEACFFE5D@apple.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] H.261
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: Fri, 22 Nov 2013 21:01:27 -0000

On Fri, Nov 22, 2013 at 12:08:17PM -0800, David Singer wrote:
> Um
> 
> On Nov 22, 2013, at 11:26 , Ron <ron@debian.org> wrote:
> 
> > For the people who say they can't use VP8, the problem is much as you
> > describe, "maybe some mugger will spring out of the hedges", despite
> > the protections provided by its licencing.
> 
> It’s much worse than that.  The IETF has a formal “will not license” on the
> table, and there are active lawsuits.  For most standards bodies, a “will not
> license” statement requires an analysis, and removal of technology as needed.
> Now, it may be that the analysis and lawsuits end up revealing that the
> patents do not, in fact, read.  But we cannot just assume that.

As you said yourself just a few minutes ago:

> I’m not sure I’d call that a detailed analysis;  a detailed analysis would
> include, for example, opening up the 31/34 patent statements for each codec,
> identifying the patents, and seeing whether they had yet expired.

except s/had yet expired/were even remotely relevant/


It is indeed most unfortunate that the IETF disclosure policy allows anyone
to make even the most blatantly bogus claim and places no onus on them to
correct or retract it even once proven so.

I'm yet to see anyone take down their existing support for VP8, or point
to a particular section of code that any of that IPR core dump is relevant
to in any way.  At least one claim has already been dismissed by the court
that heard it.  And the MTI audio codec has similar bogus claims made for
it too (that have since been conclusively refuted but are still up).

The timing of the particular mugger you refer to springing from the hedges
here will in itself be an interesting point for historians of the future.
And maybe for anti-trust lawyers too.

I'd also note those patents *still* aren't declared against H.264, despite
that being their origin, and that neither the Cisco offer, nor MPEG LA, do
licence them.  The deafening silence on this is itself a notable concern.


People are actively trying to find a workable solution to the concerns
that you profess here.  Mounting a bipolar argument about which side of
the question the onus of proof belongs to depending on what you are
arguing for or against makes it a bit tricky to take that professed
concern seriously and address it as anything more than simple sophistry.

I'm pretty sure that if you can point to which part of the VP8 technology
concerns you, people would be very interested in examining that and as
you say, removing or reimplementing it as needed.  There's surely more
scope for fixing it than for fixing H.263 where the patents were designed
into it from the outset.

Unless you show us the proof where it does, we can only address your
claimed concerns as the generic handwaving that they are - with a
generically 'accepted as safe' solution.


And if we accept that handwaving, then we really can't accept the
"implement any 2" solution either.  Since that would still have the
risk of of the sets becoming disjoint should your vague fear actually
ever really play out.


  Woof,
  Ron