Re: [HOME_NETWORK_TF] Some comments on the open issues

Many thanks for your comments Giuseppe,

I agree with your suggestion to cap the time spent discussing scenarios  
during the teleconference.

Some responses regarding your comments on the use cases I submitted:

On Fri, 03 Jun 2011 16:14:19 +0100, Giuseppe Pascale <>  

> ** Media identification (ISSUE-19)
> I agree that the use cases is a valid one but I have few question:
> - isn't this already implicitly included in the use cases listed above?
> - is the use cases only about being able to query a unique identifier  
> for content/programs or also about standardize this identifier?

It is not clear to me which other use case you feel already addresses this  
- perhaps you refer to the Service User Interface use case?

Yes, this use case aims to demonstrate a need for an identifier to be  
standardised to some degree. It is necessary for the scenario described  
that such an idenifier for a programme has meaning outside of the scope of  
the device serving or presenting that programme. For example, a home media  
storage device could allocate its own self-generated identifiers to  
distinguish one item of content from another; but such identifiers do not  
allow association with any other content outside of the domain of that  

For a simple remote control application, it is sufficient to be able to  
use identifiers to only distinguish one programme from another; and to  
associate them with metadata such as programme title, scheduled broadcast  
time, file size and format, etc. But if that application wishes to relate  
a programme to content available from an external source (such as a web  
service on the internet) then if the only identifier available is locally  
assigned as just described, it would not be possible to do this. The  
scenario described in the use case needs to be able to do this.

That standardisation could be quite lightweight - as described in the  
implementation notes of the use case - using URI style schemes to allow  
different parties to still use their own schemes of identifiers, but  
subsumed within a namespace, so that they can be distinguished from the  
scheme being used by another party.

> ** TV Querying and Control (ISSUE-20)
> This seems to be the same as Issue-4, even though issue-4 is probably  
> too generic while this give one particular example of control. I'm not  
> sure how we should handle these usecases, if we should keep both, only  
> the generic one or only the specific ones. IMO we should keep both


> ** Time Synchronisation (ISSUE-21)
> Looks fine to me. Same comment as above apply (generic vs specific)
> ** Lip-Sync accuracy Time Synchronisation (ISSUE-22)
> Looks fine to me. Same comment as above apply (generic vs specific)

I would be happy to merge the use cases if there is agreement that this is  
appropriate. What is important for me is that the scenario that  
exemplifies the use case is still supported.

I believe it is important to capture these scenarios since it has been  
established in previous discussions that simply enabling access to UPnP  
services that exist and are documented at this moment in time, does not  
support this. I believe the TF's aim is to identify where work needs to be  
done (either in the W3C or elsewhere) to enable services combining Web and  
TV - and so this has to be informed by scenarios for actual usage.

Perhaps issue-20, merged with 21 and 22 could be extended to cover any of  
the scenarios briefly mentioned in ISSUE-4 relating to specific types of  
devices to be controlled? Or separate issues could be raised to cover each  
of them?


| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London

Received on Friday, 3 June 2011 16:01:55 UTC