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

[David Singer <[e-mail]>]

> On Dec 5, 2014, at 13:07 , Ted Hardie <[e-mail]> wrote:
> 
> On Fri, Dec 5, 2014 at 12:44 PM, David Singer <[e-mail]> 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?​  

Alas, no.  My job is to manage the standards landscape, and not products.  It’s another assumed conditional (!) “If my company (or indeed anyone) were to want to implement, could we/they, would we/they?"

> ​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 I find one, I will.  At this point, I merely point out that they are not unusual.

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

well, OK, but it does seem that if we went ahead with this text, you are saying that a browser would have a 4th option, over the three I already pointed out:

1) Implement VP8 and defy the “unwilling to license”
2) Don’t implement it, defy the “must” in the spec.
3) Don’t claim to do WebRTC at all

and now 
4) Though being a browser and doing WebRTC, claim only to be a WebRTC Endpoint, not a WebRTC Browser.

I simply don’t see how this helps anything. It’s confusing and doesn’t advance interoperability at all.  We may as well delete the WebRTC Browser clause, and call everything an endpoint, if it’s a myth that browsers that implement WebRTC will be conformant to the WebRTC Browser requirements.  Or, as I said, put a 6919 clause 1 reference next to the MUST in the webrtc browser case. :-)

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

> 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.  Agreed, whether you actually need a license or not is a separate question.


David Singer
Manager, Software Standards, Apple Inc.