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

[Bernard Aboba <[e-mail]>]

My bad.

New question:  How can an endpoint that implements video but none of the
MTI codecs be construed as "WebRTC Compatible"?

On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla <[e-mail]> wrote:

>
> On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba <[e-mail]>
> wrote:
>>
>> Allowing an endpoint that implements video to call itself "WebRTC
>> compliant" without implementing either of the MTI codecs is so wrong-headed
>> that I am at a loss for words.
>>
>
> I believe you have misread the proposal. The term "WebRTC compliant" never
> appears
> anywhere in https://tools.ietf.org/html/draft-ietf-rtcweb-video-03.
> Indeed, the word
> "compliant" does not appear.
>
> Rather, endpoints which implement neither codec qualify as "WebRTC
> Compatible".
>
> -Ekr
>
>
>> On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway <[e-mail]>
>> wrote:
>>
>>> Thanks Sean,
>>>
>>> We can not support this draft at this time.
>>>
>>> As RTC SDK vendors we very likely will support both codecs, but we can
>>> not stand by a decision that will "impose" dual MTI on our developer
>>> community.
>>>
>>> According to this, every dev must use both codecs for every app that is
>>> built using our tools. Codec selection should be their choice and not be
>>> forced upon them. This seems to be a rather unreasonable expectation.
>>>
>>>
>>> *Erik Lagerway <http://ca.linkedin.com/in/lagerway> | *Hookflash
>>> <http://hookflash.com/>* | 1 (855) Hookflash ext. 2 | Twitter
>>> <http://twitter.com/elagerway> | WebRTC.is Blog <http://webrtc.is/> *
>>>
>>> On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner <[e-mail]> wrote:
>>>
>>>> All,
>>>>
>>>> At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion
>>>> about codecs, which I dubbed "the great codec compromise."  The compromise
>>>> text that was discussed appears in slides 12-14 at [4] (which is a slight
>>>> editorial variation of the text proposed at [2]).
>>>>
>>>> This message serves to confirm the sense of the room.
>>>>
>>>> In the room, I heard the following objections and responses (and I’m
>>>> paraphrasing here), which I’ll take the liberty of categorizing as IPR,
>>>> Time, and Trigger:
>>>>
>>>> 1) IPR:
>>>>
>>>> Objections: There are still IPR concerns which may restrict what a
>>>> particular organization feels comfortable with including in their browser
>>>> implementations.
>>>>
>>>> Response:  IPR concerns on this topic are well known.  There is even a
>>>> draft summarizing the current IPR status for VP8:
>>>> draft-benham-rtcweb-vp8litigation.  The sense of the room was still that
>>>> adopting the compromise text was appropriate.
>>>>
>>>> 2) Time:
>>>>
>>>> 2.1) Time to consider decision:
>>>>
>>>> Objection: The decision to consider the compromise proposal at this
>>>> meeting was provided on short notice and did not provide some the
>>>> opportunity to attend in person.
>>>>
>>>> Response:  Six months ago the chairs made it clear discussion would be
>>>> revisited @ IETF 91 [0]. The first agenda proposal for the WG included this
>>>> topic [1], and the topic was never removed by the chairs.    More
>>>> importantly, all decisions are confirmed on list; in person attendance is
>>>> not required to be part of the process.
>>>>
>>>> 2.2) Time to consider text:
>>>>
>>>> Objection: The proposed text [2] is too new to be considered.
>>>>
>>>> Response: The requirement for browsers to support both VP8 and H.264
>>>> was among the options in the straw poll conducted more than six months
>>>> ago.  All decisions are confirmed on list so there will be ample time to
>>>> discuss the proposal.
>>>>
>>>> 3) Trigger:
>>>>
>>>> Objection: The “trigger” sentence [3] is all kinds of wrong because
>>>> it’s promising that the future IETF will update this specification.
>>>>
>>>> Response: Like any IETF proposal, an RFC that documents the current
>>>> proposal can be changed through the consensus process at any other time.
>>>>
>>>>
>>>> After the discussion, some clarifying questions about the hums, and
>>>> typing the hum questions on the screen, there was rough consensus in the
>>>> room to add (aka “shove”) the proposed text into draft-ietf-rtcweb-video.
>>>> In keeping with IETF process, I am confirming this consensus call on the
>>>> list.
>>>>
>>>> If anyone has any other issues that they would like to raise please do
>>>> by December 19th.
>>>>
>>>> Cheers,
>>>> spt (as chair)
>>>>
>>>> [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html
>>>> [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html
>>>> [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html
>>>> [3] The one that begins with "If compelling evidence ..."
>>>> [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>