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

[Bernard Aboba <[e-mail]>]

Ted Hardie said:

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

[BA] What I heard was quite different.  A lot of folks were in favor of
having *others* undertake a dual MTI obligation so they could benefit.  I
did not hear a lot of folks claim that *they themselves* were willing to
undertake the obligation for their own benefit or the benefit of WebRTC.
Big difference.

On Fri, Dec 5, 2014 at 1:07 PM, 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
>
>