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

Ted Hardie <> Fri, 05 December 2014 21:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 247B51A1AB8 for <>; Fri, 5 Dec 2014 13:08:03 -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 KOsYj-bQ_iAi for <>; Fri, 5 Dec 2014 13:07:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 833F81A1A95 for <>; Fri, 5 Dec 2014 13:07:59 -0800 (PST)
Received: by with SMTP id tr6so1505682ieb.35 for <>; Fri, 05 Dec 2014 13:07:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oyTZyxLTdM4uvs+z/FwJr0TzJo54wMTSaQPeq8PXz2g=; b=rd+GBQI7EAJhilJ7bCmFi5Cvt4TK9+usLUNJxL3KXseLTVOhn9kKnfjTe9kJ/BMseT S88ZP0zRIZzHigXNHxkdXdSoOvzGpqaJaOHkwEFo03PoU+vePBeuxCawwty8t9hmipa6 4jBP4yCZHBlkfJsPPS5lk9FWJ9I5lme2p80ICfT7QHDjshWabbCKw2+sfgZEtM6BbGyl JkxQb4uAVyenMpwLhkqFtPQEFKDR6LtuA2B0Nbmcu2D45pDnVBWVSpyo7tfUBrCX12UM TwRGi2syyebsTRCnoy9S2mbVciNC5iS9CZot1RQZHyhI2PQtuLSzACIpRATy17ulHap+ KNtA==
MIME-Version: 1.0
X-Received: by with SMTP id p143mr694850ioe.16.1417813678531; Fri, 05 Dec 2014 13:07:58 -0800 (PST)
Received: by with HTTP; Fri, 5 Dec 2014 13:07:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <20141205035706.GB21150@hex.shelbyville.oz> <> <> <>
Date: Fri, 5 Dec 2014 13:07:58 -0800
Message-ID: <>
From: Ted Hardie <>
To: David Singer <>
Content-Type: multipart/alternative; boundary=001a1141f3c0aaab1f05097e78c3
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:08:03 -0000

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.


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.