RE: Review of scenarios doc (Jan 19 version)

I've updated the MediaStream capture scenarios doc as noted below.

>-----Original Message-----
>From: Harald Alvestrand [mailto:harald@alvestrand.no]
>
>I have gone through the scenarios doc (version of Jan 19, sorry for not
>updating), and have some comments. This is transcribing from my
>marked-up copy, so forgive me for commenting in serial order rather than
>in order of importance.
>
>Overall, I'm happy with the document as it stands!
>
>- Section 1, scope: I think that you should not claim that networking
>scenarios are out of scope for this task force, rather they should be
>included by reference; what comes out of the task force must satisfy
>both the scenarios described here and the scenarios described in the
>WebRTC scenarios doc.

Removed. The intro now only excludes declarative capture.


>- Section 2.1: Permisssions - you are assuming, both here and in the
>other scenarios, that ask-before-use is the only possible permission
>mechanism. This is not aligned with draft-ietf-rtcweb-security-01
>section A.3.2, where a means of granting permanent access to a
>particular service is a MUST. This is to avoid training the user to
>"always click through", which is a perennial problem with security dialogs.

I spread the permissions models around among the scenarios so that they are not always the same prompt-before-use technique. Now using prompt, pre-approval, no notice, and "activation" for variety.



>- Section 2.2 Election podcast - you don't specify whether the recording
>is happening locally or at a server. These alternatives might be
>mentioned under "Variations" - the Hangouts On Air service is very close
>to the proposed service, and does recording at server.

This was intended to be local to the client; I've now specified it as such. I'm not comfortable putting a scenario in place that involves server-size capture. Frankly servers can do whatever they want with the media stream and only need to know the low-level details of how the media stream works in order to accomplish that. Those details (I believe) are out of scope--at least for capture scenarios (they feel like a protocol-level spec).


>- Section 2.3 Find the ball - if you really want low resolution, 640x480
>might not be a good example.

Now 320x200. 243,200 fewer pixels to examine :-)


>- Section 2.4 Video diary - one thing I was thinking while reading this
>was Picture-in-Picture approaches - which would feed directly into
>manipulation functions on the stream while it is being recorded. Perhaps
>mention under Variations?

I like this scenario. Added as variation 2.4.1.2.



>- Section 2.4 Conference call product debate - this seems like a
>videoconference scenario with a recorder. You might want to point to the
>RTCWEB videoconference scenarios (with or without server) for discussion
>about non-recording concepts.

You're referring to this?
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-06

Rather than call out to this doc in a one-off location, I now link to it in the introduction.


>- Section 4 Concepts:
>Stream: I suggest you don't define "Stream". That word is used entirely
>too much, with too many meanings. Just don't use it. The text can be
>moved under MediaStream.

I care more about the conceptual understanding of Stream as described in the text. I moved that text under the following definition and removed the "Stream" definition.
 

>Virtualized device: I think this section mixes up the concept of
>shareable devices and devices which have manipulatable state. We can
>have shareable cameras and non-shareable microphones. I suggest finding
>two terms here.

I tried to separate the concepts. This change had a down-stream effect on section 5.2.1#3, and 5.8 (3rd paragraph).


>- Section 5.5: Applying pre-processing doesn't require the UA to do it
>if the UA provides a means of presenting a media stream in a known
>format on a known interface, and consume the media stream again after
>transformation that can be done outside the UA. Implementations that do
>this have been demonstrated (face recognizers in JS, for instance).

You missed the point. If the UA provides a means of access to the media
stream in a known format on a known interface, then that interface itself
is a media stream sink, and now you're talking about a post-processing 
scenario. I updated the second paragraph of 5.5 to make that more clear.


>- Section 5.6.3 Examples. If the canvas functions defined here work
>today, that should be made clear. It's not easy to see now whether these
>are real examples or suggestions for future extensions.

I'm not sure that it matters much. I added a note saying that these are all 
based on W3C draft specifications (to my knowledge, none of these have reached
Recommendation status), and many of them are implemented.


>- Section 5.7.1 Privacy. The *developer* is probably not the term you're
>looking for here about who information is exposed to; the developer is
>not involved when an application runs. You might be thinking about the
>application.

Corrected that. Thanks.

Received on Wednesday, 8 February 2012 21:06:03 UTC