Re: [HOME_NETWORK_TF] About Service Migration (ISSUE-7) and Document Migration (ISSUE-15)

On 24/5/11 17:57 , Giuseppe Pascale wrote:
> Hi JC,
> during last call we touched on two of your usecases Service Migration 
> (ISSUE-7) and Document Migration (ISSUE-15).
> There were some comments from several participants that would require 
> some actions from you.
> I'll try to summarize the main issues here so you can act on them.
> (I would like to ask everybody to point out in case I fail to list all 
> the pointed out issues)
JCD: Looking at the minutes, that's about it :)

> - for both usecases (and actually for all of them) would be better to 
> use the word "application" rather then document (see also related 
> discussion on the list)
> Since I'm going to add a definition of application, basically similar 
> to the html5 definition of document, you don't need to clarify in your 
> usecase the term.
JCD: I have changed the vocabulary in all my use cases.

> - for ISSUE-7 (and in general for any usecase you or anyone else will 
> provide) would be better to provide a more detailed description of one 
> particular scenario you have in mind with the steps that the user 
> would have to do to cover that particular use case. So would be good 
> if you could do for ISSUE-7 what you have done for ISSUE-15 (i.e. step 
> by step description). You have actually called it "implementation" but 
> I think that as far as you don't mention any specific technology (if 
> not part of the use case of course) that can be safely part of the 
> description itself.
JCD: OK, done.

> Furthermore someone was concerned about the particular example you 
> make since it was not clear how a moving service could still work when 
> it is highly dependent from a platform capability. So if you could 
> provide a more detailed, step by step, usecase that would be great.
JCD: Well, obviously, when the user chooses to migrate an application 
which uses audio, she needs to choose a target device with audio, or the 
migration will fail.
If you want migrations to be always successful, we need a capabilities 
One possible implementation could be:
- the application metadata includes a dependency on an audio system.
- when migration is requested and the migrating UA has a list of 
possible targets, it needs to filter from that list the ones without an 
audio system.
- then the user is only offered a choice of targets where the 
application will definitely run.
I could generate a use case for this if there is interest.

> - as also captured in the notes for ISSUE-15, the are 2 possible sub 
> usecases that can be considered here, one that involve a web server 
> and one that it does not (widget). Since it seems that what you are 
> looking at is the second one (widget) is probably better to make this 
> explicit.
JCD: There is always a web server involved. The web server which serves 
the context information always exists. But either it is a centralized 
server, in the home or on the Internet, or the web server is the HNTF UA 
which sends the migration requests, à la UPnP presentationURL.
Best regards

> Generic comment: we decided to split the requirement document into 
> high level usecases and low level usecases. I think I have a pretty 
> good understanding of the high level usecases (based on the discussion 
> so far) so I will try to list them into the requirement document 
> myself (then people can review it). Would be better then from now on 
> if we focus on more specific and user centric usecase, like it could 
> be your "voting" example since different services may imply very 
> different requirements for a specification to cover.
> /g

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

Received on Wednesday, 25 May 2011 12:54:47 UTC