See also: IRC log
giuseppe: reviewing the agenda.
Going through the requirements, then the open issues to see
what we can finalize.
... Also the issue on listing services raised by Jan last
time.
... Any other point to the agenda?
russell: agenda item on F2F?
giuseppe: ok.
<giuseppep> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements
giuseppe: starts with common
text, abstract and introduction. Let me know if you have
comments there. Then use cases and requirements.
... As soon as we start approving use cases, we can capture
them in this document.
... After we are done with use cases, we can start extract
requirements for these use cases.
... One of the section in requirements will of course be
security and privacy.
... I looked at other requirements documents (e.g. Audio XG) to
build this one.
russell: Question on associating
tracker numbers.
... to mention them in the template
giuseppe: they may not start from
1.
... I'm not sure we need to keep track on that.
... The background discussion will be tracker on the Wiki. This
document will be converted to a pure HTML document in the
end.
... The results of the discussion should be captured in this
document.
russell: so this will be the index of use cases?
giuseppe: of approved use cases,
yes.
... other comments and discussions will be useful to provide
context and clarifications but do not need to appear in this
document
russell: ok.
giuseppe: pretty similar to what other groups are doing.
kaz: Wanted to mention there's some tool to convert tracker issues into nice HTML pages. If needed, we can use that as well.
giuseppe: not sure what the output will look like. Can you share a link?
kaz: Many working groups use
Tracker to handle last call comments. When that happens, we
need to generate a disposition of comments.
... I'll share a link to an example.
giuseppe: ok.
... If no other points, let's go on and have a look at use
cases.
<inserted> -> example of an HTML document generated by Tracker DB
<giuseppep> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/DiscoveredContentHost
jcd: very basic thing.
giuseppe: are there any comment
on the use case?
... If not, we can just accept it
russell: [sound chopped]
... What is the tracker number for the use case?
ISSUE-5?
<trackbot> ISSUE-5 -- Use Case: Discovered Content Host -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/5
<jcdufourd> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/DiscoveredContentHost
giuseppe: number 5
... Any comment on this?
kaz: meta comment. We should add a link back to tracker from the wiki
giuseppe: Right. I did it for some issues.
<kaz> [ just updated http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/DiscoveredContentHost#ISSUE-5:_Discovered_content_host ]
PROPOSED RESOLUTION: approve discovered content host and close issue-5
PROPOSED RESOLUTION: approve discovered content host use case and close issue-5
kaz: From a user viewpoint this may be too detailed a description.
giuseppe: I think this is enough to capture this kind of use cases, but do not have strong opinion.
kaz: maybe later we'll need to classify the types of use cases.
giuseppe: yes, we can do it later.
+1 to close ISSUE-5
RESOLUTION: approve discovered content host use case and close issue-5
close ISSUE-5
<trackbot> ISSUE-5 Use Case: Discovered Content Host closed
<giuseppep> ISSUE-4?
<trackbot> ISSUE-4 -- Use Case: Service User Interface -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/4
jcd: a bit more complex. It's about the service and the network remotely having a user interface as a document somewhere else.
<rberkoff> r berkoff comments posted on tracker - please cover!
jcd: [jcd going through use case description]
<kaz> [ just updated http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/DiscoveredContentHost#Discovered_content_host to use the same format as ISSUE-4 wiki ]
giuseppe: comments?
... Russell, your comment is that you'll propose a more
detailed use case.
... Do you have a deadline?
... Do you want a clarification of the text or an
extension?
russell: by next call, and more an extension.
giuseppe: ok, any other comments?
<scribe> ACTION: Russell to propose an extension of ISSUE-4 by 2011-05-17 [recorded in http://www.w3.org/2011/05/03-webtv-minutes.html#action01]
<trackbot> Created ACTION-25 - Propose an extension of ISSUE-4 by 2011-05-17 [on Russell Berkoff - due 2011-05-10].
jcd: is there a difference you can talk about already or not?
russell: let me review this use case again, having problems with this toolset.
giuseppe: ok, let's postpone
ISSUE-4 for now.
... We'll go through it next call or approve it offline.
<giuseppep> ISSUE-6?
<trackbot> ISSUE-6 -- Use Case: Document as a Service Provider -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/6
<kaz> [ just updated http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/ServiceProvider#Service_Provider with link to issue-6 ]
jcd: there, you have a document
as a provider of a service. A particular machine access to
something. For example, the machine is a TV set with Programme
guide information. That information can be displayed on the TV,
but there's no interface to display it on other devices.
... So a document running on the TV set could expose a service
and provide the programme guide information to other
devices.
... The way I describe it, the document is a windowless object
that responds to other requests.
... The document needs to be able to advertize itself, publish
its interface, and then respond to messages from
elsewhere.
... 3 functions.
giuseppe: one comment on this.
I'm not sure if two documents talking to each other is the same
thing as this use case as you suggest.
... Two documents talking to each other is already
possible.
... This use case is more complex than that.
... If the intent is more to post messages, then it would be
better to rephrase it.
jcd: the last part "respond to
messages" is indeed posting messages when documents are pages.
But the first two parts are not.
... A document may need to expose itself.
... Here publishing its interface means exposing the list of
messages that the document can respond to.
giuseppe: my first comment would
be to split this, because we might want to assign different
priorities to different things.
... One thing that is missing is the justification for this.
Exposing services is already covered by Web services in my
view.
... So, what's missing?
... Exchanging messages between two documents in two different
browsers on two different devices is missing, for instance.
russell: [question on relation
between use case and UPnP]
... I have the feeling that what is described here is outside
of regular UPnP usage
giuseppe: so basically, the implementation part is not good here.
jcd: Basically, everything in
there is implemented in UPnP and is interoperable with other
possibilities. So I suspect that my language is in cause here.
The first time that the TV set exposes itself as a device. It
does that but in the background, exposing the service within
the device.
... I felt this was too UPnP specific to fit in this
document.
russell: [comment on UPnP process scribe missed]
giuseppe: In the end, do we need to remove something from the use case? The possible implementation part for instance?
<Zakim> kaz, you wanted to wonder if we have to mention HbbTV specifically here
<scribe> ACTION: Jean-Claude to clarify in the text of ISSUE-6 that the document is acting as a device and split in more atomic use cases [recorded in http://www.w3.org/2011/05/03-webtv-minutes.html#action03]
<trackbot> Created ACTION-26 - Clarify in the text of ISSUE-6 that the document is acting as a device and split in more atomic use cases [on Jean-Claude Dufourd - due 2011-05-10].
kaz: In description section, you should probably describe the use case without mentioning existing solution such as HbbTV or UPnP.
giuseppe: In general, we should
avoid having any reference to existing technologies, unless
that's really part of the use case.
... I agree that it should be re-written into something that is
more neutral.
... ok, so action on Jean-Claude and then we can discuss it
again
<giuseppep> ISSUE-7?
<trackbot> ISSUE-7 -- Use case: Service Migration -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/7
jcd: document exposing a service
and a document moving across devices. I think that the title is
very bad actually.
... It's actually a document rendering discovered content, e.g.
media content. You want to move the document when a bigger
device becomes available (e.g. a tablet).
... You want a seamless migration.
... One implementation is through a regular server. If you
don't have a server, the second possibility is to put the
intelligence on the page itself.
... When you want to migrate from the phone to the tablet, the
page saves its state and transfers the content and the state to
the other device.
giuseppe: there was a discussion on this on the mailing-list and I also had a comment.
giuseppe: I think it's more appropriate to talk about services migration
jcd: the text describes document
moving and the title describes what you're suggesting. Document
moving is a simpler case.
... This use case should also be split into: document that
moves around and there's no service in the UPnP sense, and then
"service" moving which is more complex than the previous
one.
giuseppe: in this case, it's more content moving between HTML pages (video).
jcd: if there is a state, the simplest state I can think of being the position in a movie, you have to pass it around.
giuseppe: right, I guess you have to think about cookies as well.
russell: I think I understand the
scenario here.
... It involves an intermediary Web server.
giuseppe: it's one possible implementation, I think.
russell: I can share a link to the spec in CEA where this is described.
giuseppe: ok, I think I'm fine with the use case then.
jcd: would you like me to split it into document migration and service migration?
<scribe> ACTION: Jean-Claude to split ISSUE-7 into document migration and service migration [recorded in http://www.w3.org/2011/05/03-webtv-minutes.html#action04]
<trackbot> Created ACTION-27 - Split ISSUE-7 into document migration and service migration [on Jean-Claude Dufourd - due 2011-05-10].
kaz: maybe your description implies multiple state transition that includes several states each of them corresponds to a specific device
jcd: that's an interesting suggestion. I need to think about it.
giuseppe: ok, we'll get back to it next time then.
<giuseppep> ISSUE-8?
<trackbot> ISSUE-8 -- Use case: Service Distribution -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/8
jcd: Voting system on the TV set.
Multiple viewers in front of TV. Today, we have to use the
remote control and there's only one. Whereas viewers are likely
to have personal phones.
... So, the TV set sends a message to the phones and suggests
to activate a second document.
... The second document arrives and runs on the phone (with
user's approval)
... Then the document running on the TV set exposes itself as a
service and the document running on the phones discovers it (or
the opposite).
<kaz> [ just updated http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/ServiceDistribution#Service_Distribution with Issue ID ]
jcd: The user browses the
document on his phone. Once he votes, a message is sent to the
TV set and the document on the TV set collects the votes and
submits the votes.
... This use case suggests that a document gets suggested by
the TV set to other devices
giuseppe: Apart from the editorial comment to reword without specific reference to HbbTV, I think we should highlight the difference between this use case and the other ones.
jcd: if you just have a standard
for discovery, then you cannot do this.
... What you would need is something at a different level: you
need a standard distribution mechanism.
... Besides, the devices should expose themselves as possible
receivers.
giuseppe: I'd like to discuss offline what other use cases this use case depends on.
jcd: OK, I can clarify a bit the dependencies and highlight the difference.
kaz: this use case is very much like "second screen" use case. If this means second-screen use case it's probably fine to have them here. Then we can classify requirements later on.
giuseppe: ok, we'll come back to it.
<scribe> ACTION: Jean-Claude to clarify dependencies and differences on ISSUE-8 [recorded in http://www.w3.org/2011/05/03-webtv-minutes.html#action05]
<trackbot> Created ACTION-28 - Clarify dependencies and differences on ISSUE-8 [on Jean-Claude Dufourd - due 2011-05-10].
ISSUE-10?
<trackbot> ISSUE-10 -- 3-Box Model -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/10
clarke: not sure that this is
different enough from what Jean-Claude already proposed. This
is the 3-box model used in DLNA.
... It describes connections between the different
devices.
... I think it's similar to the Jean-Claude's Service User
Interface but not sure it covers it all.
giuseppe: it makes sense to keep
it as a separate use case.
... This one is more complex, Jean-Claude's one is more the
2-Box model.
... do we need more time to approve it?
kaz: does this imply more than 3?
clarke: I suppose you could send content to multiple renderers simultaneously. That's one possibility. But 3-Box is the minimum.
PROPOSED RESOLUTION: approve 3-Box Model use case and close ISSUE-10
+1
RESOLUTION: approve 3-Box Model use case and close ISSUE-10
<kaz> [ just added link to tracker to http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/3-box-model#3-Box_Model ]
close ISSUE-10
<trackbot> ISSUE-10 3-Box Model closed
giuseppe: I'll add it to the
Requirements document, then.
... I'm not sure we have time to go through remaining issues
and security concerns.
... I'd like to ask people to take some more time and comment
on this.
... We have to have some security and privacy requirements in
this document.
... Let's continue discussing on the mailing-list
giuseppe: for the home network TF, there's a proposal from Samsung to host a F2F in June
<giuseppep> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/FaceToFaceSchedule_2011
<giuseppep> Proposed: HNTF-F2F 14-16 June 2011 - Samsung Electronics - (USA) San Jose, CA (*updated*)
[several "ok" heard in the call]
giuseppe: if there's no objection
within a week, we can consider it approved.
... we're still discussing on the workshop, it probably won't
be before September.
... Anything else to discuss?
... Basically, we'll go over open issues in these calls. Next
time, we'll just go by number. So raise an issue if you want to
discuss something.
... Next call on the 17th but I'm not available.
... Can we move it?
... Either to next week or 24th?
russell: A short questionnaire to settle this?
giuseppe: yes, we can do
this.
... We'll decide on this during this week.
... AOB?
[Call adjourned]