[rtcweb] WebRTC endpoint categories

Ron <ron@debian.org> Wed, 10 December 2014 23:00 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 3F6E11A1A4B for <rtcweb@ietfa.amsl.com>; Wed, 10 Dec 2014 15:00:30 -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 RAkNZnn3FUwr for <rtcweb@ietfa.amsl.com>; Wed, 10 Dec 2014 15:00:28 -0800 (PST)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF311A19FA for <rtcweb@ietf.org>; Wed, 10 Dec 2014 15:00:28 -0800 (PST)
Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail06.adl2.internode.on.net with ESMTP; 11 Dec 2014 09:30:15 +1030
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id CACD4FFCCA for <rtcweb@ietf.org>; Thu, 11 Dec 2014 09:30:13 +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 I63X415FXQwp for <rtcweb@ietf.org>; Thu, 11 Dec 2014 09:30:13 +1030 (ACDT)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 2A1D9FF82E for <rtcweb@ietf.org>; Thu, 11 Dec 2014 09:30:13 +1030 (ACDT)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 168D780470; Thu, 11 Dec 2014 09:30:13 +1030 (ACDT)
Date: Thu, 11 Dec 2014 09:30:13 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20141210230012.GN19538@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> <20141210012208.GK19538@hex.shelbyville.oz> <E425BA63-1BF0-4E51-AC4E-453A9E04C60F@apple.com> <20141210200027.GM19538@hex.shelbyville.oz> <F233B756-AF95-4DE0-B974-67AE552534E1@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F233B756-AF95-4DE0-B974-67AE552534E1@apple.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GhQmkemwyKmInrL8fTlj5Gzvohg
Subject: [rtcweb] WebRTC endpoint categories
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 23:00:30 -0000

[Changing the subject of this thread as requested earlier]

On Wed, Dec 10, 2014 at 01:50:50PM -0800, David Singer wrote:
> 
> I don’t think we need to change definitions. In some specs, there is
> an explicit “if the device supports the audio media type, it must…”
> and I took it as implicit that that was the case for the codecs for a
> given media type here. Users would not expect a device that states it
> doesn’t do audio to interop on audio.  But if a device claims to be a
> general-purpose device that supports audio and video in webRTC, I
> think we’d all like it if it actually interoperated, right? Isn’t that
> the main thrust of looking for MTI codecs?

I'm afraid I'm missing the crux of the distinction you see if you think
we're not just agreeing with each other now :)

A device is a WebRTC endpoint (browser or not) if it implements the
mandatory requirements of the WebRTC protocol (which includes MTI
codecs).

Anything which doesn't do that, but can otherwise do some subset of
WebRTC to operate with WebRTC endpoints, in some unspecified here way,
is in the WebRTC-compatible class of devices.  Whatever we end up
calling those, if the definition remains the same, they can do anything
they please, however they please, which obviously video and audio is a
subset of.  I don't see how we could sensibly say they must not do
either of those things at all, when the definition says they are not
constrained by, or defined in, or implementations of, this spec.

There's no confusion about the expectations for interop though, because
they are "non-WebRTC" devices, so nothing at all can be expected except
what the device itself says it is actually capable of.  They might
implement some melange of various standards or they might be an entirely
proprietary thing.  The IETF isn't really concerned with marketing
appellations, these classes are just language to use in the spec itself
when we need to say something referring to these categories of things.

A device which doesn't implement the WebRTC protocol, doesn't implement
the WebRTC protocol.  It doesn't really matter what its reasons for that
might be, or what other things it does implement.  Does it?

If I implement a protocol that shares the same first 8 octets with an
IPv4 header, that doesn't mean I have implemented RFC 791.

  Ron