See also: IRC log
<giuseppep> http://www.w3.org/2011/webtv/track/products/2
start the open issues
question to jan on issue-16
waiting for response from author of issue-17
issue-17 ongoing discussions
in mailing list
so waiting for some conclusion
it will be moved to the new Media Pipeline TF
<francois> ACTION: giuseppe to move ISSUE-18 to MPTF [recorded in http://www.w3.org/2011/06/21-webtv-minutes.html#action01]
<trackbot> Created ACTION-40 - Move ISSUE-18 to MPTF [on Giuseppe Pascale - due 2011-06-28].
<giuseppep> ISSUE-19?
<trackbot> ISSUE-19 -- Media Identification -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/19
Matt explains use case is to define a mechanism to identify a content on a global level. This allows for different applications to identify the content universally. BBC wants to augment the content shown on the screen. The application can query to know what content is being presented. There is an interest when a service from BBC is being presented.
Giuseppe says it is simply a URL. Response is that there is a good support for carrying identifying with the content.
Clarke asks how this information is carried. Response: broadcasters would carry the information. Bob states that track carries metadata. CableLabs is working on a content identifier that could be used for a solution. This could be carried as metadata track to pass this information. Matt is not familiar with this approach. Additional question: this is a home networking service, so a device can query another device what content you are playing. Response yes, a identifier can query after this identifier.
Clarke asks if this is pull or push based? Response: the identifier is waiting for the identifier.
Giuseppe says that what is needed is not a hardware requirement but a way to retrieve the identifier, together with a standard url that every application can understand. Response: yes, not an api is needed but simply a scheme.
Clarke says different from a guide you would get the program event and not what you see in the epg. Response clarifies. One can query based on the time and date after the information. Response is yes.
jcd: need to understand what needs to be standardized
basically need to identify the tecknology and next to identify the syntax.
another comment, earlier discussion how do we expose home network protocols to Web protocols, to other services.
This is categorized as new service set. upnp has mechanism to retrieve a service to query. It is a mechanism using upnp service to perform query.
<francois> [One requirement derived from this use case could perhaps be: any API function that takes content identifiers as arguments must accept URIs as content identifiers]
Based on the requirements we can decide how to go in the next step. The way forward is to list what can be standardized and touch on it next time.
<giuseppep> ISSUE-20?
<trackbot> ISSUE-20 -- TV Querying and Control -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/20
Use case is about implement application and service desire to control integrated TV or STB and control own changing chanels and getting epg info. This is both a rendered and presenter like a TV with built in ...
Similar with use cases from issue-4 Service User Interface. Also overlap with ISSUE-17.
Listing of how to request playback media. The tv can be controlled by a device. Does this add something more? It adds controlling content from a device that does not render or stream.
Giuseppe says it is pretty clear that it can be a service or a device, what do u think?
Matt can understand the logic.
Giuseppe proposes that Matt propose an amendment to issue-4, check issue-4 for clarification then we can close the issue.
Matt does not mind, if things are consistent.
issue-17 may list specific service that should be possible
Francois says that perhaps this example is pretty good to understand issue-4.
Proposal is to just send a rephrasing of issue-4, people can reply and amend it.
<francois> ACTION: Matt to check ISSUE-20 in relation with ISSUE-4 and propose re-phrasing if needed. [recorded in http://www.w3.org/2011/06/21-webtv-minutes.html#action02]
<trackbot> Created ACTION-41 - Check ISSUE-20 in relation with ISSUE-4 and propose re-phrasing if needed. [on Matt Hammond - due 2011-06-28].
<giuseppep> ISSUE-21?
<trackbot> ISSUE-21 -- Time synchronisation -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/21
This is defining specific forms of application. The idea is the ability to determine if a UA can be co-timed with another application.
Fine with the use case. How does this apply to other use case? Can any mechanism be used to enable this type of use case?
Probably there can be an arch that can support this but in some cases it is not possible, which will add complications on the design.
Do we have a widely used protocol or mechanism to enable this?
Based on discussions on mailing list that existing technology to support this that can present live content. Reference an integrated receiver.
Propose to resolve this on the mailing list. Olivier and Russel mentioned ieee synchronization. Are those well established protocols to support this?
Assignment of ntp for precision, probably other service protocols use it. We could indeed count that there are technolodgy to support this interesting use case.
Support this scenario adds this requirement to do something for synch.
Onto ptp
Igarashi mentions general comment about service standard and some protocol needed between applications, some discovery protocol. Discussion for the working group.
Requirement issue. If we discuss requirement we should specify the protocol to be used. In a Working Group they will discuss further the protocol, we can "mention" the protocol, but are there well established protocols? Maybe we do not need to specify it.
We need to derive requirements that should be standardized, the working group will continue on that based on req.
What is answer for this specification? Different ways to support this. In general we ensure the UA can (missed) the protocol can be standardized
Seems if we are talking about Web content to sync timing with content, between Web apps. If UA should support this then it is a different discussion.
Question about interoperability, do we need to specify a standard? The application needs to say what protocol to do time synchronization, to tell that application support this. Not clear that the standard is required for interoperability. If we have a standard for a web content to invoke home network service the standard is requirement for applications to access the API. The API does not need to know the time sync.
JanL: the last comment was interesting. Is it the UI of the Web Application? In the realm of Web application, it touches upon ISSUE-24. Can we do that between Web application that could resolve timing constraints?
Just exchange information, Just talking about applications. The question if it is just exchanging information. The intention of the use case was application to sync with non applications, like media player. This may look like a application issue. In terms of req we should specify req the use case of application.
Without an application framework this use case cannot be achieved.
What is the requirement? Syncmay need something specific and different from what we have. An idea is some message sync delivered async. This should be separate. 2 requirements. If protocol that we use sync protocol, we define a message application exchange. Part of objective is to expose to web content.
upnp or bonjour are as they are. Not supported in soap or REST. It would affect the underlying protocol... or not.
When we want 2 web applications to exchange messages, this could be a hw req, this could be an almost realtime comm
<jcdufourd> I suspect that this sync requirement will need some specific implementation, different from e.g. sending a simple async message. There could be a need for synchronous message, or extra-fast message, or message to another browser rather than to another web application... Hence my opinion we should keep the use case
Francois mentions Web Real-Time Communications WG, set to work to enable applications to exchange video as well as non A/V content (datagrams) in real-time. Will address some of these issues.
Giuseppe wonders, talking about real time, once this work is done, whether we should address it in another working group. Indeed, precisely in that working group since the rtc charter lists Web and TV IG in list of liaisons because we knew this would be useful to address some 2nd screen scenarios. Good idea to send requirements to Web RTC group.
we can revisit the issue once we know what can be standardized. If underlying platform supports time sync, expose this thing if the protocol underlying suports it.
how do we move forward? Proposal to do the usual strategy that we come back next time after discussion on mailing-list. Good way forward. Same question on issue-22. Discuss in mailing list 21 and 22.
We reached issue-22, the next one is 23. We can start on issue-23 next week. Call should be closed now.
Giuseppe notes that he will be away the next 4 weeks. Francois and Kaz will moderate.