W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2013

Re: Material (again!) for scoping discussion

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 19 Dec 2013 11:00:37 -0500
Message-ID: <CABcZeBOcwSmWShyzh2GD=ATvNbgY1X9a1wSJWEBaKmNrJ4q3fA@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Thu, Dec 19, 2013 at 6:10 AM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> Hi all,
> we've now gone through the list of items that could be in/out of 1.0 of
> WebRTC, and developed our opinion.
> Clue for reading (most should be obvious): when there is a strange name
> in the "Can be own spec?" column we propose creating a separate document
> (with that working name).
> Sorry for the very short notice, we'll talk more about this at the
> telechat in a little less than five hours.

I've gone through this list and it makes me pretty sad; this seems
like a recipe for a system which is primarily useful for demos, but
not suitable for building the range of applications that people really

As a worked example of this, let's start by considering track
rejection and hold. If I am on a low bandwidth link and someone offers
me video, I need to be able to reject it; it's not enough to just not
display the video, since it's still chewing up bandwidth.  So, this
seems like a fairly critical feature for a minimally functional
system, and yet the chair's proposal is to defer past 1.0. How
can this work?

After that, rather than go through this list--which is rife with this
kind of stuff--line-by-line, we need to figure out how to look at this
at a higher level in terms of what functionality we actually
need. This list seems to assume that the standard is "could you build
anything at all and then retrofit the real functionality you need
later." I strongly disagree with that.

Received on Thursday, 19 December 2013 16:01:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC