Re: Material (again!) for scoping discussion

On 19/12/13 17:01, Eric Rescorla wrote:
> 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
> expect.
>
> 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?

In recent time I think there has been one proposal dealing with 
rejection [1]. There was one comment on rejection [2] (incidentally 
given by me) basically saying "your proposal looks good, but not sure we 
need this now".

So based on recent discussion this does not seem like something a lot of 
people want. And, I guess there are always the options of signaling 
(outside the SDP) to the sender to switch off video, or munging the SDP.

[1] http://lists.w3.org/Archives/Public/public-webrtc/2013Oct/0058.html
[2] http://lists.w3.org/Archives/Public/public-webrtc/2013Oct/0064.html

>
>
> 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.
>
> -Ekr
>

Received on Wednesday, 25 December 2013 13:46:51 UTC