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

David Singer <> Fri, 05 December 2014 20:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0C0501A1A73 for <>; Fri, 5 Dec 2014 12:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.101
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9aWJ6trBNik1 for <>; Fri, 5 Dec 2014 12:44:37 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D2F51A1A58 for <>; Fri, 5 Dec 2014 12:44:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1417812276; x=2281725876; 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=/k9wkltX6YW4f65YHkWCyj3iMDki+/N1Wjjhg9ogq+c=; b=d9CdlPGmgnA+kKYWnhnwJ9GXUag5JvN/bDr589N9nRh8ZCQqfW2v2EPuRrCRvc1h wMVinsUGCRl3wFEDRBpFXDm4BvPNCtdc/YKns7iU5B9bjYsIjEb9xBjVhNiyB7+b 0tQkueMrhFCj17Hxt9m0mrT6lAnYS929HpszgagnN4n/u2nTwsm0FpW+/E0YOccd cZddnB/Jh3xo0LOWMdNV/fs81bf2NOYkebKqjP73WCZvn1c7lh+lKzGhPp+m6Ebh C78/PqEvg56EJ4nXk6ztxXcR3ChvVQXjSsWAe6zPdXtay90GQV5I6MLkCjTDsuD/ DB3vXkuwu+npIaf2EyNWjA==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 31.5F.06819.43912845; Fri, 5 Dec 2014 12:44:36 -0800 (PST)
X-AuditID: 11973e13-f79656d000001aa3-16-548219343317
Received: from ( []) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by (Apple SCV relay) with SMTP id E7.7B.06091.51912845; Fri, 5 Dec 2014 12:44:05 -0800 (PST)
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Oct 22 2013)) with ESMTPSA id <> for; Fri, 05 Dec 2014 12:44:36 -0800 (PST)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: David Singer <>
In-reply-to: <>
Date: Fri, 05 Dec 2014 12:44:40 -0800
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <> <> <> <> <> <20141205035706.GB21150@hex.shelbyville.oz> <> <>
To: Ted Hardie <>
X-Mailer: Apple Mail (2.1993)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FCYqmsi2RRi8Pi1pcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuNb/nLXgk2pFa8dN1gbGE3JdjJwcEgImEu+vnWSDsMUkLtxb D2RzcQgJ7GOUmLX5PStM0Z2Oo8wQiYlMErPPzmYESYA5E66ndjFycDALqEtMmZILEuYV0JNo evKYCcQWFoiQONJ5hh3EZhNQlXgw5xgjSDmnQLBE7y13kDALULhhaiNYObOArcTLt1vYIWxt iSfvLrBCjLSRON23hAXihL3MEsdePwc7WkRAWWLvlR1QD8hK/LsIsosLyH7LKvGoZxfTBEbh WQjnzUJy3iwkOxYwMq9iFMpNzMzRzcwz1UssKMhJ1UvOz93ECAri6XbCOxhPr7I6xCjAwajE w7tCojFEiDWxrLgy9xCjNAeLkjjvO16gkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkb/M72X YxMjlorsuhBZo776r5KMX19mSXTV9kKTjQ4pkxwzIg5f+iLu823qxCIp9guPH6Ztl5YT0hWZ os005d4h+UuXJQ8+KRYJavpsdViVSzA14W5S8r+j32stzUPvf71TdrWzgtviGsuxKVdCXkzf dMhQ9+5115gDrypk2cpmvTjY29/VvUuJpTgj0VCLuag4EQBznHGoQwIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAcpysq2RRi8GedhcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuNb/nLXgk2pFa8dN1gbGE3JdjJwcEgImEnc6jjJD2GISF+6t Z+ti5OIQEpjIJDH77GxGkASYM+F6ahcjBwezgLrElCm5IGFeAT2JpiePmUBsYYEIiSOdZ9hB bDYBVYkHc44xgpRzCgRL9N5yBwmzAIUbpjaClTML2Eq8fLuFHcLWlnjy7gIrxEgbidN9S1gg TtjLLHHs9XM2kISIgLLE3is72CDulJX4d/EM+wRGgVkIF81CctEsJGMXMDKvYhQoSs1JrDTX SywoyEnVS87P3cQIDrrC1B2MjcutDjEKcDAq8fCukGgMEWJNLCuuzD3EKMHBrCTCmzwbKMSb klhZlVqUH19UmpNafIhRmoNFSZw35B1QSiA9sSQ1OzW1ILUIJsvEwSnVwNg8v0+1TnzWiT8l vvdt/rsfq6hiZ5y226724aus5HPKL499qn5TtP+lI/PaNz8YLl5sm/Xp+az9NfsrL/yb0+K5 9coeZb/cg8HLUsIYK1+Xz11iGZT6cbJbTPatvdVXe4vPMbO+in595nVj4t7zl8WEqu5OXvbv 0cpMj/Us6Qr1e6cd2rvCPPOWEktxRqKhFnNRcSIA6cFiFzYCAAA=
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 20:44:39 -0000

> On Dec 5, 2014, at 11:55 , Ted Hardie <> wrote:
> Hi David,
> On Fri, Dec 5, 2014 at 11:11 AM, David Singer <> wrote:
> There is a formal notice from a company that they believe they hold IPR and they are unwilling to license. You and I can dislike the situation, dislike patent law, dislike the procedures, or anything else, as much as we wish, it doesn’t change them.
> For the IETF to insert a MUST into a specification it is instructing companies,
> ​This is fundamentally incorrect.  The IETF writes voluntary standards.  A MUST in an IETF standard is not an instruction to a company; it is a description of the expected behaviour of an interoperable implementation.  You are not required to implement the standard at all.  At most, it is a description of what someone who claimed compliance to the standard is expected to have done.

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

> 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. 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 might NOT be, in fact, "WebRTC Browsers”?  This seems to both confuse the expectation — be contrary to a straightforward reading — and defeat the purpose (of interoperability). I was trying to treat the specification more straightforwardly than this, and go with obvious meanings and intentions.

If this is the expected outcome we might need a note saying roughly “Note that not every WebRTC implementation in a browser is a WebRTC Browser; some may be WebRTC Endpoints."

> choose to accept the offer of a binary solution provided by others (as have put forward by both Cisco and Google).  

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.

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

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.