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

Bernard Aboba <bernard.aboba@gmail.com> Fri, 05 December 2014 21:26 UTC

Return-Path: <bernard.aboba@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 8C11E1A1ABC for <rtcweb@ietfa.amsl.com>; Fri, 5 Dec 2014 13:26:07 -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 1tb8G-m1ktxl for <rtcweb@ietfa.amsl.com>; Fri, 5 Dec 2014 13:26:04 -0800 (PST)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C126A1A1B64 for <rtcweb@ietf.org>; Fri, 5 Dec 2014 13:26:03 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id n3so2697512wiv.5 for <rtcweb@ietf.org>; Fri, 05 Dec 2014 13:26:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fzbpy1PaqL7v4H8oiiBEwOnsHD4ufeHbWNtE/mRK4Qo=; b=PbdNXFGY67qObYY3GbupDu3XMATn2pjteJkH/Oubz5sd2IeyBvWpbDshi7UXgy0Ox5 Gbmai8zmpu8DGj1u84cNgIjgnp9PwRaTeF8IiwZ76/hfarxzY5dQj248mu/LGfAKV7NP 4ASlrXfbUM9fxx6VmXed8LYS1mrsGzLAWLKkwSB5LBxOQ5zok4v2ie8/wGQTL2BUpdje LhcMdo+v2UUMEiboDtKZqU5n/eePTP6tXk86IUsBeh6gaxX1tZnDnp/w0mSvYgwjoz2y AcE7R5Ch+Fmh4dc4KHCSTfOwmSW5b7+wcCNl3CnzuphpA2jrgasZpbaD3FvkrgYYoxWK u5/w==
X-Received: by 10.194.161.202 with SMTP id xu10mr27684575wjb.4.1417814762551; Fri, 05 Dec 2014 13:26:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.211.131 with HTTP; Fri, 5 Dec 2014 13:25:42 -0800 (PST)
In-Reply-To: <CA+9kkMDM4SedfnvpYzEKu=+hWi-N_1b-nki=Pkch3sWCFkGqXg@mail.gmail.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>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Fri, 5 Dec 2014 13:25:42 -0800
Message-ID: <CAOW+2dsHJQ1pVcYGEtX_NfRfmUqfKS7HAfhHWv+wrt2BAMRkTg@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=089e013d1f9c47862b05097eb977
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uecUfiBOWRBp9a5XOvmyzsnolyc
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:26:07 -0000

Ted Hardie said:

"What I heard in the room was a lot of folks who were willing to make this
compromise to move forward, because it helped enable WebRTC as a whole
(this was the main thrust of JDR's comments, for example). "

[BA] What I heard was quite different.  A lot of folks were in favor of
having *others* undertake a dual MTI obligation so they could benefit.  I
did not hear a lot of folks claim that *they themselves* were willing to
undertake the obligation for their own benefit or the benefit of WebRTC.
Big difference.

On Fri, Dec 5, 2014 at 1:07 PM, 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?​
>
> While I certainly would welcome such good news, there may well be folks
> here who are deciding whether and what to implement based on these
> decisions. What I heard in the room was a lot of folks who were willing to
> make this compromise to move forward, because it helped enable WebRTC as a
> whole (this was the main thrust of JDR's comments, for example).  Speaking
> personally, I hope that means that the breadth of implementors will
> increase in the light of the options that will be available.
>
>
>> > And note, "is expected" here has exactly no regulatory force; it is "is
>> expected" by other interoperable implementations.​
>>
>> It might not have regulatory force, but it might have consequences:
>> notably any IPR grants that are conditioned on “conforming
>> implementations”, as I pointed out before.
>
>
> ​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 you deliberately don’t do a “must” (rather than, for example, having a
>> bug), your claim of conformance may be suspect and your license therefore
>> questionable.
>>
>> > based on no visible analysis, and (unfortunately, since the German case
>> closed without a clear answer) no formal judgment, to defy the claim and
>> risk suit.
>> >
>> > ​The IETF, as a body, does not undertake those analyses.  Working group
>> members may undertake them when deciding whether to implement the standard.​
>> >
>> > That is clearly formally inappropriate.  The most we should do is to
>> use a term from RFC 6919 (I’d suggest sections 1 or 6).
>> >
>> >
>> > ​April 1 RFCs are an amusing lot, aren't they?  ​
>>
>> Well, but that’s where we seem to be.  They are amusing precisely because
>> they cut ‘close to the bone’.
>>
>> > ​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).
>
> 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.
>
> Note as well that I, personally, have never advocated for having a single
> codec available to an app or a browser; the methods for negotiating are a
> key part of this infrastructure, and they will be key to it moving forward
> as things progress.  We worked toward a mandatory-to-implement to avoid
> interoperability failure.  This compromise gets a pretty good way toward
> avoiding it​ and past what had been an impasse.  Am I thrilled?  No.  But
> it works well enough to be going along with.
>
>  .
>
>>
>> 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.
>
>
>
>> > The sense of the room (as I heard it as participant from the floor) was
>> that there were lots of people who could work with this compromise, those
>> methods, and their perception of the risk.
>> >
>> > You are absolutely free to perform what risk analysis you like and to
>> take whatever risk avoidance​ steps you deem appropriate.  That might,
>> sadly, mean you remain on the sidelines as WebRTC moves forward.  Whatever
>> your choices there, please represent the IETF process correctly as you do
>> so.
>>
>> I will try to be as precise as I can.  My apologies for the casual
>> writing.
>>
>>
> ​Thank you, and I will try to do the same.
>
> regards,
>
> Ted Hardie
> as an individual​
>
>
>
>
>> best wishes
>>
>> >
>> > regards,
>> >
>> > Ted Hardie
>> > as an individual
>> >
>> >
>> >
>> > David Singer
>> > Manager, Software Standards, Apple Inc.
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>>
>> David Singer
>> Manager, Software Standards, Apple Inc.
>>
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>