Re: [HOME_NETWORK_TF] Some comments on the open issues

Dear François, all,

On 6/6/11 14:35 , Francois Daoust wrote:
> On 06/03/2011 05:14 PM, Giuseppe Pascale wrote:
>> ** 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.
>
> Details in ISSUE-7 may help emphasise that:
>  1/ some vocabulary is needed to describe existing service connections 
> as part of an execution context

JCD: the text is there (second bullet):

"When moving the radio document, the following needs to be preserved:

    * the service needs to be restarted and exposed on the new device
    * the connection to the (same) radio controller needs to be
      reestablished
    * the radio needs to be playing the same station, with the same
      volume, etc."



>  2/ user permissions can be part of the execution context 
> (re-connection between the device that acts as remote control and the 
> migrated service does not require another user validation). This could 
> help discover security holes, as the weakest HNTF UA in a network of 
> HNTF UA that support migration could potentially become a risk for the 
> whole local network: once a device manages to hack a connection with 
> the weakest HNTF UA in a network, it can then migrate this connection 
> to other HNTF UAs without the user's explicit consent. That probably 
> isn't such a big deal though as the user remains the one who initiates 
> the migration, normally.
>
> So it may be useful to keep both use cases separated, although we 
> probably do not need such a detailed use case here.
> (the description of the radio service could perhaps be re-used in 
> other more generic use cases actually, it's clear and visual!)
>
JCD: I have changed the description because it confused the issue: now 
the radio app has NO UI, all the UI is in the controller, so that e.g. 
the radio app could reside on a device without a screen. The previous 
description was too computer-oriented.

The added value of this use case is indeed:
- the connection as part of the execution context
- the validation by the author of the connection as part of the 
execution context as François points.

Best regards
JC

-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144