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> Action items

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 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> 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> MMI Workshop (FYI)

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: http://www.w3.org/2011/webtv/wiki/Media_APIs/Use_Cases ]
... Any questions/comments?

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 http://www.w3.org/2013/07/10-webtv-minutes.html#action02]

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

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.