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

Bernard Aboba <bernard.aboba@gmail.com> Tue, 09 December 2014 20:31 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80411A00BF for <rtcweb@ietfa.amsl.com>; Tue, 9 Dec 2014 12:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6TeUv5oE49t for <rtcweb@ietfa.amsl.com>; Tue, 9 Dec 2014 12:31:33 -0800 (PST)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015091A0011 for <rtcweb@ietf.org>; Tue, 9 Dec 2014 12:31:33 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id h11so3037761wiw.3 for <rtcweb@ietf.org>; Tue, 09 Dec 2014 12:31:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ALFQRg5spAVG3oIQPrQD+5z7sMOfLICOijmPC2sIVs8=; b=fJ+04uFN4/1hwdNf5SxAu/h9mVqTdRossti/k5W2IKCJtvVNmoxc7r0mdOgBwOrbo8 UB7hA8+C41LEfJGmlJ4zdLUv2gSRxi1NdHDR08FBea1Y8fGJdyRCmpsAGu3edYQ6GeSu lVVK8ZMNtABn62tZX+Zq0fE2ecGOzkrEk1ONtjjWWqinErStMwrlVzvNIWPArs1CLPqZ E5s7RzsU3PNB6zpzEfBWOPgU8xV8+nQXJzkZJclBhZRUAOphS5d4z3Etnddvh4W8eFMh F98gLvvDoxIIpOk5y3Ot5WjarKFeDbsTRyibnIHsHq7wZY7o3OREYzjqHmhYcZrobV/m 0iNw==
X-Received: by 10.194.161.202 with SMTP id xu10mr638540wjb.4.1418157091808; Tue, 09 Dec 2014 12:31:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.211.131 with HTTP; Tue, 9 Dec 2014 12:31:08 -0800 (PST)
In-Reply-To: <CAPF_GTaJwaS9+9uSSGTC1+RqKb=uF8UQxsP4u5jPJiRi=88-Nw@mail.gmail.com>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <CAPF_GTaJwaS9+9uSSGTC1+RqKb=uF8UQxsP4u5jPJiRi=88-Nw@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 9 Dec 2014 12:31:08 -0800
Message-ID: <CAOW+2dvGH6jEp072GxfQwZ=O_QaxZpTrq3bgd2A-gOMj2PL9ZQ@mail.gmail.com>
To: Sean Turner <turners@ieca.com>
Content-Type: multipart/alternative; boundary=089e013d1f9cb16e030509ce6dbf
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Z9jcw2yl14ae7VsFE682gBg80nM
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 20:31:36 -0000

Setting aside my reservations about the dual-MTI requirement for browsers,
I also oppose the other elements of the proposal.

Mandating that applications support both codecs makes no sense - they
should only be required to support one of them (their choice).   If this
change were made the trigger clause would serve no purpose, other than to
keep this discussion going ad-infinitum.  So I oppose that as well.

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.



On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway <erik@hookflash.com> 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 <turners@ieca.com> 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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>