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

From: Harald Alvestrand <[email-masked]>
Date: Mon, 11 Jul 2011 16:17:43 +0200

Just one comment-on-comment:

On 06/29/11 12:50, Stefan Håkansson LK wrote:
> 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.

4.2.4.2.  Derived Requirements

    F22 ( It SHOULD be possible to modify video codec parameters during a
    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.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 12 Jul 2011 13:58:56 +0200

>    browser to change the resolution of the video Alice sends to match
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.
>    F22 ( It SHOULD be possible to modify video codec parameters during a
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"
>   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
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 12 Jul 2011 16:17:08 +0200

On 07/12/11 13:58, Stefan Håkansson LK wrote:
> 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.
> 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.

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 12 Jul 2011 07:35:51 -0700

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)
Stephan

On 7.12.2011 07:17 , "Harald Alvestrand" <[email-masked]> wrote:

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 12 Jul 2011 17:02:45 +0200

> 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"<[email-masked]>  wrote:
>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 12 Jul 2011 08:09:20 -0700

That's fine, but then you need to add at least one more use case:
point-to-point, and not quite simple...
Stephan

On 7.12.2011 08:02 , "Harald Alvestrand" <[email-masked]> wrote:

>>>>>><http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requ
>>>>>>ir
>>>>>> ements/?include_text=1>
>>>>>>
>>>>>>
>>>>>>
>>>>>      negotiate a high resolution video.  Bob decides to change the
>>>>>size
>>>>> of
>>>> But my preference is not strong - I'm happy to reinsert the use case
>>>>if
>>>> people think so.

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 12 Jul 2011 10:56:21 -0500

+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

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 12 Jul 2011 10:23:15 -0700

The crystal radio is "not quite simple" if we use standard memory 
technology (or hard-ware version).

Given signal-to-noise, the maximal fractal surface may seem to be the 
union of point-to-point. That is falsifiable, the millisecond is not 
unless one proves one. ASCII presents "the choice" to support that. 
Standard? "Not my business."

The event horizon for real-time appears only simulated (by us), and I 
like the religions topics on this, for science by science.

For example,

We could express: millisecond := <square>alpha+beta</square>

We could write that with MathML, yet the published MathML is not in 
plain English, enough. Reason? Maybe. How do you know if that means 
"square root of the value of alpha plus beta" or "alpha squared plus 
beta squared, and that the square root of that value". Which quote is in 
present tense? The obvious.

The constance is the power of two, a magic number in computer science, 
yet for mathematics, a real number? 1 + 1.

Elementary support for that number? Some say not their business.

Let's revisit the scale factor of affine transformations: 
http://mathworld.wolfram.com/AffineTransformation.html

How would re-write that equation to remove the magic numbers in order to 
have the pure scalar value? Replace the first two and last two with 
"alpha" and "omega", and format with XML to MathML.

Is the truth, the pure scalar value, of two relative to the affine 
transformation by Wolfram? Ballard's method is E=mcc, so not always. 
Mathematicians think relative to "Energy equals mass times speed of 
light to the power of two."

Use-case for "real-time": law of two.

On 07/12/2011 08:09 AM, Stephan Wenger wrote:
> On 7.12.2011 08:02 , "Harald Alvestrand"<[email-masked]>  wrote:
>
>    
>>>> On 07/12/11 13:58, Stefan H�kansson LK wrote:
>>>>          
>>>>>>> All,
>>>>>>>
>>>>>>> some comments to
>>>>>>>
>>>>>>>

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant