[HOME_NETWORK_TF] Minutes - 21 June 2011

Hi all,

The minutes of today's Home Networking TF call are available at:

... and copied as raw text below. Many thanks, Jan, for taking minutes!

Issues 16 to 22 were discussed during the call.


21 Jun 2011

    See also: [2]IRC log

       [2] http://www.w3.org/2011/06/21-webtv-irc


           Nilo_Mitra, francois, Giuseppe, Clarke, Jan_Lindquist, MattH,
           DongHyun_Kang, aizu, Bob_Lund, Igarashi, Narm, jcdufourd




      * [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

    <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

    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

    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

    <trackbot> Created ACTION-41 - Check ISSUE-20 in relation with
    ISSUE-4 and propose re-phrasing if needed. [on Matt Hammond - due

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

    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

    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

    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

    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

    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

    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

    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
    [NEW] ACTION: Matt to check ISSUE-20 in relation with ISSUE-4 and
    propose re-phrasing if needed. [recorded in

    [End of minutes]

Received on Tuesday, 21 June 2011 20:30:18 UTC