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

[Peter Saint-Andre - &yet <[e-mail]>]

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.

See you at the NETVC BoF! ;-)

Peter

-- 
Peter Saint-Andre
CTO @ &yet
https://andyet.com/