Re: [rtcweb] revisiting MTI

Eric Rescorla <ekr@rtfm.com> Tue, 16 December 2014 20:00 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 E7B7D1ACDFF for <rtcweb@ietfa.amsl.com>; Tue, 16 Dec 2014 12:00:08 -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 sIXOFj6ujqLn for <rtcweb@ietfa.amsl.com>; Tue, 16 Dec 2014 12:00:04 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C741A8766 for <rtcweb@ietf.org>; Tue, 16 Dec 2014 12:00:04 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id r20so13478203wiv.0 for <rtcweb@ietf.org>; Tue, 16 Dec 2014 12:00:03 -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=kDcy7UNNNwnuFUtyl1O7TMD0dTnZZLjL1UeZUApWnGE=; b=RZFUPu76qMKDf8Cac52VZIljy7z43RZyggYA97IJJcwfbzUgE9+J9ExrMs0IEYclCp s0ZpFpOXYsjYkl5NiZiTpnWNixvjpkyhMQrpiEq4P3V7jZuhL9SqPoMTuUGVgJmMJ9w6 hnGBFIF505Mku/HRtamQIwuq8HzybQuqTaJ6CZhow3SEY6pglSIlvAtuhCihG3YkHb2w mcUiWM6PP8JJTTdMnq5AUQXRUoxRxwVBW+4a+/47ZAguFetVtQ4UF6gx3aWG1rcse9dC 0fPPbUVpp2v5gCDNhbd5LOGo+4EHf7MJa/m5YFyREZ2ZdSHVXmq/5i2e+12fyIv4eqC1 x4lA==
X-Gm-Message-State: ALoCoQnIsnh16PLaKwHamqpXJMHOPBr6iUNAQcMVVQtUg+3yido42iufS7z0sdGEkFCnzkHQMs1P
X-Received: by 10.194.203.104 with SMTP id kp8mr32839217wjc.103.1418760002869; Tue, 16 Dec 2014 12:00:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.130.34 with HTTP; Tue, 16 Dec 2014 11:59:22 -0800 (PST)
In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF363549@XMB111CNC.rim.net>
References: <548F54A5.2060105@andyet.net> <CA+9kkMDNhRdbzCs9vrqDeD4CoWWK1xS5o0z3jL0DvNpDuLfCPw@mail.gmail.com> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <CABcZeBOAfuscG28PMAu8JJ4yAAt1-ohnuqCaeoa+jkpDkJhhpw@mail.gmail.com> <20141216152100.GU47023@verdi> <CABcZeBOykRm1RCupB6905AOikXrcrmeSjE45Yqf1mHL3aed2Zg@mail.gmail.com> <20141216162534.GV47023@verdi> <CABcZeBNDiDyYtv_0vZyO_mGuFi-dn4s0CXEo1agMmRSvsLNR8w@mail.gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF3634AA@XMB111CNC.rim.net> <CABcZeBPQMY=X1NFY=T04H7EGbapUMoEdN5k0WAmyzX2ijsm8pg@mail.gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF363549@XMB111CNC.rim.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 16 Dec 2014 11:59:22 -0800
Message-ID: <CABcZeBMnBCtBZqnbfcTfAR519UoffuVKKPPLc-35XKmU5WSFSg@mail.gmail.com>
To: Gaelle Martin-Cocher <gmartincocher@blackberry.com>
Content-Type: multipart/alternative; boundary=047d7bae493efe2541050a5acd2d
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XE-daBfFeavrmrAtzUVDWeiR4K0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] revisiting MTI
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, 16 Dec 2014 20:00:09 -0000

On Tue, Dec 16, 2014 at 11:56 AM, Gaelle Martin-Cocher <
gmartincocher@blackberry.com> wrote:
>
>  I am not sure on what you are basing your opinion.
>

As I said, the purpose of an MTI is to provide basic interop.


 Waiting for an RF technically superior codec might not be pragmatic and
> can indeed prevent any evolution of WebRTC codec for a long time.
>
> Deprecating MTI can be done in steps (e.g. become SHOULD, then MAY)
>
>
>
> If this MTI text prevents codec evolution, this is a serious issue.
>

It doesn't prevent codec evolution. That's why we have negotiation. Browsers
are free to implement non-MTI codecs and I would anticipate that they
will do so.

-Ekr





 Gaëlle
>
>
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* Tuesday, December 16, 2014 2:38 PM
> *To:* Gaelle Martin-Cocher
> *Cc:* John Leslie; rtcweb@ietf.org
>
> *Subject:* Re: [rtcweb] revisiting MTI
>
>
>
>
>
>
>
> On Tue, Dec 16, 2014 at 11:31 AM, Gaelle Martin-Cocher <
> gmartincocher@blackberry.com> wrote:
>
> I have little confidence that the choice between H265 and VP9 will be
> easier than it is today between VP8 and H264.
>
> Are we going to multiply similarly performing codecs  going forward (in
> the spec or in practice) or be stuck with mandatory low performing codecs
> because we cannot make better decision?
>
>
>
> It's important to remember that the requirement for an MTI codec
>
> is to guarantee basic interoperability. I would not imagine that we
>
> would define a new required codec unless it was not just technically
>
> superior but also definitively RF in the sense contemplated by Adam's
>
> text.
>
>
>
> -Ekr
>
>
>
>
>
>
>
>  Time frame for H265 / VP9  is up to two years from now
>
> And possibly the timeframe for H.266/Dalaa is four years from now
>
>
>
> This is one more drawback of the proposed text for MTI, not only it
> multiplies encoders and decoders to be supported but  can prevent the
> evolution of webrtc toward more advances codecs. (assuming we will not
> require 4 or 6 encoders and 4 or 6 decoders to be supported by every single
> endpoints. Two MTI seems largely enough, no?).
>
>
>
> Gaëlle
>
>
>
> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Eric
> Rescorla
> *Sent:* Tuesday, December 16, 2014 11:53 AM
> *To:* John Leslie
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] revisiting MTI
>
>
>
> On Tue, Dec 16, 2014 at 8:25 AM, John Leslie <john@jlc.net> wrote:
>
> Eric Rescorla <ekr@rtfm.com> wrote:
> > On Tue, Dec 16, 2014 at 7:21 AM, John Leslie <john@jlc.net> wrote:
>
> > Needless to say, having WG consensus on the substance and letting the
> > editor wordsmith the text is totally normal IETF process.
>
>    In some cases, yes. IMHO, this is not one of them. YMMV...
>
>
>
> Indeed it does, since I have *never* heard of such a case where
>
> the editor had no discretion to change the text in purely editorial
>
> ways (subject to WG consensus of course). Feel free to cite one
>
> if you have one.
>
>
>
>
>
> > I haven't heard anyone who was at HNL and in favor of the text on the
> > slides object that Adam's text in the draft doesn't reflect those
> > slides.
>
>    Probably you haven't...
>
>
>
> To the best of my knowledge it hasn't happened. Can you cite anyone
>
> who has so objected.
>
>
>
>
>
>
> > Besides, Eric isn't the WGC calling consensus.
> >
> > No, the chairs did here:
> > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html
> ]
> ] From: Sean Turner <turners at ieca.com>
> ] 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.
>
>    Actually, as I read this more carefully, that isn't a consensus call.
> Sean goes on to dismiss the objections he heard in the room:
>
>
>
> He's addressing them. What exactly is the problem with this?
>
>
>
>
> ] 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.
>
>    Sean is specifically saying the "trigger" should be discussed
> on-list.
>
>
>
> I don't read this this way at all, Rather he's saying that in the future we
>
> can update the RFC. But yes, we can discuss the trigger on-list. Do you
>
> have some substantive objection that wasn't raised in HNL and/or
>
> hasn't been discussed to death here?
>
>
>
>
>
> ] 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.
>
>    This _is_ calling for consensus.
>
>    But Sean omitted saying _what_ text; and agreed that the exact text
> may not have been clear to those in the room.
>
>
>
> Huh? The "proposed text" that was discussed in HNL is on the slide and
>
> that's what's being referred to here. Adam edited text which is
> substantially
>
> the same into the draft.
>
>
>
>
>
>
>
> ] If anyone has any other issues that they would like to raise please do
> ] by December 19th.
>
>    (And folks have been doing so.)
>
>    I have asked on-list for the exact text before raising my issues,
> since my issues relate to the text, not the choosing to have two MTIs.
>
>
>
> As I pointed out in my original message, that text is in Adam's draft.
>
>
>
> Again, it's totally procedurally regular to have rough consensus on text in
>
> the WG meeting and on the list and then have the editor edit in
> substantively
>
> the same text to the draft. If you think there is some respect in which
> those
>
> two blocks of text are not in fact the same, please point to it. Otherwise,
>
> this is just dilatory.
>
>
>
>
>
> > And this message clearly points to the slides above.
>
>    I don't find it helpful to attack the people who raise issues. YMMV.
>
>
>
>    But what EKR thinks really doesn't matter. He is not a WGC.
>
>
>
> Ironic that you would complain about "attack"s in a thread where you
>
> started out by attacking Adam Roach and here say "what EKR thinks
>
> really doesn't matter"
>
>
>
> -Ekr
>
>