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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Tue, 12 July 2011 11:58 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463E121F8FF5 for <rtcweb@ietfa.amsl.com>; Tue, 12 Jul 2011 04:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.117
X-Spam-Level:
X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuqfFFapz40C for <rtcweb@ietfa.amsl.com>; Tue, 12 Jul 2011 04:58:57 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 258B521F8FEA for <rtcweb@ietf.org>; Tue, 12 Jul 2011 04:58:56 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-28-4e1c370077a2
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A5.3D.09774.0073C1E4; Tue, 12 Jul 2011 13:58:56 +0200 (CEST)
Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.110]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 12 Jul 2011 13:58:55 +0200
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Tue, 12 Jul 2011 13:58:56 +0200
Thread-Topic: [rtcweb] Comments to use-cases/reqs document
Thread-Index: Acw/1WYjrSoUFie5Qii6GYVnY+0TVAAs3RfH
Message-ID: <BBF498F2D030E84AB1179E24D1AC41D616C389F09F@ESESSCMS0362.eemea.ericsson.se>
References: <4E0B0373.3040509@ericsson.com>,<4E1B0607.6080202@alvestrand.no>
In-Reply-To: <4E1B0607.6080202@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] Comments to use-cases/reqs document
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 12 Jul 2011 11:58:58 -0000

>> All,
>>
>> some comments to
>> <http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1>
>>
>>
>>
>> 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
>
>4.2.4.1.  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 of
>    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. 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 accordingly."

But my preference is not strong - I'm happy to reinsert the use case if people think so.
>4.2.4.2.  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?

Stefan


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb