Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

David Singer <singer@apple.com> Fri, 05 December 2014 23:13 UTC

Return-Path: <singer@apple.com>
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 5DEEB1A212D for <rtcweb@ietfa.amsl.com>; Fri, 5 Dec 2014 15:13:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.101
X-Spam-Level:
X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 qGHvrtqjKwIx for <rtcweb@ietfa.amsl.com>; Fri, 5 Dec 2014 15:13:50 -0800 (PST)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F8A1A6FE3 for <rtcweb@ietf.org>; Fri, 5 Dec 2014 15:13:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417821229; x=2281734829; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xINHHmbCgWGi4EWfXY2RLdxy3ViTkRE975lSJ7w2R6A=; b=EBSaHDo37yGS3CjDdFcU+/24ZvZJBFfWl87nNhpTq+oYADeBd/LfQIwCnqVWCOWC QcTmcZOOH4E4I7g0HrOxsCLVHXjmb8XdDc2Y43tYnxKBxMgt2yoAs43JDtyPDYdQ zOosrkrx+opgwlec8+AKgP55lxGlxVZsitzMgpnVv7d6YOvaTWL+uqb7Mg2l+FET UShvLOtpOYpTc9MzAKdYMbw3cUfFBrIHPDebbLt0XJZvn12kcEw1F5xHTWkgoig8 K70ZXQZJDCxYDZg00WFyWq87Hjm/KPAUcHMZwuXF9j1ZXXdJKqghH+iDHXZ/Hjz5 sewXfWzWfimPk3xxjTrHew==;
Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 34.FE.26546.D2C32845; Fri, 5 Dec 2014 15:13:49 -0800 (PST)
X-AuditID: 11973e11-f79af6d0000067b2-cb-54823c2db3a9
Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 41.95.06123.F2C32845; Fri, 5 Dec 2014 15:13:51 -0800 (PST)
Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG4002ZNTV1VE70@marigold.apple.com> for rtcweb@ietf.org; Fri, 05 Dec 2014 15:13:49 -0800 (PST)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: David Singer <singer@apple.com>
In-reply-to: <CA+9kkMB+uEDBTxs4WcfCz-U8-GzSQvD4bdB0ErpK7_+EqSGDig@mail.gmail.com>
Date: Fri, 05 Dec 2014 15:13:48 -0800
Content-transfer-encoding: quoted-printable
Message-id: <E2E87798-8093-489F-933A-891AE2DE425B@apple.com>
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <CALiegfkbiN1BAaJyrqOzUeYiViCGHcs6QaM7VVHwUzCUVAuKBw@mail.gmail.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> <C56EF8F1-FE24-4DF9-9869-49795BD34AC1@apple.com> <CA+9kkMCGp+WdcFomT53qfC2xY8LPYWTtaYiLDBbQ-AZZG1dyOg@mail.gmail.com> <ED88A5CB-C173-46EA-992F-7A57F962B7B0@apple.com> <CA+9kkMDM4SedfnvpYzEKu=+hWi-N_1b-nki=Pkch3sWCFkGqXg@mail.gmail.com> <2CCC7F59-6EB2-4F11-A63E-40C89350E8F2@apple.com> <CA+9kkMB+uEDBTxs4WcfCz-U8-GzSQvD4bdB0ErpK7_+EqSGDig@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
X-Mailer: Apple Mail (2.1993)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAYoatr0xRi8LhX3WLtv3Z2B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBltF19wVTwW6TiRvd39gbG6wJdjJwcEgImEqdvnmaFsMUkLtxb zwZiCwnsZZSYcCsRpqZxxzSgOBdQfBKTxMIf75khiuYzSRx959bFyMHBLKAuMWVKLkiYV0BP ounJYyYQW1ggQuJI5xl2EJtNQFXiwZxjjCA2p0CwxIRl98BqWIDir+7+ALOZBWwlXr7dwg5h a0s8eXeBFWKmjcTjhw2MEDdsZJVYcGINWEJEQFli75UdbBCHykr8uwiyjAvIfssqMfXuE+YJ jMKzEO6bheS+WUh2LGBkXsUolJuYmaObmWekl1hQkJOql5yfu4kRFMTT7QR3MB5fZXWIUYCD UYmHd4VEY4gQa2JZcWXuIUZpDhYlcd53vEAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjMUl nTP0FmpafmrcyfnZPONkpM8q5ZtBeWJXNhhfEI/Lnrjt48S+E182zZWTK2QuDrCfwPcsNkd1 EstUyU3VjbFn2uWKS1dW7npifCG6QmjVB862K8IJqmGv1Yqv7LCJazx15e20O6EvS17NPDxZ 8dGfDZGre2+e63grpnfsW52riEzC7CpVMyWW4oxEQy3mouJEAE2TlTlDAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FDcoqtv0xRi8P+qjMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaLv6gqngt0jFje7v7A2M1wW6GDk5JARMJBp3TGODsMUkLtxb D2RzcQgJTGKSWPjjPTNIQkhgPpPE0XduXYwcHMwC6hJTpuSChHkF9CSanjxmArGFBSIkjnSe YQex2QRUJR7MOcYIYnMKBEtMWHYPrIYFKP7q7g8wm1nAVuLl2y3sELa2xJN3F1ghZtpIPH7Y wAhxw0ZWiQUn1oAlRASUJfZe2QF1qKzEv4tn2CcwCsxCOGkWkpNmIRm7gJF5FaNAUWpOYqWp XmJBQU6qXnJ+7iZGcNgVRuxg/L/M6hCjAAejEg/vConGECHWxLLiytxDjBIczEoivMmzgUK8 KYmVValF+fFFpTmpxYcYpTlYlMR5S94BpQTSE0tSs1NTC1KLYLJMHJxSDYxr/Z+81Ldhe/VC WMlw+Z15V85Ua3yc86m458+f3N6v38K+qX13vbwwMCDKYV8qm1N5gN/T6ypa+WqxV6ZMfqTP b6/LEHeevcOmY1HLysjJMzu4Nm9Pzz1/2329nLKQePa/w3ff93keCvT7PSe08+j+DaxHZ/s+ /tdmmDWj8dS25LBpr3suhnxRYinOSDTUYi4qTgQA4WLsVTcCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EueLa36FskHChaAP891vLRlCoJ8
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
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, 05 Dec 2014 23:13:51 -0000

Hi Ted

> On Dec 5, 2014, at 14:32 , Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> Hi David,
> 
> On Fri, Dec 5, 2014 at 1:42 PM, David Singer <singer@apple.com> wrote:
> 
> ​
> ​(Much snipped)​
> 
>> It really is not similar.  Maybe there are licenses that one or other does not carry:  in the Cisco case, we are unaware of any “unwilling to license”, whereas for VP8 there is a clear statement that no license can be had. 
>> 
> ​In both cases, the participant needs to assess whether they know of all the salient IPR, whether they have all the licenses for that IPR which they need.   While I am not a lawyer, I imagine that in both cases that would involve making a determination of the relevance of the claim as well as an analysis of its license terms.  It also involves an assessment of the risk that there are other claims which may later arise.
> 
> To my lay person's eyes, the two assessments do look pretty similar.  It appears, honestly, that you disagree with the results' of others assessments, rather than that the assessments do not need to take place in both cases.  But I may be misunderstanding your point.

OK, let me see if I can persuade you of a qualitative difference.  For each ‘must’, what is the nature and availability of licenses that I might need from those claiming IPR?

* H.264: all those claiming IPR offer licenses, though most of them ask for payment
* VP8: almost all offer licenses that are either free or effectively so (pre-paid, in the case of the MPEG-LA), but there is one for which no license is available (and it’s not an insignificant company, or one not active in the field, or a small set of patents)

For me, that is a major difference.  Clearly for others (e.g. Ron who has said as much), the cost is more significant than the license availability.

I think inserting the ‘must’ here means that companies will either ignore it, or claim not to be a WebRTC Browser, neither of which advance the cause of interoperability at all.  If, in fact, we expect there to be a significant number of WebRTC Endpoints, and that we expect that they will be sometimes at both ends of a call, then this tentative agreement already has given up on ensuring interop, and I suggest we simply move to the webRTC Endpoint requirements and delete the webRTC Browser one.  (We could enhance it in various ways: add a ‘recommend both at least for decode’, for example.)


David Singer
Manager, Software Standards, Apple Inc.