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

[David Singer <[e-mail]>]

> On Dec 5, 2014, at 11:55 , Ted Hardie <[e-mail]> wrote:
> 
> Hi David,
> 
> On Fri, Dec 5, 2014 at 11:11 AM, David Singer <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 

David Singer
Manager, Software Standards, Apple Inc.