Re: [rtcweb] Is there room for a compromise? what about no MTI?

Bjoern Hoehrmann <derhoermi@gmx.net> Mon, 23 December 2013 01:40 UTC

Return-Path: <derhoermi@gmx.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 C83701AE350 for <rtcweb@ietfa.amsl.com>; Sun, 22 Dec 2013 17:40:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 U4oYsdJNT2Y0 for <rtcweb@ietfa.amsl.com>; Sun, 22 Dec 2013 17:40:10 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id D73D21AE346 for <rtcweb@ietf.org>; Sun, 22 Dec 2013 17:40:09 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.32.76]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0LeeNW-1V8wx91B6c-00qP17 for <rtcweb@ietf.org>; Mon, 23 Dec 2013 02:40:05 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Ron <ron@debian.org>
Date: Mon, 23 Dec 2013 02:40:05 +0100
Message-ID: <li4fb9hokqmvdiice9265pa5p9oksa8lka@hive.bjoern.hoehrmann.de>
References: <20131220113631.GA70585@verdi> <52B47196.6060400@bbs.darktech.org> <D5B39658-5766-4C5B-9090-8E8EDC4BCFA6@apple.com> <52B484AB.5020102@bbs.darktech.org> <CAOJ7v-0QcMsZ+nxG+kP99zE-+VUiFesGh05agwsnmaMCapJSmA@mail.gmail.com> <52B4B85F.2070209@dcrocker.net> <CAOJ7v-21zRcW=mRdec+92qNikUFZNi_UqHqvFpOfC7-MAjvY=w@mail.gmail.com> <52B73B81.6050400@dcrocker.net> <CABcZeBM8P==y_tXrNp-Rxe5unXyJJatY-ONbhCfkGPwi0bCQBg@mail.gmail.com> <20131223012255.GZ3245@audi.shelbyville.oz>
In-Reply-To: <20131223012255.GZ3245@audi.shelbyville.oz>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:tKnLi/fTkBO4iJtQ5rK3a8PQtkEUwRK6Ko2AtqAtvfR+jaqFJcP qXS/DCTqjKh/VI0iOskhOxkGPgKNeCX0bSUqp3085aPkgkCmqJfoMkBphJFJv1YKNJ9WW6Q Gmkas9jJIlfuNcyQ61m78b55HxnixB+c/QanGMzZ7rNL8vBVWN+btC515BMVmY1+hoqRKgN BDemYaZI28Kjv7yVtTWWQ==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Is there room for a compromise? what about no 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: Mon, 23 Dec 2013 01:40:12 -0000

* Ron wrote:
>On Sun, Dec 22, 2013 at 05:28:27PM -0500, Eric Rescorla wrote:
>> In such a case, would it really make sense to call such devices
>> non-compliant for not implementing an MTI video codec that they
>> wouldn't negotiate in any case?
>
>Yes, it would.  Choosing not to provide video support where video is
>an integral part of the standard and something supported by the device
>is deliberate non-compliance.
>
>That's quite different from just not doing the obviously impossible
>on obviously primitive devices.

>It doesn't seem like a very complicated question.  Justin's suggestion
>was an eminently sensible statement of the obvious.  If your device
>obviously can't ever do video at all, nobody is going to be surprised
>if the code for that doesn't happen to be there either.

That is not quite the whole story. If you order a product with "WebRTC"
and get a text pager or ringphone that do speak the wire protocol, you
might well feel mislead because you associate "WebRTC" with smartphone
video conferencing or whatever. The Working Group might well decide to
deny certain underpowered devices to claim implementing the standard it
is defining. There might be good reasons for that aswell, e.g. certain
technically plausible implementations might not meet accessibility or
other requirements considered mandatory by the Working Group.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/