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

[David Singer <[e-mail]>]

> On Dec 4, 2014, at 19:57 , Ron <[e-mail]> wrote:
> 
> On Thu, Dec 04, 2014 at 02:03:44PM -0800, David Singer wrote:
>> 
>>> On Dec 4, 2014, at 13:59 , Iñaki Baz Castillo <[e-mail]> wrote:
>>> 
>>> 2014-12-03 19:33 GMT+01:00 David Singer <[e-mail]>:
>>>> As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list.
>>>> 
>>>> This is some feedback.
>>> 
>>> I've been searching in both the rtcweb and public-webrtc mailing
>>> lists, and must say that it is VERY SAD that the only "contribution"
>>> and "feedback" received from Apple are these regarding "MTI codecs",
>>> nothing else.
>>> 
>>> I hope Apple has better things to do than sending FUD to working
>>> groups in which they have no interest.
>> 
>> I apologize for both the fact that you think this is FUD, and for the lack of other engagement.
>> 
>> Quite where you see the uncertainty and doubt in the “you MUST
>> implement something which, it is stated, is subject to IPR which
>> CANNOT be licensed”, I am less sure.  Fear, yes, I get that.
> 
> Are you seriously suggesting that the due diligence which Google's
> team did prior to the acquisition of On2 and the VP8 IP was so
> completely incompetent that they "somehow missed" the barnload of
> random claims that Nokia have belatedly asserted here as a last
> scorched earth defence after all other lines of sophistry were
> apparently failing dismally?

I love your colorful language. I might think that it optimistic to think one could develop a motion-estimating, DCT-based, entropy-coded, codec — one that is in direct family from H.261 and MPEG-2 onwards — and avoid all the IPR. But your colorful language and happy faith in these engineers, and others’ skepticism, are both beside the point.

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


David Singer
Manager, Software Standards, Apple Inc.