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

[Mohammed Raad <[e-mail]>]

David,

What's missing from this thread is input from Nokia. I found it interesting
that the same list of patents submitted to the IETF was omitted from the
"unwilling to license" declaration made to ISO and IEC. My understanding of
the compromise made by the people at the meeting is that they either do not
believe that the declaration made is credible or that it is in some other
way irrelevant. It's interesting that you seem to be trying to "save" the
people who made this decision and their employers from it.

Mohammed
On 5 Dec 2014 23:08, "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?​
>
> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>>
>> David Singer
>> Manager, Software Standards, Apple Inc.
>>
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>