Re: [HOME_NETWORK_TF] Some comments on the open issues

On Sun, 05 Jun 2011 14:24:26 +0200, Russell Berkoff  
<> wrote:

> Giuseppe,

> I would certainly welcome the (chairs) proactively managing the agenda.
> However, I have concerns about the TF not systematically covering issues  
> raised on use cases. I don’t think open-calls for comments on submitted  
> use cases during a teleconference is particularly effective given  
> comments were previously submitted.
In fact comments would be better submitted over email.
I think most of the W3C groups work this way;

Maybe other people on this list working with other WGs can share their  

> I would encourage the chairs to reconsider using "modern" collaboration  
> tools which insure all participants are looking at the same content and  
> allow comments to be captured and tracked within the documents.
If you have a concrete proposal for better procedures and tools feel free  
to make it and this group (all of us) will evaluate it.

 From a W3C PoV, any tool that does not require some sort of fee and work  
across systems should be fine.


> Regards,
> Russell Berkoff
> -----Original Message-----
> From: Giuseppe Pascale []
> Sent: Friday, June 03, 2011 8:14 AM
> To: Jean-Claude Dufourd; Russell Berkoff; Matt Hammond
> Cc:
> Subject: [HOME_NETWORK_TF] Some comments on the open issues
> Hi all,
> here my comments on some of the open issues, feedbacks (from everybody)  
> are welcome.
> Note that to avoid to only touch on 1/2 use cases in each telco, I would  
> like during next telcos not to spend more than 10/15 minutes per usecase.
> This means we will have to do the rest of the discussion over email, and  
> hopefully use telcos for final discussion and approval.
> What do you think about this approach? please let me know, I'm open for  
> any suggestion that allow us to get more work done.
> ** Service User Interface (ISSUE-4)
> As we have discussed few times, this could overlap with ISSUE-17 (UPnP)  
> if that use cases is rephrased, but it could also be a superset of it.
> We can either approve it as is and later decide to drop it if the  
> outcome of ISSUE-17 is generic enough to cover this or we can wait with  
> this until
> ISSUE-17 is solved.
> @JC, Russel, any opinion on this?
> **  Service Migration (ISSUE-7)
> I think this use case is valid, but there seems to be still a lot of  
> confusion around it.
> Can people point out what is missing and how can it be clarified?
> Maybe one way could be to point out explicitly that there are 2 way to  
> implement this use cases
> - with a central server (in the home) where to store the state of the  
> Service to be able to resume it later on--> this can be done already, so  
> out of scope
> - without a central server (e.g. a Widget),so you need to migrate both  
> the "content" /hmlt/js/images) and the state from one device to another.  
> This is in scope.
> On the other end, I'm also wondering it we really need this use case, or  
> if this is already implied by having Application Migration + Application  
> Exposing a service.
> Does an application exposing a service that migrates add more  
> requirements compared to a "simple" application that migrates? Note that  
> the an application that migrates still have a state to preserve, and  
> since we don't define what "state" is, it could also be the state of the  
> service.
> ** Service Distribution (ISSUE-8)
> This looks fine to me, even though as you say the only additional  
> requirement of the use case (compared to the others) is to be able to  
> push services rather then discover services.
> Probably good to extend with few more words the "Need/justification:"
> section of the template
> ** Application Exposing a Service (ISSUE-12) Looks fine to me
> ** Application Responding to Requests (ISSUE-13) Is this really needed  
> as a separate use case? Isn't this part of the "expose a service" and  
> "discover a service" usecase?
> ** Application Discovering a Service (ISSUE-14) Looks fine to me
> ** Application Migration (ISSUE-15)
> Also for this maybe is worth mentioning that there are 2 ways to support  
> this Usecase,
> - central server (e.g. your TV) so that you can "log out" from one  
> device and "log in" in another device and keep the state; this doesn't  
> seem to require any additional technology so is not in the scope.
> - the application is a local application (e.g. widget) so you need to  
> move both the application and the state.
> Maybe you could even rewrite this use case to explicitly and solely  
> mention the "local" applications, since for application served by a HN  
> web server there is no need for a migration functionality.
> ** 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?
> ** 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)
> ** UPnP / DLNA Home Network Enabled User-Agent (ISSUE-17)
> @Russell,
> did you had a look at JC rephrasing in the discussion page?
> Is probably a good starting point.
> I don't have a strong opinion about keeping everything in one use cases  
> vs splitting them up. I would prefer to have at list a split between  
> "The User-Agent commands other home network devices" and "The User-Agent  
> acts as a HomeNetwork device.", but no need to go more fine grain than  
> this.
> Note also that some of the usecases described overlap with some of JC's  
> ones (e.g. Device Discovery), so if we approve this we can probably drop  
> the others (or vice versa)
> /g
> --
> Giuseppe Pascale
> TV & Connected Devices
> Opera Software - Sweden

Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Tuesday, 7 June 2011 11:21:26 UTC