Re: [rtcweb] Comments to use-cases/reqs document

Stephan Wenger <> Tue, 12 July 2011 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EA9121F887C for <>; Tue, 12 Jul 2011 07:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u6Qbxzdtdf3n for <>; Tue, 12 Jul 2011 07:36:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4070921F8700 for <>; Tue, 12 Jul 2011 07:36:02 -0700 (PDT)
Received: from [] (unverified []) by (SurgeMail 3.9e) with ESMTP id 12153-1743317 for multiple; Tue, 12 Jul 2011 16:36:00 +0200
User-Agent: Microsoft-MacOutlook/
Date: Tue, 12 Jul 2011 07:35:51 -0700
From: Stephan Wenger <>
To: Harald Alvestrand <>, Stefan =?ISO-8859-1?B?SOVrYW5zc29u?= LK <>
Message-ID: <>
Thread-Topic: [rtcweb] Comments to use-cases/reqs document
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-ORBS-Stamp: Your IP ( was found in the spamhaus database.
Cc: "" <>
Subject: Re: [rtcweb] Comments to use-cases/reqs document
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jul 2011 14:36:05 -0000

Hi Harald,
If you define "simple" as "minimum functionality", then there should also
be a use case "not quite so simple; offer at least the user experience you
get from a Skype client today".  That use case may well turn out to be
more popular than the "simple" use case according to your definition.
However, my preference would be not to assume minimalistic use cases, but
rather tune the level of mandation of the requirements.  (So I'm in
Stefan's camp -- keeping the number of use cases reasonable)

On 7.12.2011 07:17 , "Harald Alvestrand" <> wrote:

>On 07/12/11 13:58, Stefan Håkansson LK wrote:
>>>> All,
>>>> some comments to
>>>> 3. The "Video Size Change" use case derives F22; but that is already
>>>> derived in "Simple Video Communication Service". I propose to remove
>>>> the "Video Size Change" use case.
>>> I disagree with this proposal.
>>> While the "resizing" requirement is in "simple video communication
>>> service" as
>>> "The users can change the display sizes during the session", I believe
>>> the basic use case does not derive the requirement that the change in
>>> video size be communicated to the other party.
>>> I would propose the following changes:
>>> - Reinstate the text below:
>>> 4.2.4.  Video Size Change
>>>  Description
>>>     Alice and Bob are in a video call in their browsers and have
>>>     negotiate a high resolution video.  Bob decides to change the size
>>>     the windows his browser is displaying video to a small size.
>>>     Bob's browser regenerates the video codec paramters with Alice's
>>>     browser to change the resolution of the video Alice sends to match
>>>     the smaller size.
>> My preference is always to keep the number of use cases down.
>We may have a difference of style here - I prefer to have explicit use
>cases that show only a single action or attribute that needs to be
>supported, which means that the number of use cases tends to be high.
>I think this is especially important for the situation where a WG has to
>decide to drop an use case because no agreed-upon implementation can be
>>   Could we not just add a sentence to the current "Simple Video
>>Communication Service" use case so it reads something like "The users
>>can change the sizes of the video displays during the session. Changes
>>of the display size are communicated from the displaying browser to the
>>one sending the stream so that the video codec parameters can be changed
>As per above - I would prefer the "Simple Video Communication Service"
>to be as simple as possible. Even resizing the window locally is more
>than "as simple as possible" - the Gtalk video client for my phone
>doesn't support that.
>> But my preference is not strong - I'm happy to reinsert the use case if
>>people think so.
>>>  Derived Requirements
>>>     F22 ( It SHOULD be possible to modify video codec parameters
>>>during a
>>>     session.)
>> F22 now reads "The browser SHOULD use encoding of streams suitable for
>>the current rendering (e.g. video display size) and SHOULD change
>>parameters if the rendering changes during the session"
>>> - Change the text of F22 to be:
>>>    It SHOULD be possible for one party to request a change in video
>>> codec parameters, such as size,
>>>    during a session, and for the other party to react to this request.
>> I think "party" is very vague. What does it mean - the browser, the
>>user, the web app?
>Since this is the IETF WG - the "party" is the browser, user and web app
>together; somehow the desire for a change has to be communicated across
>the network, and that's the requirement I think needs to be in the IETF
>requirements list.
>The corresponding API requirement (which I'm not sure how to formulate -
>all this may go on in the browser and need no explicit API) needs to go
>into the W3C requirements list.
>rtcweb mailing list