Re: Material (again!) for scoping discussion

On 25/12/13 15:10, Eric Rescorla wrote:
> On Wed, Dec 25, 2013 at 8:46 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> 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.
>
> I don't think you can draw this inference.
>
> However, the suggestions you make above for how to address this
> are precisely why I suggested it as a test case for discussing the principles
> to use for how to make these decisions (which seems to me to be a
> lot more useful than trying to discuss each issue one at a time).

Do you have a proposal on what level of functionality we should discuss? 
You mention looking at this at a higher level, but I take it that the 
use case document is too high level and not detailed out enough.

Received on Wednesday, 25 December 2013 15:45:38 UTC