RE: [HOME_NETWORK_TF] Priorities for requirements

I agree with Matt's relative priorities with exceptions noted inline below.

Bob Lund

> -----Original Message-----
> From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-
> request@w3.org] On Behalf Of Matt Hammond
> Sent: Monday, August 22, 2011 2:06 AM
> To: Giuseppe Pascale
> Cc: public-web-and-tv@w3.org
> Subject: [HOME_NETWORK_TF] Priorities for requirements
> 
> Hi Giuseppe, here is my perspective on the relative priorities of
> requirements.
> 
> Some stand out as a common requirement that underpin everything else.
> These would seem obvious candidates to be high priority. Specifically:
> 
> ... Security considerations (for applications, users and content):
> 
>      1.7.5.1 Application trust level
I see this as secondary priority. If a low-level API is provided by the UA then this will have to be solved at JS which is an issue beyond the scope of the HNTF.

>      1.7.5.2 Access to home network services
>      1.7.5.3 Prevent leaking of information
I see this as secondary priority. If a low-level API is provided by the UA then this will have to be solved at JS which is an issue beyond the scope of the HNTF.

>      1.7.3.8 Content Protection
I see this as a DRM issue, not HNTF.
> 
> ... And the basics of discovery of services and content:
> 
>      1.7.2.1 Service Discovery
>      1.7.2.2 Content Discovery
>      1.7.2.3 Content Players Discovery
>      1.7.2.6 Media Identification
This may be out of scope if a low-level API is provided by the UA.
> 
> I believe Media Identification should be considered a higher priority.
> It is a prerequisite for applications to be able to properly relate
> items of media content to a wider web of data/content. This was at the
> core of most of the BBC's second screen scenarios and demos described in
> Berlin.
> 
> These alone are insufficient to fulfill most of the use cases and user
> scenarios identified. The use cases that seem most straightforward to
> address next and which also show the most immediate utility are those
> that support the ability to control and query media playback:
> 
>      1.7.1.1 Compatibility with widely deployed standards
>      1.7.3.1 Control of content players
>      1.7.3.2 Playback of content
>      1.7.3.3 Playback of live content
>      1.7.3.4 3 Box model
>      1.7.3.5 Time-synchronization
While I understand this is viewed as a very important feature, I think the control protocol to exchange time synchronization information and the application logic to make use of this information are both outside the scope of HNTF.
> 
> The requirements listed above focus on enabling applications to utilise
> existing home network services.  The remaining requirements all enable
> use cases and scenarios that are of great interest, but could be
> considered a "next step" of making it possible for applications to
> advertise and/or offer services. I therefore would consider these to be
> of lower priority.
> 
>      1.7.2.5 Services Advertisement
I see this as high priority. If you don't have service advertisement I don't see how one does service discovery.

>      1.7.2.4 Content Advertisement
>      1.7.3.7 Application communication
>      1.7.4.1 Push migration
>      1.7.4.2 Pull migration
> 
> Going for high accuracy time synchronisation enables a smaller set of
> scenarios than achieving some less precise degree of time
> synchronisation.
> It is also probably harder to do well. I'd also class this as lower
> priority.
> 
>     1.7.3.6 Accurate time-synchronization
> 
> regards
> 
> 
> Matt
> --
> | Matt Hammond
> | Research Engineer, BBC R&D, Centre House, London
> | http://www.bbc.co.uk/rd/

Received on Monday, 22 August 2011 15:47:22 UTC