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

Bernard Aboba <bernard.aboba@gmail.com> Fri, 05 December 2014 19:41 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 83C881AD654 for <rtcweb@ietfa.amsl.com>; Fri, 5 Dec 2014 11:41:53 -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 RnsiAoqnHvrM for <rtcweb@ietfa.amsl.com>; Fri, 5 Dec 2014 11:41:50 -0800 (PST)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E3B1A036B for <rtcweb@ietf.org>; Fri, 5 Dec 2014 11:41:50 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id em10so2472741wid.5 for <rtcweb@ietf.org>; Fri, 05 Dec 2014 11:41:49 -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=76o+SpO06Apcd/jN0VTvLFjaqQ3AjhwQjcQor/zft3k=; b=SEwzOGBEcphvugTBI94TEf8M7c0+cjeaVQzeiyQ6aPnaoMSx4h6/jHWmn4TUjfJ+02 p0cu9fULC+9VhOxnojcS8RjrtR3Wv+XDuslRpKfGLMwlu2vU9me2ARFdACtdqCHAD6Pb Iba/EZGTtzbARG1dwkcumgU2HvKlP2SBOshjhc97+zKIfe3MrLX7XPlCtnWUAKpIdo58 L9v6FKEq//m86Hl+3CUQyF5US0a3JBXV7JGdYQbqSqkMtmFz9XmamISVaFBTFui/23iY 15ZEoJhGMXZ9NeG++reLMnqKAE3a3zhDWwA6WK6HdpGbsjF4TN7Teuu2pAs2JdFZVaaE 2UTA==
X-Received: by 10.194.92.116 with SMTP id cl20mr27382984wjb.71.1417808509223; Fri, 05 Dec 2014 11:41:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.211.131 with HTTP; Fri, 5 Dec 2014 11:41:29 -0800 (PST)
In-Reply-To: <C5A55329-4A5F-4507-8D9E-CA6AA99C6C27@apple.com>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <C5A55329-4A5F-4507-8D9E-CA6AA99C6C27@apple.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Fri, 5 Dec 2014 11:41:29 -0800
Message-ID: <CAOW+2duW-AWJMrRKiazh9tX7HQB4BXiSAMkOwngDn39WfM5xfg@mail.gmail.com>
To: "Krasimir D. Kolarov" <kolarov@apple.com>
Content-Type: multipart/alternative; boundary=047d7bd910c28d4eba05097d44ec
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gxMR70-ygqCdd4XzBuCB9_Heyx0
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: Fri, 05 Dec 2014 19:41:53 -0000

I also do not support the draft proposal for the following reasons:

1. The proposal imposes a dual MTI obligation on devices and
applications.  We should expect this recommendation to be widely ignored in
practice because it offers no interoperability benefits, while increasing
footprint and adding unnecessary liability/fees. The RFC 6919 "MUST (BUT WE
KNOW YOU WON'T)" is appropriate here.  Definition:

   The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate
   requirements that are needed to meet formal review criteria (e.g.,
   mandatory-to-implement security mechanisms), when these mechanisms
   are too inconvenient for implementers to actually implement.

2. The codec standardization process is important from a legal and IPR
disclosure point of view.  VP8 has not yet completed this process.

On Fri, Dec 5, 2014 at 11:22 AM, Krasimir D. Kolarov <kolarov@apple.com>
wrote:

> To re-iterate what I said at the mike during the meeting, at this point we
> can not support this draft, due to the existence of “unwilling to license"
> declaration on a technology required for compliance. The discussion on
> point 1 below during the meeting and on the list has not changed that
> situation.
>
> Krasimir
>
>
> > On 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
>