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

David Singer <singer@apple.com> Fri, 05 December 2014 21:42 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 C1B611A6EE4 for <rtcweb@ietfa.amsl.com>; Fri, 5 Dec 2014 13:42:54 -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 k6mrsVHQVaTJ for <rtcweb@ietfa.amsl.com>; Fri, 5 Dec 2014 13:42:52 -0800 (PST)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAAA1A1B37 for <rtcweb@ietf.org>; Fri, 5 Dec 2014 13:42:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417815771; x=2281729371; 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=s/SYrAfZpvKk7Hm7KPCX+xAA4WEvp0w0oVgmWMhxjuU=; b=EbzPpBYzXo/dys6315S9u1VNqkvMaqSnwW1shepRww7s7Pcj00JfERPIY02ni1TL JMlPjJYGcuBkSFiceVfZ53qEPqkoDIi/97rjb/Z42mhnQBPzluBAjpQKR1i0zxBa K4Lfm/QQpcpAwNReNt5Q4EjLAm7lGRn4wO6oOfbk0w2wWfsmC7XI2aYU/06vptep 1QKXcTt/UDE4/CYlqMkI/nEPfDF7Vl9I23JF2+byjB/nky7lkvHrOCFDVDkiH/ya faJgIuNbsTY1w4rwHHtqZw9jDw//BXkoWI8j10pCplaOlB/YOIhL+Xj3AMVIlVh4 9ELkxFe72todoNrG6msuiw==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id BA.1A.12074.BD622845; Fri, 5 Dec 2014 13:42:51 -0800 (PST)
X-AuditID: 11973e12-f79f86d000002f2a-78-548226db9a66
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 7F.D5.05775.7C622845; Fri, 5 Dec 2014 13:42:31 -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 <0NG400226PNFVE40@marigold.apple.com> for rtcweb@ietf.org; Fri, 05 Dec 2014 13:42:51 -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+9kkMDM4SedfnvpYzEKu=+hWi-N_1b-nki=Pkch3sWCFkGqXg@mail.gmail.com>
Date: Fri, 05 Dec 2014 13:42:50 -0800
Content-transfer-encoding: quoted-printable
Message-id: <2CCC7F59-6EB2-4F11-A63E-40C89350E8F2@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>
To: Ted Hardie <ted.ietf@gmail.com>
X-Mailer: Apple Mail (2.1993)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAYpXtbrSnEoO+drsXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuPHiJFPBEuWKeVv+sDcwLpPpYuTkkBAwkei+tJ4JwhaTuHBv PVsXIxeHkMBeRomjPzazwBRt3rabCSIxiUli6vRnzBDOfCaJxj9bGbsYOTiYBdQlpkzJBWng FdCTaHryGGyqsECExJHOM+wgNpuAqsSDOccYQWxOgWCJZUfngC1gAYrvu3KfGcRmFrCVePl2 CzuErS3x5N0FVoiZNhJfpq6F2rudReJo21uwBSICyhJ7r+xgg7hUVuLfRYhlEgJvWSUe/nKc wCg8C+G8WUjOm4VkxQJG5lWMQrmJmTm6mXkmeokFBTmpesn5uZsYQWE83U5oB+OpVVaHGAU4 GJV4eFdINIYIsSaWFVfmHmKU5mBREud9xwsUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBg3 T/aYyPGLb72r4tnYDE5mTb5b3+Lg1vUh+GbY7PetXzre5SZVlq5IFDv8dWLv48yL3btKUne/ 4g33aTF9yFP9g3Ov4jZnhwU58fs3ak+cpbR7XWrgl61eQZ9aS45OalzzJPnW1e8e3MY3jtgl O91omfqB13aax9HGdykHpN49fX2S87fHBV8lluKMREMt5qLiRADeot1hRAIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcontcrSnEYM51Fou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcePFSaaCJcoV87b8YW9gXCbTxcjJISFgIrF5224mCFtM4sK9 9WxdjFwcQgKTmCSmTn/GDOHMZ5Jo/LOVsYuRg4NZQF1iypRckAZeAT2JpiePwZqFBSIkjnSe YQex2QRUJR7MOcYIYnMKBEssOzqHBcRmAYrvu3KfGcRmFrCVePl2CzuErS3x5N0FVoiZNhJf pq6F2rudReJo21uwBSICyhJ7r+xgg7hUVuLfxTPsExgFZiGcNAvJSbOQjF3AyLyKUaAoNSex 0kwvsaAgJ1UvOT93EyM48AqjdjA2LLc6xCjAwajEw7tCojFEiDWxrLgy9xCjBAezkghv8myg EG9KYmVValF+fFFpTmrxIUZpDhYlcd64d0ApgfTEktTs1NSC1CKYLBMHp1QDo5PS37Y9PF25 L0yPFEzzzRZ4mvsiylYlvHvF6aScA3teBgnkxe/YsY739OUmqzOlH5lrpn2oqFiSGlloGHVY 2jFN8K+7q+3H2b8yc1fwrQvMzJVh4ua8EMV0ScutuNveqHpX6PRg9vNy6zNSXj18VH1ygtZ5 NfE9nJOY1/SdkjPWT9feNTVCiaU4I9FQi7moOBEAcoijhDgCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2qCeibCvd61GW2sSeCDArRo8u14
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 21:42:54 -0000

> On Dec 5, 2014, at 13:07 , Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> On Fri, Dec 5, 2014 at 12:44 PM, David Singer <singer@apple.com> wrote:
> 
> OK, I apologize for the casual writing.  “If you claim to conform <this> definition in this RFC, then you MUST…” is effectively a conditional instruction.  Yes, of course you get to choose whether to implement at all (but you wouldn’t be here if you hadn’t chosen to implement), and also which definition you implement to (but see below).
> 
> ​May I take your presence in this discussion as an indication that you have chosen to implement?​  

Alas, no.  My job is to manage the standards landscape, and not products.  It’s another assumed conditional (!) “If my company (or indeed anyone) were to want to implement, could we/they, would we/they?"

> ​You have pointed out that such IPR grants can exist.  I did not see you point out​ any that applied to this case.  If I missed that pointer, I would appreciate your sharing it again.

If I find one, I will.  At this point, I merely point out that they are not unusual.

> > ​The proposed compromise contains multiple methods for handling the risk you believe present:  choose not to implement the standard; choose a different level compliance (endpoint);
> 
> This is where we stray into RFC 6919 territory.  You’re suggesting that an acceptable outcome is that some (many?) implementations of WebRTC in products that are called Browsers
> 
> ​No, I didn't say that.  I noted that someone who is building based on WebRTC has options here.  The endpoint option may be workable for many (especially in the Mobile App space). 

well, OK, but it does seem that if we went ahead with this text, you are saying that a browser would have a 4th option, over the three I already pointed out:

1) Implement VP8 and defy the “unwilling to license”
2) Don’t implement it, defy the “must” in the spec.
3) Don’t claim to do WebRTC at all

and now 
4) Though being a browser and doing WebRTC, claim only to be a WebRTC Endpoint, not a WebRTC Browser.

I simply don’t see how this helps anything. It’s confusing and doesn’t advance interoperability at all.  We may as well delete the WebRTC Browser clause, and call everything an endpoint, if it’s a myth that browsers that implement WebRTC will be conformant to the WebRTC Browser requirements.  Or, as I said, put a 6919 clause 1 reference next to the MUST in the webrtc browser case. :-)

> While I am terribly fond of my browser colleagues, the real uptake here has to be among those who write applications on the WebRTC platform--and making that robust enough and varied enough for their needs is important.  

I thought the principle platform was envisaged to be the WebRTC browser — something that allows embedding of webrtc in arbitrary web pages?  Yes, we expect to interop with more focused endpoints. The applications don’t supply the codecs, do they (assuming by ‘application’ you mean the collection of HTML, JS, CSS and the like)?

> I didn’t reply to this before: the point of the Cisco offer is not that it is binary, but that it carries a license.  The difficulty with VP8 is not, per se, in compiling the code, it’s the formal refusal to license.
> 
> OpenH264 notes that Cisco "will not pass on ... MPEG-LA licensing costs" and, as far as I can see, pretty much stops there​.  Google is also not passing on its costs in VP8, if there are any.  IF you believe that there are other, unbundled rights you need in either, then you should behave accordingly.  But the two are exactly parallel: they require the participant to asses the available rights and risks.  Others' assessments of those risks apparently differ from yours.

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.  Agreed, whether you actually need a license or not is a separate question.


David Singer
Manager, Software Standards, Apple Inc.