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

Ted Hardie <ted.ietf@gmail.com> Fri, 05 December 2014 22:32 UTC

Return-Path: <ted.ietf@gmail.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 E4D051A1F02 for <rtcweb@ietfa.amsl.com>; Fri, 5 Dec 2014 14:32:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 GnUpik4CDQ9t for <rtcweb@ietfa.amsl.com>; Fri, 5 Dec 2014 14:32:29 -0800 (PST)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9FC1A1EF6 for <rtcweb@ietf.org>; Fri, 5 Dec 2014 14:32:29 -0800 (PST)
Received: by mail-ig0-f175.google.com with SMTP id h15so71891igd.2 for <rtcweb@ietf.org>; Fri, 05 Dec 2014 14:32:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TURlcERDzVXxouDwe1xBmYNRk5Wq8cSzgkKJ6b+5Fto=; b=K+1gdVeCmzv+xHxv0MThBvdocSyW3cYkbzbLdLTRXN2SyOU5eQ++mbUL5g4ku+/Ldi 7aEBHExGD1ewU14SdoU3zb2ryVgZwj+3PHLIUvC9FYzmB6T6R0ClADcY6mBl13W388kR jMaux+xhrDJo9iNuTjFfl7sTF9RfCGTxRfuGAE3Wb9SoJ5qZUz3JNrUGrj1mpmCYhEqt iqUhERw3s16WDPdN4zUGONl0makiSFo02JBALje+z3QMfbA1OY8FbUfPuMVQs+qNRoJr 1Pdg4viF0RrA/74e+HtTX4mmVUeaapOWf+1ZgioJwKtd6l//owwccmDCy+DkSZYZsOSf +6cA==
MIME-Version: 1.0
X-Received: by 10.42.68.203 with SMTP id y11mr17451436ici.62.1417818748603; Fri, 05 Dec 2014 14:32:28 -0800 (PST)
Received: by 10.43.3.4 with HTTP; Fri, 5 Dec 2014 14:32:28 -0800 (PST)
In-Reply-To: <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> <2CCC7F59-6EB2-4F11-A63E-40C89350E8F2@apple.com>
Date: Fri, 05 Dec 2014 14:32:28 -0800
Message-ID: <CA+9kkMB+uEDBTxs4WcfCz-U8-GzSQvD4bdB0ErpK7_+EqSGDig@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: David Singer <singer@apple.com>
Content-Type: multipart/alternative; boundary="20cf30334b5fddd31205097fa65a"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AnZ-OFKHxAsSg0zhS-KbOLwP9UY
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 22:32:32 -0000

Hi David,

On Fri, Dec 5, 2014 at 1:42 PM, David Singer <singer@apple.com> wrote:

>
> ​
>
​(Much snipped)​

>
>
> > 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?


​That's certainly a model, and on platforms which provide robust access to
the necessary substrates, it may well be popular.  But it's not the only
model--a mobile app can be distributed with a  set of encoders and decoders
if the platform does not provide them (or, indeed, it could make up any
other deficits of the substrate in a particular OS).
​Because the Mah-jong ​application which substitutes player's faces for the
tile backs isn't expecting to handle arbitrary JS, or interoperate with
other applications other than browsers, the endpoint approach is valuable
for it.


>   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)?
>
> That's the "application" inside the browser or conforming mobile web
platform; it's not the only application type that might be doing WebRTC.​


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


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

regards,

Ted Hardie
as an individual




> Agreed, whether you actually need a license or not is a separate question.
>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>