See also: IRC log
<giuseppe> http://www.w3.org/2011/webtv/track/products/2
<giuseppe> ISSUE-20?
<trackbot> ISSUE-20 -- TV Querying and Control -- open
<trackbot> http://www.w3.org/2011/webtv/track/issues/20
<MattH> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/TVControl
matt: re-write proposal to better
explain what could be standardized.
... The processing engine could be incorporated or not.
... There were some questions I hope I've addressed.
giuseppe: comments on this?
... I don't have specific comments. I see different challenges.
One thing I noticed is that it does not follow the same
approach as other things we've discussed.
... Not a generic approach.
... On the use case, no problem it's fine.
... Any other comment, or can we conclude it's approved?
proposed RESOLUTION: approve ISSUE-20
RESOLUTION: approve ISSUE-20, TV Querying and Control
<scribe> ACTION: giuseppe to integrate ISSUE-20 in requirements spec [recorded in http://www.w3.org/2011/08/02-webtv-minutes.html#action01]
<trackbot> Created ACTION-58 - Integrate ISSUE-20 in requirements spec [on Giuseppe Pascale - due 2011-08-09].
<MattH> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/TimeSynchronisation
matt: Same here, re-wrote to
better explain what's up for standardization.
... Regarding the time sync use case, the idea is to make it
possible to be able to sync the content of their own app with
the content played on the TV set.
... I believe we briefly described the prototype during the
Berlin Workshop.
... Re-focusing is to highlight the fact that it's useful for
an app to have a simple and clear API to access this type of
information.
... It would be useful to have a high-level API that can enable
these kind of applications and that abstract away the possible
inconsistencies.
Russell: I object, the existing discovery protocol address these issues, so I believe it's out of scope.
matt: I was referring to the previous situation. In the new version, I refer to existing protocols that can be appropriate, so you're right.
Russell: ok.
giuseppe: comments on the content
of the issue?
... then we can approve this as well
RESOLUTION: Approve ISSUE-21, Time synchronization
<scribe> ACTION: giuseppe to integrate ISSUE-21 in requirements spec [recorded in http://www.w3.org/2011/08/02-webtv-minutes.html#action02]
<trackbot> Created ACTION-59 - Integrate ISSUE-21 in requirements spec [on Giuseppe Pascale - due 2011-08-09].
giuseppe: for some of these use cases, there could be an entity on the network that provides the service, so not necessarily a local API
<MattH> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/LipSyncTimeSynchronisation
<giuseppe> ISSUE-22?
<trackbot> ISSUE-22 -- Lip-sync Accuracy Time Synchronisation -- open
<trackbot> http://www.w3.org/2011/webtv/track/issues/22
matt: related but with emphasis
on needs for precise timing information, e.g. lip sync.
... The description here makes explicit the need to expose the
accuracy that is available so that an app can determine whether
it can do its stuff.
giuseppe: thanks, any comment on
this?
... OK, let's close this as well
kaz: Matt, are you interested in not only lip-sync but also 3D, or animation, audio frame, or other multiple modalities?
matt: I think these should be valid. We were more interested in audio at BBC, but I can see other purpose requiring accurate timing sync for other modality, yes.
RESOLUTION: Approve ISSUE-22, Lip-sync Accuracy Time Synchronisation
<scribe> ACTION: Giuseppe to integrate ISSUE-22 in requirements spec. [recorded in http://www.w3.org/2011/08/02-webtv-minutes.html#action03]
<trackbot> Created ACTION-60 - Integrate ISSUE-22 in requirements spec. [on Giuseppe Pascale - due 2011-08-09].
<giuseppe> ISSUE-23?
<trackbot> ISSUE-23 -- UPnP/DLNA ecosystem support -- open
<trackbot> http://www.w3.org/2011/webtv/track/issues/23
Russell: Issue-23 is a use case
to support the UPnP/DLNA ecosystem devices as-is within an
application.
... There are a large number of currently deployed UPnP/DLNA
devices, and having W3C user agents be able to support those
devices would be beneficial for both orgs as well as for
users.
giuseppe: you didn't write any use case, right?
russell: right.
... It's just to generate a requirement.
... There are specific use cases which are written later on,
but this is a specific use case to require UPnP/DLNA
support.
Giuseppe: no comment. Any comment?
Russell: I think there should be a requirement that maps to this issue.
Giuseppe: OK, I can find a way to integrate that in requirements spec.
RESOLUTION: Approve ISSUE-23, UPnP/DLNA ecosystem support
<scribe> ACTION: giuseppe to integrate ISSUE-23 in requirements spec. [recorded in http://www.w3.org/2011/08/02-webtv-minutes.html#action04]
<trackbot> Created ACTION-61 - Integrate ISSUE-23 in requirements spec. [on Giuseppe Pascale - due 2011-08-09].
kaz: comment on ISSUE-23. Clarify what you mean by W3C user agents?
Russell: there are conceivably user agents that may not be browsers but something else.
kaz: In that case, W3C specification compliant user agents. W3C does not produce user agents
Russell: yes.
See ISSUE-26
Russell: question is whether it's
enough to support various protocols, or whether we need to dig
up in types of services exposed and expose e.g. media
servers.
... [Going through requirements]. Requirement to list content
that matches precise criteria on a media server for instance.
Playback operation.
... View EPG data which may represent current content, also
tune and play live content, and then select and play recorded
content.
Giuseppe: back to ISSUE-26, any
comment?
... I don't think the use case is controversial.
... No problem with the use case itself.
... One problem I have with these use cases is that they all
look different.
... We might want to re-write them for more consistency.
Russell: I'm certainly willing to
help.
... I tried to make the use cases and requirements
consistent.
Giuseppe: ok.
RESOLUTION: Approve ISSUE-26, Home Network Enabled User-Agent - Network Media Player
<scribe> ACTION: Giuseppe to integrate ISSUE-26 in requirements spec [recorded in http://www.w3.org/2011/08/02-webtv-minutes.html#action05]
<trackbot> Created ACTION-62 - Integrate ISSUE-26 in requirements spec [on Giuseppe Pascale - due 2011-08-09].
See ISSUE-27
Russell: companion use case to
previous one, to be able to serve content.
... Media server not necessarily local, could be in the
cloud.
Giuseppe: there's a specific reference to DLNA in things to standardize.
Russell: I was just trying to
clarify what the term Home Network Media Transport Requirements
might entail.
... May I just change "mainly" into "possibly"?
... It was really just meant as a clarification.
... I'll go through the use case and take that out.
Giuseppe: ok, fine.
RESOLUTION: Approve ISSUE-27, Home Network Enabled User-Agent - Network Media Server
<scribe> ACTION: Giuseppe to integrate ISSUE-27 in requirements spec [recorded in http://www.w3.org/2011/08/02-webtv-minutes.html#action06]
<trackbot> Created ACTION-63 - Integrate ISSUE-27 in requirements spec [on Giuseppe Pascale - due 2011-08-09].
See ISSUE-28
Russell: provides more details
about what needs to be controlled on media that provides
rendering.
... including closed captioning, camera angles, etc.
Giuseppe: same as for ISSUE-27, DLNA mention remains.
Russell: Yes, I'll go through all of these issues and adjust the wording.
Giuseppe: ok, also approved, then.
RESOLUTION: Approve ISSUE-28, Home Network Enabled User-Agent - Network Media Controller
<scribe> ACTION: Giuseppe to integrate ISSUE-28 in requirements spec [recorded in http://www.w3.org/2011/08/02-webtv-minutes.html#action07]
<trackbot> Created ACTION-64 - Integrate ISSUE-28 in requirements spec [on Giuseppe Pascale - due 2011-08-09].
See ISSUE-29
Russell: different scenarios on controlling recorder, listed on the page.
Giuseppe: Comments?
... Approved.
RESOLUTION: Approve ISSUE-29, Home Network Enabled User-Agent - Network Record Controller
<scribe> ACTION: Giuseppe to integrate ISSUE-29 in requirements spec [recorded in http://www.w3.org/2011/08/02-webtv-minutes.html#action08]
<trackbot> Created ACTION-65 - Integrate ISSUE-29 in requirements spec [on Giuseppe Pascale - due 2011-08-09].
See ISSUE-30
Russell: Control of a device,
which we don't know anything about. There might be
provisioning, e.g. home network management services while
upgrading firmware. There's a whole slew of device types on top
of media related services.
... This is a use case to control all sorts of devices.
Giuseppe: given that this is generic, and that we already have approved generic use cases, does that add something?
Russell: we do have Igarashi-san
application use cases. But this is more control of non media
devices on the home network.
... Usage will become increasibly important.
Giuseppe: Yes, but requirements
already covered by other issue, I think.
... High-level versus low-level.
ISSUE-14?
<trackbot> ISSUE-14 -- Document Discovering a Service -- closed
<trackbot> http://www.w3.org/2011/webtv/track/issues/14
Giuseppe: The requirements doc is already updated to cover this.
Russell: I might suggest that
this gets merged with issue-14, provided there are no new
requirements.
... One question that I have in mind. Is a device or service in
these use cases the same as the device in the use case I'm
providing?
... I think Jean-Claude mentioned the definition of a device as
a list of services.
... I'm a little concerned about the definition section in the
requirements doc.
Giuseppe: it's for the scope of the document.
Russell: I think we'll have to discuss devices vs. services
Giuseppe: could you provide text for the requirements document?
<scribe> ACTION: Russell to see if ISSUE-14 and ISSUE-30 can be merged [recorded in http://www.w3.org/2011/08/02-webtv-minutes.html#action09]
<trackbot> Created ACTION-66 - See if ISSUE-14 and ISSUE-30 can be merged [on Russell Berkoff - due 2011-08-09].
giuseppe: it would be nice to
finish the document by the end of the month.
... I'll update it so that we can review it before the f2f
meeting and approve it during the meeting.
... The idea would be to publish the requirements document, and
then to add some section in the IG report about our
findings.
... What should we do with CableLabs draft proposal?
... We need to know what we're going to do with other documents
such as implementation alternatives.
Clarke: hard to understand you right now, let's do a phone call and come up with a plan or something.
Giuseppe: question, Clarke, is what should the group do with this?
Clarke: I'd like people to comment on it, see if it meets requirements.
<kaz> Wiki
<kaz> issue-38?
<trackbot> ISSUE-38 -- CableLabs Simplified Home Networking API Proposal -- open
<trackbot> http://www.w3.org/2011/webtv/track/issues/38
Clarke: Then look at this
proposal and the one from Opera, see if they can be
aligned.
... I'm working on an update to that document, which I can
publish in the next couple of days.
Giuseppe: [chunked], include in the report?
Clarke: yes, I'd like to resolve as many obvious divergences as possible and then include in the report.
Russell: I'm not necessarily favoring an API the way you propose [scribe missed precise concern]
Clarke: when something is
discovered, it calls a callback. I found it useful to combine
things, but you could have your user agent to do otherwise. The
basic idea of having discovery "routines" that calls a callback
is pretty generic and doesn't predict any specific
implementation.
... The same goes for request.
... If you want one callback for zeroconf, one for DLNA, etc.
that's fine.
Russell: something like REST call, does that require a callback?
Clarke: what happens is that you
send a message, and when you get a response, which is
asynchronous, the callback gets called. A single routine could
handle all your REST responses, or different routines could be
used.
... Still, you send a request, then get a response.
Russell: I might suggest that you write this in "here's the usage scenario" instead of providing an IDL, not very consistent with the way we've approaches other use cases.
Giuseppe: The goal is more to
capture how this could be implemented.
... It is not to become the specification, it's merely meant to
suggest how an API could be defined.
Russell: I suspect there is a use
case knocking around in this document. I would encourage the
writing of a use case based on this document. One concern is
what happens to one device discovered with different methods?
Is there a way to say that this is the same?
... I think it raises some interesting questions.
Clarke: It's one way to implement
the requirements triggered by the other use cases. It's
certainly not the only one.
... I'm uncertain how this should be communicated to any
working group that addresses these requirements.
Giuseppe: my view on this is that
we need to make sure the discussions are reflected on this
document, then we can decide to publish it along with the
requirements document to the intention of a working
group.
... If it's already covered by another document, e.g. by
Opera's proposal, then maybe we can drop it.
... We need to have opinions on this.
... The same applies to the Security document, actually.
Clarke: I'll try to write something that tries to align CableLabs and Opera's proposals.
Giuseppe: ok, running out of time, here.
[call adjourned]
<giuseppe> I hope you could hear what I was saying....
<giuseppe> I was using skype, next time I'll use the phone