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

Bernard Aboba <> Fri, 05 December 2014 21:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8C11E1A1ABC for <>; Fri, 5 Dec 2014 13:26:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1tb8G-m1ktxl for <>; Fri, 5 Dec 2014 13:26:04 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C126A1A1B64 for <>; Fri, 5 Dec 2014 13:26:03 -0800 (PST)
Received: by with SMTP id n3so2697512wiv.5 for <>; Fri, 05 Dec 2014 13:26:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id xu10mr27684575wjb.4.1417814762551; Fri, 05 Dec 2014 13:26:02 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 5 Dec 2014 13:25:42 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <20141205035706.GB21150@hex.shelbyville.oz> <> <> <> <>
From: Bernard Aboba <>
Date: Fri, 5 Dec 2014 13:25:42 -0800
Message-ID: <>
To: Ted Hardie <>
Content-Type: multipart/alternative; boundary=089e013d1f9c47862b05097eb977
Cc: "" <>
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> wrote:

> On Fri, Dec 5, 2014 at 12:44 PM, David Singer <> 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
>> >
>> >
>> >
>> David Singer
>> Manager, Software Standards, Apple Inc.
> _______________________________________________
> rtcweb mailing list