- From: Francois Daoust <fd@w3.org>
- Date: Tue, 21 Jun 2011 22:29:44 +0200
- To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Hi all,
The minutes of today's Home Networking TF call are available at:
http://www.w3.org/2011/06/21-webtv-minutes.html
... and copied as raw text below. Many thanks, Jan, for taking minutes!
Issues 16 to 22 were discussed during the call.
Francois.
-----
21 Jun 2011
See also: [2]IRC log
[2] http://www.w3.org/2011/06/21-webtv-irc
Attendees
Present
Nilo_Mitra, francois, Giuseppe, Clarke, Jan_Lindquist, MattH,
DongHyun_Kang, aizu, Bob_Lund, Igarashi, Narm, jcdufourd
Regrets
Chair
Giuseppe
Scribe
JanL
Contents
* [3]Topics
1. [4]ISSUE-16 - Web and Device Interworking
2. [5]ISSUE-17 - Home Network Enabled User-Agent
3. [6]ISSUE-18 - Video tag support of MPEG2-TS
4. [7]ISSUE-19 - Media Identification
5. [8]ISSUE-20 - TV Querying and Control
6. [9]ISSUE-21: Time synchronisation
* [10]Summary of Action Items
_________________________________________________________
<giuseppep> [11]http://www.w3.org/2011/webtv/track/products/2
[11] http://www.w3.org/2011/webtv/track/products/2
start the open issues
ISSUE-16 - Web and Device Interworking
question to jan on issue-16
waiting for response from author of issue-17
ISSUE-17 - Home Network Enabled User-Agent
issue-17 ongoing discussions
in mailing list
so waiting for some conclusion
ISSUE-18 - Video tag support of MPEG2-TS
it will be moved to the new Media Pipeline TF
<francois> ACTION: giuseppe to move ISSUE-18 to MPTF [recorded in
[12]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].
ISSUE-19 - Media Identification
<giuseppep> ISSUE-19?
<trackbot> ISSUE-19 -- Media Identification -- raised
<trackbot> [13]http://www.w3.org/2011/webtv/track/issues/19
[13] 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.
ISSUE-20 - TV Querying and Control
<giuseppep> ISSUE-20?
<trackbot> ISSUE-20 -- TV Querying and Control -- raised
<trackbot> [14]http://www.w3.org/2011/webtv/track/issues/20
[14] 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
[15]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].
ISSUE-21: Time synchronisation
<giuseppep> ISSUE-21?
<trackbot> ISSUE-21 -- Time synchronisation -- raised
<trackbot> [16]http://www.w3.org/2011/webtv/track/issues/21
[16] 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.
Summary of Action Items
[NEW] ACTION: giuseppe to move ISSUE-18 to MPTF [recorded in
[17]http://www.w3.org/2011/06/21-webtv-minutes.html#action01]
[NEW] ACTION: Matt to check ISSUE-20 in relation with ISSUE-4 and
propose re-phrasing if needed. [recorded in
[18]http://www.w3.org/2011/06/21-webtv-minutes.html#action02]
[End of minutes]
Received on Tuesday, 21 June 2011 20:30:18 UTC