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

Eric Rescorla <ekr@rtfm.com> Wed, 10 December 2014 11:18 UTC

Return-Path: <ekr@rtfm.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 686FF1A1A19 for <rtcweb@ietfa.amsl.com>; Wed, 10 Dec 2014 03:18:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 7qLRFettuJSp for <rtcweb@ietfa.amsl.com>; Wed, 10 Dec 2014 03:18:19 -0800 (PST)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A091A19EC for <rtcweb@ietf.org>; Wed, 10 Dec 2014 03:18:18 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id r20so4766996wiv.8 for <rtcweb@ietf.org>; Wed, 10 Dec 2014 03:18:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OvHITuQbh7R5tQ6IzLHNYq2nwIfqRyfqszN7x7hDuTI=; b=JO4R5B2+AB85/oUsVpp5IcwMOsbaDmIiqO6Rkm+5TSOcx4BPT3NuqvIIQgvrpUTp79 yzMOOBoM3DNfaz8tPrVUle+ESvVXZ2QE6S/wa3j2fjQ7ZibOqk7CljRiYDZyZJos7jkg wb47aA4G5kWuq/u1vtg1k/7BFAAdrbEDVjK16ZJzx2menmyU75Lq/53EyCedpFja1KIy yXg26DRV2p/TBqExD1VIUFIGUfI3up4RrVpAdEtM3AhkPZOTmR/0QkC2AhrNllWqaKIE cUCxUdm5cInOzh7EFYTVk2dX2QWlLmduF/dG+SvdaKkuiWpA8OAb2RdPVqITTiq93lNv YWZg==
X-Gm-Message-State: ALoCoQlFlcd4BlPbhimWcStGW5mMjMe+41i92BXOGYO5QE3IN/oWnqmv03mM8MxWTTtYyPwhENY0
X-Received: by 10.180.98.138 with SMTP id ei10mr5556300wib.32.1418210297279; Wed, 10 Dec 2014 03:18:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.130.34 with HTTP; Wed, 10 Dec 2014 03:17:36 -0800 (PST)
In-Reply-To: <CAOW+2dsv9W9_x+RroLdsAKyhNAFGGdCTm9P3BMf1_L0XzB8UBQ@mail.gmail.com>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <CAPF_GTaJwaS9+9uSSGTC1+RqKb=uF8UQxsP4u5jPJiRi=88-Nw@mail.gmail.com> <CAOW+2dvGH6jEp072GxfQwZ=O_QaxZpTrq3bgd2A-gOMj2PL9ZQ@mail.gmail.com> <CABcZeBPw+JoXmHM_nH=ZF6zWfMpw_V1MLZU=hD6kac8qv_Z5eQ@mail.gmail.com> <CAOW+2dsv9W9_x+RroLdsAKyhNAFGGdCTm9P3BMf1_L0XzB8UBQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 10 Dec 2014 12:17:36 +0100
Message-ID: <CABcZeBPEp-ujLfoYp+C8_cvyQ9EdEAkn_o6aFpuXEdN_N18YZw@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Content-Type: multipart/alternative; boundary=f46d044267fefc905d0509dad09d
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Gag_j5Cnx87t0hAoFwUoxJ8zxC8
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: Wed, 10 Dec 2014 11:18:22 -0000

On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba <bernard.aboba@gmail.com>
wrote:

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

Well, this seems like a generic complaint about the term "compatible",
since such
endpoints are explicitly not required to meet any requirements:

     A WebRTC-compatible endpoint is an endpoint that is able to
      successfully communicate with a WebRTC endpoint, but may fail to
      meet some requirements of a WebRTC endpoint.  This may limit where
      in the network such an endpoint can be attached, or may limit the
      security guarantees that it offers to others.  It is not
      constrained by this specification; when it is mentioned at all, it
      is to note the implications on WebRTC-compatible endpoints of the
      requirements placed on WebRTC endpoints.


So, perhaps we need a new term, but this doesn't seem like an issue limited to

video codecs


-Ekr


On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>> On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba <bernard.aboba@gmail.com>
>> 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 <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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>
>