Re: [rtcweb] Comments to use-cases/reqs document
Henry Sinnreich <henry.sinnreich@gmail.com> Tue, 12 July 2011 15:56 UTC
Return-Path: <henry.sinnreich@gmail.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 2919621F8ED2 for <rtcweb@ietfa.amsl.com>; Tue, 12 Jul 2011 08:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.986
X-Spam-Level:
X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=-2.614, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1, 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 z20LdCuqLkqB for <rtcweb@ietfa.amsl.com>; Tue, 12 Jul 2011 08:56:26 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D75721F8EC8 for <rtcweb@ietf.org>; Tue, 12 Jul 2011 08:56:26 -0700 (PDT)
Received: by yxp4 with SMTP id 4so2515154yxp.31 for <rtcweb@ietf.org>; Tue, 12 Jul 2011 08:56:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ZR4M5pRN5bN24PKyFYbJyzs5Wbb60IsEpBuUawS8bFE=; b=pHeRfYou7UiP5MiekuNswXdw8faiuslp2iD5yPMZGFjIothrDneep/PL5b5BrnK+5l O/HXPSZIv7amh+GBxrp63Yu0C5IvBEtBOQY1/8xsAKcWvgaWwb3Xy64Jm+pBbMe17ArF PgKhBJ1oJL3vCcMYHXhpJH/0nHqYTUtSKnicw=
Received: by 10.101.23.17 with SMTP id a17mr69021anj.143.1310486185742; Tue, 12 Jul 2011 08:56:25 -0700 (PDT)
Received: from [192.168.15.2] (cpe-76-184-227-164.tx.res.rr.com [76.184.227.164]) by mx.google.com with ESMTPS id v9sm13462239anv.30.2011.07.12.08.56.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jul 2011 08:56:24 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Tue, 12 Jul 2011 10:56:21 -0500
From: Henry Sinnreich <henry.sinnreich@gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>, Stephan Wenger <stewe@stewe.org>
Message-ID: <CA41D8D5.1C395%henry.sinnreich@gmail.com>
Thread-Topic: [rtcweb] Comments to use-cases/reqs document
Thread-Index: AcxArD5C3J+SPmk77k60BK3v+Cm4CQ==
In-Reply-To: <4E1C6215.1000601@alvestrand.no>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 15:56:27 -0000
+1 The use cases and especially requirements should be kept as simple/minimal as possible but no more. Actually the most interesting use cases may not be known at present; a good test if rtcweb is really innovative. Quite happy that Harald and Cullen seem to keep firm control on this. As for the video/screens parameters, one of my gripes is the use of antiquated SDP instead of standard metadata formats for all screens, I/O devices, etc. SDP is a big can of worms to throw out. Legacy RTP as well, but this seems to be covered for now. Finally, just to put all my gripes in one place: Why not use HIP with ICE/HIP instead if SIP-ICE? This is so self evident. Thanks, Henry On 7/12/11 10:02 AM, "Harald Alvestrand" <harald@alvestrand.no> wrote: > On 07/12/11 16:35, Stephan Wenger wrote: >> 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) > I'm all for "reasonable", but my "reasonable" may be different from > yours.... the sum of all requirements should indeed allow us to build > equivalents to Skype or Google Talk on top of this platform (except for > the parts that don't make sense, of course :-) ), but I find it easier > to talk about auto-zoom to keep head size constant (for instance - at > least one Skype beta supported that) as a separate use case, not merged > with the "basic use case". > >> Stephan >> >> >> On 7.12.2011 07:17 , "Harald Alvestrand"<harald@alvestrand.no> wrote: >> >>> On 07/12/11 13:58, Stefan Håkansson LK wrote: >>>>>> All, >>>>>> >>>>>> some comments to >>>>>> >>>>>> <http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requir >>>>>> ements/?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. >>> 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 >>> found. >>>> 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." >>> 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. >>>>> 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? >>> 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 >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Comments to use-cases/reqs document Stefan Håkansson LK
- Re: [rtcweb] Comments to use-cases/reqs document Harald Alvestrand
- Re: [rtcweb] Comments to use-cases/reqs document Stefan Håkansson LK
- Re: [rtcweb] Comments to use-cases/reqs document Harald Alvestrand
- Re: [rtcweb] Comments to use-cases/reqs document Stephan Wenger
- Re: [rtcweb] Comments to use-cases/reqs document Harald Alvestrand
- Re: [rtcweb] Comments to use-cases/reqs document Stephan Wenger
- Re: [rtcweb] Comments to use-cases/reqs document Henry Sinnreich
- Re: [rtcweb] Comments to use-cases/reqs document Dzonatas Sol