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

Jonathan Rosenberg <jdrosen@jdrosen.net> Sat, 13 December 2014 19:15 UTC

Return-Path: <jdrosen@jdrosen.net>
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 6B7B41A1B39 for <rtcweb@ietfa.amsl.com>; Sat, 13 Dec 2014 11:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.422
X-Spam-Level:
X-Spam-Status: No, score=0.422 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no
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 AQsesbzW60Lg for <rtcweb@ietfa.amsl.com>; Sat, 13 Dec 2014 11:15:16 -0800 (PST)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2B51A1A03 for <rtcweb@ietf.org>; Sat, 13 Dec 2014 11:15:16 -0800 (PST)
Received: from mail-pd0-f171.google.com ([209.85.192.171]:45263) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from <jdrosen@jdrosen.net>) id 1Xzs9k-0007Gb-0L for rtcweb@ietf.org; Sat, 13 Dec 2014 14:15:15 -0500
Received: by mail-pd0-f171.google.com with SMTP id y13so9127942pdi.16 for <rtcweb@ietf.org>; Sat, 13 Dec 2014 11:15:04 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.70.43.138 with SMTP id w10mr37200471pdl.50.1418498104732; Sat, 13 Dec 2014 11:15:04 -0800 (PST)
Received: by 10.70.36.205 with HTTP; Sat, 13 Dec 2014 11:15:04 -0800 (PST)
In-Reply-To: <CALiegfmH6hWp6nuArv8YyPcgq6SCd9x-dU0cxAaKJLrmb0hc_g@mail.gmail.com>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <CALiegfmuO6m=FfSQ9b9i_cu+_0eUSbxTtMh0_9kNCk9BLf-iuA@mail.gmail.com> <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <CALiegfmH6hWp6nuArv8YyPcgq6SCd9x-dU0cxAaKJLrmb0hc_g@mail.gmail.com>
Date: Sat, 13 Dec 2014 14:15:04 -0500
Message-ID: <CA+23+fHc=cz1EhkT2EbiTrP6KTkA9i0CT-00EGf9aWwf1hYWVA@mail.gmail.com>
From: Jonathan Rosenberg <jdrosen@jdrosen.net>
To: Iñaki Baz Castillo <ibc@aliax.net>
Content-Type: multipart/alternative; boundary="047d7bfea98aa5b693050a1dd3ba"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jdrosen.net
X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4xFMh2S29sL5OFMy9Yprv8_dMR4
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: Sat, 13 Dec 2014 19:15:18 -0000

I support the rough consensus reached in the room in Honolulu.

-Jonathan R.

On Fri, Dec 12, 2014 at 9:57 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>
> 2014-12-12 15:45 GMT+01:00 Adam Roach <adam@nostrum.com>:
> > I think that the future-looking clause is one of the wartiest parts of
> this
> > proposal. On the other hand, it's the one thing that makes it different
> than
> > things we've considered in the past, and is clearly a key part of what
> > allowed it to gather the support that it has so far. So: ugly, necessary,
> > and sufficient.
> >
> > Given that it's sufficient to gain the current level of support, the need
> > for change is unclear.
> >
> > Given that it's necessary, we can't remove it, or the whole thing falls
> > apart.
> >
> > And, given that it's ugly, making it more expansive would only make the
> > proposal qualitatively worse.
> >
> > There's no point trying to map out large decision trees for the future,
> > especially since we've had such a contentious time coming to some
> semblance
> > of agreement on the current direction. Pushing more future-looking
> decisions
> > into the text would only serve to give us more things to disagree about.
> >
> > And, as you point out, if something comes up in the future that
> materially
> > changes the landscape, it's completely within the purview of the IETF to
> > apply rational analysis to make a decision based on the actual facts at
> that
> > time.
>
> That would sound really nice if the already chosen MTI codecs were
> 100% RF with no licensing/patent issues. That's not the case so IMHO
> the door should remain open for, at least, the inclusion of a new 100%
> RF video codec.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


-- 
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net