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

David Singer <singer@apple.com> Wed, 03 December 2014 18:33 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 7D8F91A8BC4 for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 10:33:39 -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=[BAYES_20=-0.001, 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 5LMqaLMDjOBl for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 10:33:38 -0800 (PST)
Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853371A8F40 for <rtcweb@ietf.org>; Wed, 3 Dec 2014 10:33:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417631586; x=2281545186; 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=9+7wSe7f40sX6rl3Zm0bl/2ZJ6l8k8NhdXvhSKsN3XA=; b=THzL+anof/n4XfQ9pibTB6q0KbaJu27d3VgL3PGjAVbQlMt5Caa9VSbsA7Vxwe2W /L3Lursy7VmEZtM1lKkjb7gBjyTIRmYxFpMMNANJ9/g7n6pV6KSDOFawj8Mu5vKC KhP49uIhnDXrjK6180Ylf6LiRefSETZRQ8yjTyFxhZEbf+rh7YSX/5C172PrSMsM AJYQ8mz8VwI9mqzH/1KTw5z4AsvO5quVG548MSVF/EeFOzvv4OuCsOftX9VIzSIQ XifDpNm0KCXdS6bC2npKfEPT8aAQefoI7j4osLvAhZemfAhk+HUnO+Q94LXeQP9y q5zb7FxDWl/u2dVnupYaEg==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 93.2B.02334.2675F745; Wed, 3 Dec 2014 10:33:06 -0800 (PST)
X-AuditID: 11973e13-f79ee6d00000091e-08-547f57628dd7
Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (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 BE.B4.05775.D475F745; Wed, 3 Dec 2014 10:32:45 -0800 (PST)
Received: from [17.153.58.181] (unknown [17.153.58.181]) by aniseed.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG0004QORJ4UN40@aniseed.apple.com> for rtcweb@ietf.org; Wed, 03 Dec 2014 10:33:05 -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: <5476092D.4010406@nostrum.com>
Date: Wed, 03 Dec 2014 10:33:04 -0800
Content-transfer-encoding: quoted-printable
Message-id: <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com>
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Mailer: Apple Mail (2.1990.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FAYpZsUXh9icPATj8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+H3jGnvBV/6KK21N7A2MV3m6GDk5JARMJLb+P8UIYYtJXLi3 nq2LkYtDSGAvo8SftafZYYp6vt5lh0j0M0nsnPmBFcKZyCQx9+ld5i5GDg5mAXWJKVNyQRp4 BQwkbp2ZATZVWCBC4kjnGbBBbAKqEg/mHAOLcwpoS+xZuIQNxGYBiv+YPAXMZgaKP3l3gRVi jo3EmbbnYL1CAhkS5zdNYwaxRYBWXX54Aeo4eYk5F06AXS0h8JBV4uHsdUwTGIVmIZw0C8lJ s5CsWMDIvIpRKDcxM0c3M89UL7GgICdVLzk/dxMjKFyn2wnvYDy9yuoQowAHoxIP74PouhAh 1sSy4srcQ4zSHCxK4rz7FYFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPNfq+wsfpos6ndx /+wWh4YzUo7b/J4xXHjmfHaGo+GZ8lkyeaVPzaebW/0Ku9K4YEHTqeeJQodeBJgv2LlW4UTK eoO7ZWp3FNUDk4S2bNOdszqRcW3B9hWLXfKnTQyz7zX9c6nLqJg9qGP+nXdyJ579v+xpOCVq 1pWuU/M28Nz/3Pt5E+Pj6nQlluKMREMt5qLiRAA5mIagOAIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FAsrusbXh9icGW2msXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+H3jGnvBV/6KK21N7A2MV3m6GDk5JARMJHq+3mWHsMUkLtxb z9bFyMUhJNDPJLFz5gdWCGcik8Tcp3eZuxg5OJgF1CWmTMkFaeAVMJC4dWYGI4gtLBAhcaTz DNggNgFViQdzjoHFOQW0JfYsXMIGYrMAxX9MngJmMwPFn7y7wAoxx0biTNtzsF4hgQyJ85um MYPYIkCrLj+8AHWcvMScCyfYJjDyz0K4YhaSK2YhmbqAkXkVo0BRak5ipZleYkFBTqpecn7u JkZweBVG7WBsWG51iFGAg1GJh/dBdF2IEGtiWXFl7iFGCQ5mJRFeccf6ECHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8ZSpA1QLpiSWp2ampBalFMFkmDk6pBsbYuKmf+RYv/SfdpHHQ+Pka1Xjd 7suimk+evJO/KqJ74144T0fO9jdvlEP5/9wu9EkJ5vxtymK94f+ir5dj3/D4+bjtvvJgReTC rnfh8menZrPM/nxBeUvbPvXrtseYP+UGzEmrmjHhx/I1PT8bOnTPtu762/3Z8cDf6OKC0pLA WLFNJTVOW24qsRRnJBpqMRcVJwIAs2ZcRSsCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WeqjX72nwPLwjBins-0sFCALqBQ
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 18:33:39 -0000

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.

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.

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

Dave Singer

singer@mac.com

David Singer
Manager, Software Standards, Apple Inc.