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

David Singer <singer@apple.com> Wed, 03 December 2014 21:08 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 4369E1A7023 for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 13:08:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 cbmVgixvaB8r for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 13:07:58 -0800 (PST)
Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1401A700D for <rtcweb@ietf.org>; Wed, 3 Dec 2014 13:07:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417640875; x=2281554475; 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=82OW76aWurPlIR6ZG+4EXi27lMHTK2IHBkPzV/1Dawc=; b=KDzbpK+7dEtf8Ud7+T46Km208Vz45L0fgEMkU18b/uU6vr6EB7liYFJ6kd1lMgVX a1yGkVAJGzahhFZxdqo4FNS9bDrfvlj14Wm7UGS0TOWE7P3qEVh/dWZYtNPQV6vl a3T6rXphjfoxBsDJywrACtndk/0xtAiDgkKDoziiExKKKRRWbS5Fi1J5PUINSCYZ Y+n/yvwAOyCF2zWwGS7CNbeT3CzcjzmQm241/9J4TIDjd0RTX1IsebxkTptUQnS1 mnCEp0pMuss/g4zDJz8rR4qjUGFgjZtsTQZ47hiwcKdRvHHRvZ7EPvyhY+LJ862H CZD5QNHmOdEWLRbmXaUDrw==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id A0.D0.05330.BAB7F745; Wed, 3 Dec 2014 13:07:55 -0800 (PST)
X-AuditID: 11973e15-f791b6d0000014d2-ec-547f7bab2135
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 relay6.apple.com (Apple SCV relay) with SMTP id 93.3D.05775.69B7F745; Wed, 3 Dec 2014 13:07:34 -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 <0NG000BXMYOTN410@marigold.apple.com> for rtcweb@ietf.org; Wed, 03 Dec 2014 13:07:55 -0800 (PST)
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: David Singer <singer@apple.com>
In-reply-to: <547F60A8.3080302@alvestrand.no>
Date: Wed, 03 Dec 2014 13:07:54 -0800
Content-transfer-encoding: quoted-printable
Message-id: <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com>
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1990.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FAYpbu6uj7EYPpvEYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMeflFaaCWzIVj2Z/Z29g/C3WxcjJISFgIvF06xd2CFtM4sK9 9WxdjFwcQgJ7GSXmXlzODFPUenQjK0RiEpPElbWHoJz5TBJP/18AquLgYBZQl5gyJRekgVfA QOLWmRmMILawQITEkc4zYBvYBFQlHsw5BhbnFNCVmLa4FyzOAhS/076PDcRmFhCW+P74HguE rS3x5N0FVoiZNhLfph2Fum4fo8SC7Q/BGkQEdCQe7m9ggrhUXmLOhRNgRRICb1kl9i15xTyB UXgWwn2zkNw3C8mOBYzMqxiFchMzc3Qz88z0EgsKclL1kvNzNzGCAnm6negOxjOrrA4xCnAw KvHwPoiuCxFiTSwrrsw9xCjNwaIkzpuUXR8iJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbHQ QSbI8u3bHSeCVVWC+GwKZvIt2KCl+Hjr+50/987St5xdVL41u0MyIOXzuv3dgRFfZW8fXF8S XPc5aLvlhqW81k81Zjxt3Z/OMPOdGPss/76Spi0XS5WSAvP+WL2Jn/v9+M+LHxk5FRU4FP27 WOJ66n57TLP89CDwk1Zahe+FS7WKLOvnvVRiKc5INNRiLipOBAAjJAtIRQIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcojutuj7EYMcFA4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMeflFaaCWzIVj2Z/Z29g/C3WxcjJISFgItF6dCMrhC0mceHe erYuRi4OIYFJTBJX1h5ihXDmM0k8/X+BuYuRg4NZQF1iypRckAZeAQOJW2dmMILYwgIREkc6 z7CD2GwCqhIP5hwDi3MK6EpMW9wLFmcBit9p38cGYjMLCEt8f3yPBcLWlnjy7gIrxEwbiW/T jkIdsY9RYsH2h2ANIgI6Eg/3NzBBXCovMefCCbYJjAKzEE6aheSkWUjGLmBkXsUoUJSak1hp ppdYUJCTqpecn7uJERx4hVE7GBuWWx1iFOBgVOLhfRBdFyLEmlhWXJl7iFGCg1lJhNc6rz5E iDclsbIqtSg/vqg0J7X4EKM0B4uSOG9KNlBKID2xJDU7NbUgtQgmy8TBKdXAOOXt0vB5YYe5 5/t570wTXc6ceO1T0OoDcQvnPTj+QGWrfbrPvK77EY/0PzhMKXjQqejy6o1pEGvT6zvvXJav Fni/NcrOqLjV79YSqWahKd0H+zf1/EgTZZslv9JiY+Z31s8is0OOZXNKXfsl4v7u0iRT700p Fgs8O2/UPEycMN95Bl/f1iv3VZRYijMSDbWYi4oTAYrUNYk4AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2hYQEYFgoQdCDbQ7bjf-KpiTm0E
Cc: 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: Wed, 03 Dec 2014 21:08:00 -0000

> On Dec 3, 2014, at 11:12 , Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> On 12/03/2014 07:33 PM, David Singer wrote:
>> As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list.
>> 
>> This is some feedback.
>> 
>> 
>> 
>> I’d like to point out that this could easily place companies in an impossible position.
>> 
>> Consider: it is not uncommon for IPR owners to grant a license (often free) only to ‘conforming implementations’. (A common rationale is that they want to use their IPR to bring convergence and interoperability to the industry).  Let’s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC specifications.
> 
> I'm having trouble following the logic here. What technology are you imagining that Company X will put IPR claims on, and what conformance do you imagine that it would require?

I am imagining the common case that company X has IPR on some aspect of the WebRTC spec. (some other aspect than the codec), and they offer the fairly-common “license is free to conforming implementations of WebRTC”.  

> 
> (We could also consider the case of someone, call it Company G, claiming IPR on some non-codec part of WebRTC technology and refusing to license it at all. We can discuss the relative chances of the two things happening.)

No, I am not interested in discussing trolls here.  I am pursuing much more normal circumstances.

> 
>> 
>> Consider also: we have an “unwilling to license” statement from Nokia on VP8, on the formal record (and including a long list of patents).
>> 
>> Consider finally: a small company for whom WebRTC is important.
>> 
>> 
>> 
>> Let’s look at the choices:
>> 
>> 1.  Follow the mandate, implement VP8, and risk a ruinous lawsuit from Nokia.
>> 
>> 2.  Reject the mandate, do not implement VP8, and be formally therefore not conformant and therefore not in receipt of a license from company X; risk a ruinous lawsuit from X.
>> 
>> 3.  Do not implement WebRTC, and risk a ruinous loss of relevance.
>> 
>> 
>> I do not think that the IETF should be placing anyone into the position of having three extremely unpalatable choices.
> If Company G does its thing, both 1 and 2 risk a ruinous lawsuit from Company G.
>> 
>> (Yes, I am aware that #2 is ‘unlikely’, but one day someone will decide that the “only to conformant implementations” clause needs to be real and enforced, and will do this; our hypothetical small company might prefer not to be the example case.)
>> 
>> (I use a small company as the example, because for them the risk is bankruptcy, but of course no-one likes to step into the path of trouble even if they have the resources to weather it.)
> 
> My impression from the meeting was that the people speaking in favour of the proposed solution had evaluated the risks, and were ready to make a decision based on their evaluation.

Well, this is exactly that:  for the ‘vanilla’ company, mandating VP8 means mandating a violation of Nokia’s statement, which puts them at risk;  or forcing people to abrogate a ‘must’ clause, which also may put them at risk.  Or not do WebRTC.



Dave Singer

singer@mac.com

David Singer
Manager, Software Standards, Apple Inc.