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

Ron <ron@debian.org> Wed, 10 December 2014 15:16 UTC

Return-Path: <ron@debian.org>
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 1E3951A19EF for <rtcweb@ietfa.amsl.com>; Wed, 10 Dec 2014 07:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 I2kbch7rFCce for <rtcweb@ietfa.amsl.com>; Wed, 10 Dec 2014 07:16:46 -0800 (PST)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id AFD601A0115 for <rtcweb@ietf.org>; Wed, 10 Dec 2014 07:16:45 -0800 (PST)
Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Dec 2014 01:46:44 +1030
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id CE5E6FFC74 for <rtcweb@ietf.org>; Thu, 11 Dec 2014 01:46:43 +1030 (ACDT)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CHAEgt2ebYR7 for <rtcweb@ietf.org>; Thu, 11 Dec 2014 01:46:42 +1030 (ACDT)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id A74A4FFBAD for <rtcweb@ietf.org>; Thu, 11 Dec 2014 01:46:42 +1030 (ACDT)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 9A00580470; Thu, 11 Dec 2014 01:46:42 +1030 (ACDT)
Date: Thu, 11 Dec 2014 01:46:42 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20141210151642.GL19538@hex.shelbyville.oz>
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <CAPF_GTaJwaS9+9uSSGTC1+RqKb=uF8UQxsP4u5jPJiRi=88-Nw@mail.gmail.com> <CAOW+2dvGH6jEp072GxfQwZ=O_QaxZpTrq3bgd2A-gOMj2PL9ZQ@mail.gmail.com> <CABcZeBPw+JoXmHM_nH=ZF6zWfMpw_V1MLZU=hD6kac8qv_Z5eQ@mail.gmail.com> <CAOW+2dsv9W9_x+RroLdsAKyhNAFGGdCTm9P3BMf1_L0XzB8UBQ@mail.gmail.com> <CABcZeBPEp-ujLfoYp+C8_cvyQ9EdEAkn_o6aFpuXEdN_N18YZw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBPEp-ujLfoYp+C8_cvyQ9EdEAkn_o6aFpuXEdN_N18YZw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mz887Gv2PAIvV9dDw295KzgnPkE
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: Wed, 10 Dec 2014 15:16:55 -0000

On Wed, Dec 10, 2014 at 12:17:36PM +0100, Eric Rescorla wrote:
> On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba <bernard.aboba@gmail.com>
> wrote:
> 
> > My bad.
> >
> > New question:  How can an endpoint that implements video but none of the
> > MTI codecs be construed as "WebRTC Compatible"?
> >
> 
> Well, this seems like a generic complaint about the term "compatible",
> since such
> endpoints are explicitly not required to meet any requirements:
> 
>      A WebRTC-compatible endpoint is an endpoint that is able to
>       successfully communicate with a WebRTC endpoint, but may fail to
>       meet some requirements of a WebRTC endpoint.  This may limit where
>       in the network such an endpoint can be attached, or may limit the
>       security guarantees that it offers to others.  It is not
>       constrained by this specification; when it is mentioned at all, it
>       is to note the implications on WebRTC-compatible endpoints of the
>       requirements placed on WebRTC endpoints.
> 
> 
> So, perhaps we need a new term, but this doesn't seem like an issue limited to
> video codecs

Yes, I thought the definition was already very clear; but given that even
with Adam's clarification, people in this group (who you might reasonably
expect to have read these documents) appear to be confused, are already
transmuting the defined term WebRTC-compatible to "WebRTC Compatible" or
even "WebRTC compliant", and are foreshadowing their fear that some
implementers might abuse this to deliberately mislead the market (for
whatever that is worth); then maybe renaming this term is useful.

Maybe s/WebRTC-compatible endpoint/non-WebRTC endpoint/ ?

That would be consistent with "It is not constrained by this specification",
would still include my WebRTC controlled coffee maker, and might better
avoid any sort of "Vista Capable" vs "Vista Ready" word games.

  Ron