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

Tim Panton <tim@phonefromhere.com> Thu, 14 November 2013 08:50 UTC

Return-Path: <tim@phonefromhere.com>
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 C4A9911E817B for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 00:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Level:
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 0D0aDLFvFgjP for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 00:50:01 -0800 (PST)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id D681611E8172 for <rtcweb@ietf.org>; Thu, 14 Nov 2013 00:50:00 -0800 (PST)
Received: (qmail 57307 invoked from network); 14 Nov 2013 08:49:52 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 1200
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 14 Nov 2013 08:49:52 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id F288A18A0411; Thu, 14 Nov 2013 08:49:51 +0000 (GMT)
Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 6503918A0379; Thu, 14 Nov 2013 08:49:51 +0000 (GMT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_77DAE0E4-47E1-445F-BA27-9AFF21C19133"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <20131113165526.GA13468@verdi>
Date: Thu, 14 Nov 2013 08:49:10 +0000
Message-Id: <73223543-696E-48B4-A293-1EE075DD78DD@phonefromhere.com>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1816)
Cc: Neil Stratford <nstratford@tropo.com>
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: Thu, 14 Nov 2013 08:50:07 -0000

On 13 Nov 2013, at 16:55, John Leslie <john@jlc.net>; wrote:

>  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...)

I'm coming around to this POV. With the possible slight variant that we should clarify
that this applies to _browsers_ not rtcweb compatible endpoints.

Ideally we'd see browsers implementing both VP8 and H264 - but single purpose 
endpoints (doorbells, prison video phones, baby alarms, smart-fashion mirrors, video mixers etc) using whichever
codec suits their hardware/legal/usecase needs best, and exchanging rtcweb media with
a browser at the far end. 

Non browser endpoints need to be confident they can talk to any browser and browsers need to
be able to talk to anything.

I think that's what is behind the option #4 in Gonzalo's proposal. 
>  4. Browsers MUST support both H.264 and VP8

- What this highlights is that we've created a media protocol that will be used by things that aren't browsers,
we need to address that requirement, without just seeing it as legacy support.

Tim.

Tip of the Hat to @nstratford for helping clarify my thinking on this.