RE: [HOME_NETWORK_TF] Priorities for requirements

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

Bob Lund

> -----Original Message-----
> From: [mailto:public-web-and-tv-
>] On Behalf Of Matt Hammond
> Sent: Monday, August 22, 2011 2:06 AM
> To: Giuseppe Pascale
> Cc:
> 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):
> 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.

> Access to home network services
> 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.

> Content Protection
I see this as a DRM issue, not HNTF.
> ... And the basics of discovery of services and content:
> Service Discovery
> Content Discovery
> Content Players Discovery
> 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:
> Compatibility with widely deployed standards
> Control of content players
> Playback of content
> Playback of live content
> 3 Box model
> 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.
> Services Advertisement
I see this as high priority. If you don't have service advertisement I don't see how one does service discovery.

> Content Advertisement
> Application communication
> Push migration
> 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.
> Accurate time-synchronization
> regards
> Matt
> --
> | Matt Hammond
> | Research Engineer, BBC R&D, Centre House, London
> |

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