[apis] minutes - 10 July 2013

available at:
 http://www.w3.org/2013/07/10-webtv-minutes.html

also as text below.

Thanks for taking these minutes, Daniel!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                     Web and TV IG - Media APIs TF

10 Jul 2013

   [2]Agenda

      [2]
http://lists.w3.org/Archives/Public/public-web-and-tv/2013Jul/0006.html

   See also: [3]IRC log

      [3] http://www.w3.org/2013/07/10-webtv-irc

Attendees

   Present
          kaz, ddavis, CyrilRa, Bin_Hu, Sheau, Glenn,
          Sung_Hei_Kim, Wook_Hyun, Mark_Vickers

   Regrets
   Chair
          BIn_Hu

   Scribe
          ddavis

Contents

     * [4]Topics
         1. [5]Previous minutes
         2. [6]Action items
         3. [7]Use cases discussion
     * [8]Summary of Action Items
     __________________________________________________________

Previous minutes

   Bin_Hu: Any questions from the previous meeting minutes?
   ... No questions, so approving the previous meeting minutes.
   ... Next, reviewing action items.

Action items

   <inserted> [9]Action items

      [9] https://www.w3.org/2011/webtv/track/products/7

   Bin_Hu: 2 action items
   ... First, "giuseppe to share summary of the work of HNTF,
   suggest which current use cases have already been covered by
   past TFs and passed on to WGs"

   Bin_Hu: Due date for this action item is next week, so we can
   review it in the next call

   <scribe> ACTION: giuseppe to share summary of the work of HNTF,
   suggest which current use cases have already been covered by
   past TFs and passed on to WGs [recorded in
   [10]http://www.w3.org/2013/07/10-webtv-minutes.html#action01]

   <trackbot> Created ACTION-120 - Share summary of the work of
   HNTF, suggest which current use cases have already been covered
   by past TFs and passed on to WGs [on Giuseppe Pascale - due
   2013-07-17].

   Bin_Hu: Next action item is "kaz to ask the sys team to extend
   the time slot to 90 minutes"
   ... This has already been done so is now closed.
   ... Thank you Kaz.

   <kaz> action-119 closed

   <trackbot> Closed ACTION-119 Ask the sys team to extend the
   time slot (of Media APIs TF telcon) to 90 minutes.

Use cases discussion

   Bin_Hu: The goal of the Task Force is to analyse requirements
   for Web on TV.
   ... and what requirements have not yet been addressed.
   ... Then pass this info on to Working Groups.
   ... First, a summary of progress.
   ... We have put forward some use cases since May.
   ... One way to move forward is to compare our use cases with
   the Home Network use cases.
   ... Thanks to Olivier for his opinions on this.

   Bin_Hu: We also had a discussion with AT&T about how the use
   cases compare with HN use cases.
   ... There are some suggestions in the mailing list.
   ... We can extract requirements from the use cases, and then
   decide if they have been addressed.
   ... Requirements that have not been addressed are gaps which we
   can address.
   ... Important thing is to get consensus from this group to move
   forward.
   ... to be more effective in our final deliverables.

   Sheau: Are the use cases to be considered as a complete list or
   is it still open for others to be added?

   Bin_Hu: Personally, I think the use case list is never complete
   - it's always possible for others to be contributed.
   ... This will help with requirements and gap analysis.
   ... It's still in the early stage so I welcome requirements but
   also new use cases.

   Sheau: Thank you, I agree that they're never "finished".

   Bin_Hu: Any other questions/suggestions?
   ... We also have use cases contributed from ETRI
   ... Do you have any suggestions to move forward?

   skim13: What we're doing is good.
   ... I think we can continue like this.

   Bin_Hu: Back to today's work.
   ... Let's start trying to summarise the requirements from the
   use case list.

   <inserted>
   [11]http://lists.w3.org/Archives/Public/public-web-and-tv/2013J
   ul/0007.html

     [11]
http://lists.w3.org/Archives/Public/public-web-and-tv/2013Jul/0007.html

   Bin_Hu: What kind of requirements can be summarised from "Use
   Case One – Tablet Joins Home Network"

   Sheau: Can we assume that all devices are running HTML5
   compliant browsers?
   ... Without that assumption it's difficult to proceed.

   Bin_Hu: I agree, we should assume an HTML5 browser environment.
   ... This will become a more universal environment so personally
   I think we should assume this.
   ... We need content synchronisation and service discovery
   ability
   ... to have other devices be able to discover these services.
   ... But note that some services might be served from more than
   one device so we should have the ability to aggregate such
   content/services.
   ... This seems to me to be an obvious requirement.

   Sheau: Even the use case mentions a set-top box, does it really
   indicate multiple devices, e.g. multiple set-top boxes?
   ... There may be multiple STBs that give the impression of
   being one.

   Bin_Hu: That's a good question - we should leave it open to
   support multiple set-top boxes and multiple services.

   Sheau: Also, regarding the final two points, should we just say
   that there's a requirement for a service protocol ... ?

   Bin_Hu: I would think that instead of indicating a service
   protocol, we should indicate that there's a method for the
   synchronisation of the services and content.
   ... The reason being that there should be a function to
   synchronise, whereas a protocol may limit our thinking in terms
   of supporting this capability.
   ... We should leave it as open as possible.

   Sheau: My question was how the content service potentially fits
   in between the final two steps.
   ... There is authentication and authorisation to have content
   access. Is that something we should standardise? I don't think
   we should be silent.

   Bin_Hu: I think we should capture that requirement and even the
   requirement of content protection.
   ... On the other hand, those requirements may have been
   addressed already, but we should capture them first and find
   out.
   ... We should capture the requirements first and look for gaps.

   glenn: There are at least two specs already for authentication
   and authorisation. One is from Bell Labs and the other is OATC.
   ... They cover authentication, live metadata, tracking, etc. so
   it might be worth looking into these two.

   <CyrilRa> oatc.us

   Bin_Hu: I'll try to capture that later.
   ... Any other input?

   kaz: As you might know, the W3C MMI group will hold a workshop
   on 22nd and 23rd July in New York
   ... We'll talk about a standard protocol for device
   integration.
   ... Maybe the discussion will include requirements and use
   cases for this group, so if there's anything useful I'll bring
   it back to this group.

   <kaz> [12]MMI Workshop (FYI)

     [12] https://www.w3.org/2013/07/mmi/

   Bin_Hu: I'll try to summarise everything after this meeting so
   you'll have something to take to the workshop.

   kaz: Sheau will also be there.

   Bin_Hu: Let's move on the next use case - "Use Case Two – TV
   Triggers 2nd Screen"

   Sheau: Where is the content source from?

   Bin_Hu: The source is the set-top box.

   Sheau: Maybe at this point, are we thinking that the tablet and
   STB are communicating?
   ... e.g. to a common server?

   Bin_Hu: They may be communicating in a peer-to-peer level or
   through a server. This is not at a level for our requirements.

   Sheau: If we drill down from the use case, the function seems
   to be coordinating between the tablet and STB.
   ... So the STB and tablet are already communicating or is the
   function coming from the cloud?

   Bin_Hu: It's unclear to me at which moment we should such
   architectural models in the discussion.
   ... For now I would think that maybe a peer-to-peer
   communication also serves this communication function.
   ... So in this scenario, I'm not sure whether the requirements
   are based on the architectural model
   ... so we should keep it as open as possible at this stage.

   Sheau: OK. Until we need something, don't think ahead too much.
   ... so maybe some words in the use case are unnecessary, e.g.
   about the overlay.
   ... For example, maybe the user is not already running a
   particular application.

   ddavis: Like push notifications?

   Sheau: More expansive than that.

   Bin_Hu: So we have some requirements:
   ... 1. a method for the STB and tablet to communicate
   ... 2. synchronisation of content
   ... 3. a method to wake up the application on the user's
   device, e.g. tablet
   ... for example push or something more full-featured than
   simple push.
   ... The web application that receives the push, also needs to
   get push content so it needs two steps..
   ... One for the client to wake up and one to fetch content from
   the server.
   ... so this could be a gap for an existing push specification.
   ... Any other comments/suggestions?
   ... Moving on to the next use case - "Use Case Three – Tablet
   EPG"

   ddavis: The user should also be able to save for later - add to
   a queue.

   Bin_Hu: OK, I'll make a note of that.

   kaz: Is there specific time span for the EPG?
   ... For example, Japanese providers usually use just one week
   but sometimes we'd like to see longer, e.g. one month.

   Bin_Hu: Good question, I don't know.

   glenn: Usually two weeks, I think

   Sheau: How does that fit into this use case?

   kaz: Maybe we should extend the use case a bit to include such
   time span information.

   Bin_Hu: I understand. Most important is that this is
   context-based.
   ... Timestamp is one form of context.
   ... For when the provider provides an EPG or targeted
   entertainment.

   Sheau: The choice of movies would depend on many factors.
   ... They may be different depending on the time.
   ... Also there will probably be a personalisation filter.
   ... They are somewhat secondary.
   ... Probably out of scope for our discussion.
   ... Sorry - I have to leave now in time for my next meeting.

   Bin_Hu: I'll let you know after I've updated the document.
   ... The requirement is targeted entertainment based on, e.g.
   watching history, timestamp, local tradition, user profile,
   etc.
   ... with suggestions for the user.
   ... Any further suggestions or comments?
   ... OK, moving on to the next use case - "Use Case Four –
   Content Sharing"
   ... No comments?
   ... I can see a requirement that the user should be able to
   share a link/video in the way they choose.
   ... If it's an image, they might be able to share the content
   directly between devices.
   ... Also, authentication, authorization, content protection,
   maybe even payment could be supported.
   ... Maybe we'd need a payment API.

   ddavis: There is currently no API but there is a payment Task
   Force looking into it.

   Bin_Hu: Any other suggestions?
   ... Let's move on to the next use case - "Use Case Five –
   Content Search"
   ... Requirement from this is that the system should be able to
   communicate with the backend of search services.
   ... Second requirement is service/content aggregation
   ... so that the content provider can provide an aggregated list
   of content/services.
   ... Also, there should be some kind of parental control.
   ... or targeted content filtering.

   ddavis: Parental control can be combined with authentication
   ... because of the use of user profiles.

   ddavis: We should think about the connection period and whether
   there's a timeout.

   @@@: If the user is watching something in DVR mode and pauses,
   we should allow for that.

   scribe: A "life goes on" mode.

   Bin_Hu: I'll add that to the requirements.
   ... Thank you, that's helpful.
   ... Let's move on the next use case: "Use Case Six – Tuner
   Control thru Web Application"
   ... Maybe this is a chance for our colleagues in ETRI to help.

   skim13: We have reported this use case, based on the
   presentation shown at 2012 TPAC meeting.
   ... Web on TV needs to consider the Tuning APIs. We've been
   concentrating on these features.
   ... We need the web application to be able to control the
   tuner.
   ... [Reads use case:
   [13]http://www.w3.org/2011/webtv/wiki/Media_APIs/Use_Cases ]
   ... Any questions/comments?

     [13] http://www.w3.org/2011/webtv/wiki/Media_APIs/Use_Cases

   Bin_Hu: The use case addresses the ability of the subscriber to
   control the TV tuner through their application, e.g. using a
   tablet as a control device.
   ... Will the user be able to search for something in the EPG?

   skim13: We have been thinking that the TV is a web platform so
   with a mouse or pad, the user can get more detailed
   information.
   ... So the user can also search for what they want. Maybe with
   a tablet but we're thinking of a web-based TV environment.

   Bin_Hu: So the control device is a keypad like a Google TV
   controller?
   ... Like a remote keyboard.

   skim13: People will have a TV like a computer with the ability
   to control with a remote.

   Bin_Hu: Maybe there's the ability to pair the remote control
   e.g. with Bluetooth.
   ... Then the application can actually access the TV tuner.
   ... What kind of requirements are you thinking of?

   skim13: We're thinking of a local tuner URI
   ... And a channel ID for identification
   ... Also the TV stream itself should be accessible from within
   the TV browser itself.

   Bin_Hu: So I have three requirements...
   ... One is channel ID
   ... Two is support for TV stream within the browser
   ... Three is a tuner ID, but maybe this can be combined with
   the requirement for the channel ID.

   <Zakim> kaz, you wanted to ask about the difference based on
   countries (include country/area code as well?)

   kaz: Given that the TV stream is based on country, we need to
   think about that.
   ... E.g. Japanese has it's own ID system, other countries too.
   ... The URI system should consider that.

   Bin_Hu: So the TV channels need to be country or region based.
   ... Now the last use case - "Use Case Seven – Channel Bounded
   Applications"

   skim13: [talks through use case 7]

   Bin_Hu: The requirement seems to be context-based.
   ... The user needs to get content relevant to the context.
   ... For example, during a football game, getting extra info.
   ... Maybe authentication is needed again, to ensure trust.

   skim13: Mostly this context is controlled by the broadcast
   service provider.
   ... It's a channel-bound application.

   Bin_Hu: I'll try to capture as much as I can in a rough draft
   on the wiki, then I'll send the link to the group for people to
   review.
   ... Following that, we can have further discussion and maybe
   more use cases.
   ... So, we've gone over time. Let's finish up.

   <scribe> ACTION: Bin_Hu to create draft of the requirements for
   the group to read through and discuss. [recorded in
   [14]http://www.w3.org/2013/07/10-webtv-minutes.html#action02]

   <trackbot> Error finding 'Bin_Hu'. You can review and register
   nicknames at <[15]http://www.w3.org/2011/webtv/track/users>.

     [15] http://www.w3.org/2011/webtv/track/users%3E.

   Bin_Hu: Suggest that we adjourn for today - let's speak again
   in two weeks.
   ... and hopefully get feedback from the MMI workshop.
   ... Thanks, speak to you next time.

Summary of Action Items

   [NEW] ACTION: Bin_Hu to create draft of the requirements for
   the group to read through and discuss. [recorded in
   [16]http://www.w3.org/2013/07/10-webtv-minutes.html#action02]
   [NEW] ACTION: giuseppe to share summary of the work of HNTF,
   suggest which current use cases have already been covered by
   past TFs and passed on to WGs [recorded in
   [17]http://www.w3.org/2013/07/10-webtv-minutes.html#action01]

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [18]scribe.perl version
    1.138 ([19]CVS log)
    $Date: 2013-07-10 15:01:11 $

     [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [19] http://dev.w3.org/cvsweb/2002/scribe/