Re: [rtcweb] MTI Video Codec: a novel proposal

Ron <ron@debian.org> Mon, 10 November 2014 04: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 E2B681A88D8 for <rtcweb@ietfa.amsl.com>; Sun, 9 Nov 2014 20:01:03 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 E3wjQvCRPh5t for <rtcweb@ietfa.amsl.com>; Sun, 9 Nov 2014 20:01:02 -0800 (PST)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 08A7A1A88E6 for <rtcweb@ietf.org>; Sun, 9 Nov 2014 20:00:57 -0800 (PST)
Received: from ppp14-2-63-74.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.63.74]) by ipmail06.adl6.internode.on.net with ESMTP; 10 Nov 2014 14:30:45 +1030
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id ED61CFFA19 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 14:30:42 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1hDcm6RkcRoE for <rtcweb@ietf.org>; Mon, 10 Nov 2014 14:30:42 +1030 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 5B30EFF88C for <rtcweb@ietf.org>; Mon, 10 Nov 2014 14:30:42 +1030 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 4BB5D80470; Mon, 10 Nov 2014 14:30:42 +1030 (ACDT)
Date: Mon, 10 Nov 2014 14:30:42 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20141110040042.GO8092@hex.shelbyville.oz>
References: <54601E19.8080203@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <54601E19.8080203@nostrum.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/giGTyDfNnn4fksK3PSSWujULcE0
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal
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: Mon, 10 Nov 2014 04:01:04 -0000

Hi Adam,

I do need to say that I really appreciate the effort you've put into
trying to help guide this discussion, both previously and now.  You
speak an uncommon amount of good common sense.

It's not clear to me exactly how you expect this part to work though:

On Sun, Nov 09, 2014 at 04:08:25PM -1000, Adam Roach wrote:
> 2. WebRTC devices MUST implement both VP8 and H.264. If compelling
>    evidence arises that one of the codecs is available for use on a
>    royalty-free basis, such as all IPR declarations known for the codec
>    being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change
>    this normative statement to indicate that only that codec is
>    required. For absolute, crystal clarity, this provision is only
>    applicable to WebRTC devices, and not to WebRTC User Agents.

What would constitute "compelling evidence" in this context?

Since the IETF doesn't take any position on the validity of IPR
declarations, I'm not seeing how the conditional clause here can
be anything but a no-op that would be essentially impossible to
trigger.

There are plenty of proposed standards which have IPR declarations
made against them, which pretty much everyone who has analysed them
in any detail agree are utterly bogus and inapplicable, but for
which the organisation which declared them refuses to withdraw.

What am I missing that would encourage different behaviour to that
in this case?

  Cheers,
  Ron