Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Harald Alvestrand <harald@alvestrand.no> Thu, 04 December 2014 12:26 UTC

Return-Path: <harald@alvestrand.no>
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 B63C31A0248 for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 04:26:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 TjOIXcCfLqdY for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 04:26:45 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 49F971A0371 for <rtcweb@ietf.org>; Thu, 4 Dec 2014 04:26:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 965BC7C35B0 for <rtcweb@ietf.org>; Thu, 4 Dec 2014 13:26:27 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5WKBcheiKlW for <rtcweb@ietf.org>; Thu, 4 Dec 2014 13:26:17 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:a53a:eb60:5dc7:d291]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1D8537C3580 for <rtcweb@ietf.org>; Thu, 4 Dec 2014 13:26:17 +0100 (CET)
Message-ID: <548052E7.1050007@alvestrand.no>
Date: Thu, 04 Dec 2014 13:26:15 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net>
In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rF6QkJdtzcgY-suCq0nyyZ3tmt4
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
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: Thu, 04 Dec 2014 12:26:47 -0000

On 12/04/2014 03:10 AM, Gaelle Martin-Cocher wrote:
> There was a single hum for the three categories (browser, non-browser, compatible endpoints), right?
>
> That makes a lot of sense for non-browser entities that are in fact WebRTC-compatible enpoints (apps, or gateways or else) to push the burden on the browser vendors as those entities will need to interact with browsers.  Hence "hum"...
>
> I think it would make a lot of sense to have different "hums" or questions for the two different categories.
> That will bring clarity on what the "non-browser" yet WebRTC endpoint is, versus what the WebRTC-compatible endpoint is (let aside gateways).
> It is not clear to me that we would have had the same results for each category if there was two (or three) different questions.

It is not clear that the questions are independent.

In fact, it is pretty clear to me that some participants who were 
willing to go with this package deal were quite unwilling to commit to 
all the pieces of the package if they were presented one at a time, and 
they had to answer the question not knowing how all the other pieces 
came out.

I think this is a textbook case of a "package deal".