RE: [HOME_NETWORK_TF] Some comments on Home Network Enabled User-Agent use cases

Giuseppe,

I think your change is good – we do not have enough information to know what aspects of media transport need to be exposed to Web content but I do agree with Russell that there may be such cases. So the path you propose is a reasonable compromise.

Bob

From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-request@w3.org] On Behalf Of Giuseppe Pascale
Sent: Tuesday, August 16, 2011 4:39 AM
To: Web and TV Interest Group WG; Russell Berkoff
Subject: Re: [HOME_NETWORK_TF] Some comments on Home Network Enabled User-Agent use cases

Russell, Bob,
comments inline


On Tue, 16 Aug 2011 09:26:04 +0200, Russell Berkoff <r.berkoff@sisa.samsung.com<mailto:r.berkoff@sisa.samsung.com>> wrote:

My comments are around some text, common to several ISSUEs (ISSUE-26, ISSUE-27,ISSUE-28, ISSUE-29).

#1 "Provide extensions to HTML5 <video>, <audio> elements to allow HTML5 to comply with Home Network Media Transport Requirements (mainly transport protocol specific headers)"

I think the expression "Home Network Media Transport Requirements" is pretty vague and also the term "provide extensions" seems misleading. Maybe this part could be rephrased with something like "Provide a mean to support additional transport specific headers"
[Russell Berkoff]
This will probably need some work. This phrase includes requirements for a number of  header-mediated transport behaviors:

1.      The header contains a “command” for the server. For example the header tells the server to serve-up the content at 2x normal rate, or the header tells the server to position the content at 1:00:00.

2.      The header contains information for the web-page. The header indicates the available speeds that the server can serve the content at. Or the header indicates alternate language tracks for the content.

3.      The header contains information for the client’s user-agent playback engine. The header contains information about the content profile (beyond simple mime-types) so the playback function can correctly parse the content stream.


Many of these headers are already in use in deployed products.

I'm not saying there is no need for this, but that there text above doesn't give any clue to what is actually needed. As you said you need to go into details so we have 2 options:
- you details all the use cases and extract specific needs. This require time and is probably a bit out of scope in this first phase.
- we rephrase the test to point out that some more analysis work may be needed.

Taking into account also Bob comment I would propose the following rephrasing:

"Provide a mean for applications to control some of the parameters that may be needed to be expose to support well-established home network protocols. A more detailed analysis is needed to identify such parameters and a way to specify them in a transport agnostic way"

Feel free to propose a better wording (if you agree with the idea behind it)


#2 "Also, provide backward-compatible extensions to previous HTML versions to support similar functionality (presumably as browser-plugins)."
I think this is out of scope and should be removed. This is a product problem not a specification problem.
[Russell Berkoff]
We should  try to provide backward compatibility if possible. At the minimum we should be cognizant that HTML5 content will be consumed by earlier systems. If web-pages can adapt to this then all the better.
I'm still not clear what this will be in practice, i.e. which requirement would it generate. So I still think we should remove it.


#3 "Allow pages to control future Home Network device classes where the comand sets are not currently known."
I think this should be removed as well. I cannot see how we could extract requirement or define a specification to comply with future and unknown requirements. Of course having a flexible architecture that is future proof is a good design goal (and I can add it as such to the requirement document) but I don't think it can be a requirement.
[Russell Berkoff]
Others do this. The UPnP core model (UDA) is based around some basic services for discovery, network variables, and eventing. The model has proven quite robust and extensible allowing it to support a wide variety of current and future devices without substantial modification. For example:  the difference between HTML <object> and <video> elements. The <object> element allows a lot of things including non-video plugins allowing all sorts of user-agent extensions.  The <video> element only knows about video. Now the <video> element is under “pressure” to support a bunch of additional behaviors. The requirement is to insure the facilities we include are generic and robust enough address future requirements. ISSUE-30 includes some potential future usages.

If you need to support general purpose and not well defined extensions, HTML 5 already provides a list of extensions mechanisms
http://dev.w3.org/html5/spec/infrastructure.html#extensibility


IMO we need to try to focus on concrete use cases and recommendations that are not too vague and can be followed up by a WG, otherwise our suggestion will not generate the outcome that we all expect to get.

/g


cheers,
/g










--
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

--
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden


--
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden