Re: [rtcweb] H.261

cowwoc <cowwoc@bbs.darktech.org> Wed, 27 November 2013 18:54 UTC

Return-Path: <cowwoc@bbs.darktech.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 75F971AD8EE for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 10:54:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 qHzbb4IIOERc for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 10:54:41 -0800 (PST)
Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 926621ADFAD for <rtcweb@ietf.org>; Wed, 27 Nov 2013 10:54:41 -0800 (PST)
Received: by mail-ie0-f177.google.com with SMTP id tp5so12279980ieb.22 for <rtcweb@ietf.org>; Wed, 27 Nov 2013 10:54:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=M/z3lflMS4VVxF6vI4rARM8GFStBlkbsmK3HUpkrT28=; b=aYI1LPglV2SRd2TYeywRY5pBHwAQ/aEMskNh3LKSg4iCyV82JRWZz1Gamkz4OuEiRL 6HK+AtXSklSWXaFr4GDJl8IkmuGG3Dfi+DUG/Fqvhf7EdX152bhO6QrLPzmuqPa3bEmL raVrn0kPup4K2S9TL/aNXEKid3J5pl3cn/VPnEUGepo+gOYq74fuQvdr4TNWXxhMvnB5 pOxU7B3gd5aT8MTSKzKqb1RJra87XiKcyVk9/bbDptARr9RoMkA73wesDZuEX/CixNSx E8sVm2tur/+MlI1F0sp65gNcaSBnvv+IKUyyWpQ2e32VUcwDENaaKmzq7xMNK4WUyjd7 NRBA==
X-Gm-Message-State: ALoCoQl+qZbyxcg8345Lzu8vLvo7QkbDrvq3SgJ6vBosuHKHnIQasJdDSIYa4JXP0++YFPnaSwyb
X-Received: by 10.42.148.200 with SMTP id s8mr1575127icv.67.1385578481040; Wed, 27 Nov 2013 10:54:41 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id a17sm4534604ign.2.2013.11.27.10.54.39 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 10:54:40 -0800 (PST)
Message-ID: <52963FC2.3000104@bbs.darktech.org>
Date: Wed, 27 Nov 2013 13:53:54 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <9783CBA7-FCF4-4241-8A04-F8DBBA409032@cisco.com> <20131127162552.GP3245@audi.shelbyville.oz>
In-Reply-To: <20131127162552.GP3245@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Wed, 27 Nov 2013 18:54:43 -0000

+1. There seems to be a lot of hand waving when it comes to H.264. Some 
very concrete questions are going unanswered.

Gili

On 27/11/2013 11:25 AM, Ron wrote:
> On Wed, Nov 27, 2013 at 03:30:55AM +0000, Cullen Jennings (fluffy) wrote:
>> I do get they MPEG LA terms can be confusing at times
>> but lots of people have figured it out.
> I can only assume that you mean this in the same sense that "lots of people"
> have "figured out" those click through EULA conditions that don't actually
> allow them to do the things they'll be doing but obviously aren't intended
> to be read since a 50 page document is presented in a 4 line scroll box with
> no button that says "click here to send this to your lawyer". [1]
>
> Like the ones that say your TV can report everything that's ever watched on
> it to the manufacturer, even after you click the Don't Do That button. [2]
>
> Or in the same sense that they drive their motor vehicles without complying
> with their legal obligation to keep a bale of hay in the trunk or have some
> person walk in front at all times waving a flag.
>
>
> A licence that says "we'll take your money, but we can't actually grant you
> the rights to use this since we don't own or control them - we'll just sort
> of promise that WE won't drag you through the courts, in exchange for being
> able to track exactly how profitable your business is" -- isn't a licence at
> all.  It's a protection racket.  With a dash of industrial espionage thrown
> in for good measure.
>
> This isn't something we should be booby trapping IETF standards with.
>
> The IETF has disclosure rules that are aimed at avoiding, so much as is
> possible, this sort of Don't ask Don't tell nonsense.  And yet we *still*
> don't have disclosures from the H.264 IPR holders that *are* present here
> for the use of H.264 in this standard.  Despite them having core dumped
> their IPR restrictions on alternative proposals.
>
> How can we possibly take mandating that technology seriously in this light?
>
> That alone should already rule this out from consideration.
>
>
>> If people have questions about specific use case I'm glad to try and get
>> them answers.
> The specific question about how the Cisco offer resolves the problem of
> MPEG LA not being the only holder of IPR that would need to be licenced
> has so far met with deafening silence.
>
> Glad answers to that would certainly be nice.
>
> People keep making claims about that offer "solving everything", which
> can't possibly be true unless you pretend those other licence holders
> don't exist.
>
> By comparison, Google at least has shown that it is *very* willing to
> do whatever is necessary to ensure that the licence and IPR of VP8 is
> very unambiguously exactly as they claim it to be.
>
> That seems a lot more reassuring than the state of denial that has
> surrounded promoting H.264.  First pretending the IPR wasn't a problem,
> then pretending they could buy us all free tickets, then claiming they
> "really wished there was a solution with no IPR burden", then rejecting
> that solution when it was actually presented as a compromise.
>
> Then pushing for getting the IETF to vote ...
>
> The number of dimensions in which we'd have to disconnect from reality
> to make this proposal acceptable makes even string theory start to look
> well grounded.
>
>    Ron
>
>
> [1] http://i.imgur.com/m0sQKZI.jpg
>
> [2] http://www.bbc.co.uk/news/technology-25042563
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb