Re: [rtcweb] confirming sense of the room: mti codec

[Ron <[e-mail]>]

On Fri, Dec 12, 2014 at 04:49:19PM -0700, Peter Saint-Andre - &yet wrote:
> On 12/12/14, 4:33 PM, David Singer wrote:
> >
> >>On Dec 12, 2014, at 7:06 , Adam Roach <[e-mail]> wrote:
> >>
> >>On 12/12/14 08:57, Iñaki Baz Castillo wrote:
> >>>IMHO the door should remain open for, at least, the inclusion of a new 100% RF video codec.
> >>
> >>Then you already have what you want: there's no way we could close that door, no matter how hard we tried.
> >
> >Quite.  I rather suspect that stating “If the situation changes, we may change this specification” is stating the obvious.  These forward-looking statements don’t seem to inform implementations, or constrain or de-constrain the group. I am unclear as to what purpose they serve.
> 
> Right now the spec makes forward-looking statements.
> 
>       To promote the use of non-royalty bearing video codecs,
>       participants in the RTCWEB working group, and any successor
>       working groups in the IETF, intend to monitor the evolving
>       licensing landscape as it pertains to the two mandatory-to-
>       implement codecs.  If compelling evidence arises that one of the
>       codecs is available for use on a royalty-free basis, the working
>       group plans to revisit the question of which codecs are required
>       for Non-Browsers, with the intention being that the royalty-free
>       codec will remain mandatory to implement, and the other will
>       become optional.
> 
>       These provisions apply to WebRTC Non-Browsers only.  There is no
>       plan to revisit the codecs required for WebRTC Browsers.
> 
> I am now thinking that if we're not going to define how all this is supposed
> to work (automatic triggers? RFC to replace this one? etc.), then it would
> be best to remove that text.
> 
> And yes, any future RFC that has IETF consensus can update or obsolete this
> one (should it become an RFC), so there's no reason to run through all the
> scenarios.

Well, there is still the question of how we're complying with the charter
which says:

 The working group will follow BCP 79, and adhere to the spirit of BCP 79.
 The working group cannot explicitly rule out the possibility of adopting
 encumbered technologies; however, the working group will try to avoid
 encumbered technologies that require royalties or other encumbrances that
 would prevent such technologies from being easy to use in web browsers.

Can we show how we've "tried to avoid that", in the light of having
consensus that VP8 is acceptable as MTI?


And I still really don't get how we've complied with 6.1.1/6.1.2 of
BCP 79, in spirit or letter, if we still *only* have disclosures for VP8.

Yes I know some people keep repeating "it's an ISO standard, not an IETF
one", but that's not an escape clause BCP 79 offers.  If we make H.264
MTI then it becomes a technology required to implement this standard.
For which BCP 79 says:

 Contributors must disclose IPR meeting the description in this section;
 there are no exceptions to this rule.


  Ron