[rtcweb] Please change the subject!

Harald Alvestrand <harald@alvestrand.no> Mon, 15 December 2014 10:06 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 433FD1A1AC3 for <rtcweb@ietfa.amsl.com>; Mon, 15 Dec 2014 02:06:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.51
X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XhOwfYiT1Z_7 for <rtcweb@ietfa.amsl.com>; Mon, 15 Dec 2014 02:06:06 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id 4494B1A1AC2 for <rtcweb@ietf.org>; Mon, 15 Dec 2014 02:06:06 -0800 (PST)
Received: from localhost (localhost []) by mork.alvestrand.no (Postfix) with ESMTP id 322A67C35E8 for <rtcweb@ietf.org>; Mon, 15 Dec 2014 11:06:05 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([]) by localhost (mork.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id if5c3uzZWveX for <rtcweb@ietf.org>; Mon, 15 Dec 2014 11:06:03 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:d542:904a:f9e9:3aec] (unknown [IPv6:2001:470:de0a:27:d542:904a:f9e9:3aec]) by mork.alvestrand.no (Postfix) with ESMTPSA id DEFC57C363A for <rtcweb@ietf.org>; Mon, 15 Dec 2014 11:06:02 +0100 (CET)
Message-ID: <548EB28A.4040901@alvestrand.no>
Date: Mon, 15 Dec 2014 11:06:02 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <E3FA0C72-48C5-465E-AE15-EB19D8D563A7@ieca.com> <CALiegfmuO6m=FfSQ9b9i_cu+_0eUSbxTtMh0_9kNCk9BLf-iuA@mail.gmail.com> <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <CALiegfmH6hWp6nuArv8YyPcgq6SCd9x-dU0cxAaKJLrmb0hc_g@mail.gmail.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <CALiegfkMUzQVOKk433d4TZtvenQWQwChYF2vc7HMED2s2wHZ5Q@mail.gmail.com> <B52D8E91-5D96-4960-8DDE-DD970014DE5D@ieca.com> <CALiegfnRvgDK4EnDBSn76YKktWLMjShsQRP6byCRqZC07WaVqw@mail.gmail.com>
In-Reply-To: <CALiegfnRvgDK4EnDBSn76YKktWLMjShsQRP6byCRqZC07WaVqw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/G8v0v-3USQI7g7_f3zAM86V7ehk
Subject: [rtcweb] Please change the subject!
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, 15 Dec 2014 10:06:08 -0000

On the "confirming sense of the room" thread, there have been lots of
messages over the last few days - but only *one* new position stated.

Could those who wish to comment further (like the 3 levels of poster
below) PLEASE change the subject line?

Den 14. des. 2014 01:58, skrev Iñaki Baz Castillo:
> 2014-12-13 17:36 GMT+01:00 Sean Turner <turners@ieca.com>:
>> Just to be clear:  "No plan" does not mean that the requirement is immutable forever, just that we don't have a plan right now.  MTI requirements in IETF documents can always be updated, and they very frequently are.
> That sounds good, but I'm still waiting for a response to my question
> made yesterday:
>>>  The rationale here is browser accommodation for very constrained "WebRTC compatible" devices, which will most typically be concerned with browser interoperation. The example that's been tossed around in this space is the "WebRTC doorbell" -- when someone rings the bell, you navigate to its interface using WebRTC, and stream an image from a small, embedded camera. In these kinds of very-low-cost devices, you're going to likely see hardware video encoding (e.g. do a web search for NVS2200), which will likely be one codec or another, but not both.
>>> The goal is continued browser support for such devices in perpetuity.
>> May I know where in the WG chapter is that goal defined please?
> If the above is a real goal of this WG (is it?) then that means that
> future revisions should respect it ad aternum. This is: even if in the
> future a new *good* video codec 100% RF appears, implementations MUST
> still include both VP8 and H264 (and deal with patent/licensing
> issues, which is a show stopper for certain players in the web
> ecosystem).