IRC log of webtv on 2013-07-10

Timestamps are in UTC.

13:09:35 [RRSAgent]
RRSAgent has joined #webtv
13:09:35 [RRSAgent]
logging to
13:09:41 [kaz]
scribenick: ddavis
13:09:53 [ddavis]
Bin_Hu: Any questions from the previous meeting minutes?
13:10:00 [cc]
cc has joined #webtv
13:10:15 [ddavis]
Bin_Hu: No questions, so approving the previous meeting minutes.
13:10:27 [ddavis]
... Next, reviewing action items.
13:10:45 [skim13]
Wook Hyun(whyun) is with me (skim13)
13:11:02 [Zakim]
13:11:06 [ddavis]
Bin_Hu: 2 action items
13:11:27 [ddavis]
... 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"
13:11:43 [kaz]
s/Sung Hei Kim/Sung Hei Kim with Wook Hyun/
13:12:16 [kaz]
13:12:18 [ddavis]
Bin_Hu: Due date for this action item is next week, so we can review it in the next call
13:12:33 [ddavis]
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
13:12:34 [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].
13:12:50 [ddavis]
Bin_Hu: Next action item is "kaz to ask the sys team to extend the time slot to 90 minutes"
13:12:58 [ddavis]
... This has already been done so is now closed.
13:13:03 [ddavis]
... Thank you Kaz.
13:13:29 [ddavis]
Bin_Hu: The goal of the Task Force is to analyse requirements for Web on TV.
13:13:42 [ddavis]
... and what requirements have not yet been addressed.
13:13:50 [ddavis]
... Then pass this info on to Working Groups.
13:14:00 [ddavis]
... First, a summary of progress.
13:14:09 [ddavis]
... We have put forward some use cases since May.
13:14:16 [kaz]
i/2 action items/topic: Action items/
13:14:30 [kaz]
i|2 action items|-> Action items|
13:14:31 [ddavis]
... One way to move forward is to compare our use cases with the Home Network use cases.
13:14:39 [ddavis]
... Thanks to Olivier for his opinions on this.
13:14:50 [kaz]
action-119 closed
13:14:50 [trackbot]
Closed ACTION-119 Ask the sys team to extend the time slot (of Media APIs TF telcon) to 90 minutes.
13:15:14 [ddavis]
Bin_Hu: We also had a discussion with AT&T about how the use cases compare with HN use cases.
13:15:21 [ddavis]
... There are some suggestions in the mailing list.
13:15:37 [ddavis]
... We can extract requirements from the use cases, and then decide if they have been addressed.
13:15:51 [kaz]
rrsagent, make log public
13:15:55 [ddavis]
... Requirements that have not been addressed are gaps which we can address.
13:15:55 [kaz]
rrsagent, draft minutes
13:15:55 [RRSAgent]
I have made the request to generate kaz
13:16:05 [Zakim]
+ +31.62.252.aaff
13:16:10 [ddavis]
Bin_Hu: Important thing is to get consensus from this group to move forward.
13:16:24 [ddavis]
... to be more effective in our final deliverables.
13:16:55 [ddavis]
Sheau: Are the use cases to be considered as a complete list or is it still open for others to be added?
13:17:14 [ddavis]
Bin_Hu: Personally, I think the use case list is never complete - it's always possible for others to be contributed.
13:17:17 [kaz]
i/Any questions from the previous meeting minutes/topic: Previous minutes/
13:17:49 [ddavis]
Bin_Hu: This will help with requirements and gap analysis.
13:18:09 [Mark_Vic_]
Mark_Vic_ has joined #webtv
13:18:33 [ddavis]
... It's still in the early stage so I welcome requirements but also new use cases.
13:18:39 [kaz]
rrsagent, draft minutes
13:18:39 [RRSAgent]
I have made the request to generate kaz
13:18:49 [ddavis]
Sheau: Thank you, I agree that they're never "finished".
13:18:54 [ddavis]
Bin_Hu: Any other questions/suggestions?
13:19:23 [ddavis]
... We also have use cases contributed from Italy
13:19:41 [ddavis]
... Do you have any suggestions to move forward?
13:19:54 [ddavis]
whyun: What we're doing is good.
13:20:00 [ddavis]
... I think we can continue like this.
13:20:19 [ddavis]
Bin_Hu: Back to today's work.
13:20:51 [ddavis]
... Let's start trying to summarise the requirements from the use case list.
13:21:08 [ddavis]
13:21:34 [kaz]
13:21:44 [CyrilRa]
CyrilRa has joined #Webtv
13:21:56 [kaz]
s/from skim13/from Italy/
13:22:53 [ddavis]
Bin_Hu: What kind of requirements can be summarised from "Use Case One – Tablet Joins Home Network"
13:23:30 [ddavis]
Sheau: Can we assume that all devices are running HTML5 compliant browsers?
13:23:58 [ddavis]
... Without that assumption it's difficult to proceed.
13:24:23 [ddavis]
Bin_Hu: I agree, we should assume an HTML5 browser environment.
13:24:49 [ddavis]
... This will become a more universal environment so personally I think we should assume this.
13:25:03 [ddavis]
s/from Italy/from ETRI/
13:25:19 [kaz]
i|What kind of||
13:25:29 [kaz]
rrsagent, draft minutes
13:25:29 [RRSAgent]
I have made the request to generate kaz
13:26:09 [ddavis]
Bin_Hu: We need content synchronisation and service discovery ability
13:26:21 [ddavis]
... to have other devices be able to discover these services.
13:27:06 [ddavis]
... But note that some services might be served from more than one device so we should have the ability to aggregate such content/services.
13:27:15 [ddavis]
... This seems to me to be an obvious requirement.
13:27:21 [kaz]
i/The goal of the Task Force is to analyse requirements for Web on TV/topic: Use cases discussion/
13:27:23 [kaz]
rrsagent, draft minutes
13:27:23 [RRSAgent]
I have made the request to generate kaz
13:27:39 [Mark_Vickers]
Mark_Vickers has joined #webtv
13:27:54 [ddavis]
Sheau: Even the use case mentions a set-top box, does it really indicate multiple devices, e.g. multiple set-top boxes?
13:28:33 [ddavis]
... There may be multiple STBs that give the impression of being one.
13:28:52 [ddavis]
Bin_Hu: That's a good question - we should leave it open to support multiple set-top boxes and multiple services.
13:30:02 [ddavis]
Sheau: Also, regarding the final two points, should we just say that there's a requirement for a service protocol ... ?
13:30:36 [ddavis]
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.
13:31:23 [ddavis]
... The reason being that there should be a function to synchronise, whereas a protocol may limit our thinking in terms of supporting this capability.
13:31:34 [ddavis]
... We should leave it as open as possible.
13:32:12 [ddavis]
Sheau: My question was how the content service potentially fits in between the final two steps.
13:32:16 [kaz]
13:33:14 [ddavis]
... There is authentication and authorisation to have content access. Is that something we should standardise? I don't think we should be silent.
13:33:31 [ddavis]
Bin_Hu: I think we should capture that requirement and even the requirement of content protection.
13:34:28 [ddavis]
... On the other hand, those requirements may have been addressed already, but we should capture them first and find out.
13:34:49 [ddavis]
... We should capture the requirements first and look for gaps.
13:35:26 [ddavis]
glenn: There are at least two specs already for authentication and authorisation. One is from Bell Labs and the other is OITC.
13:35:48 [ddavis]
... They cover authentication, live metadata, tracking, etc. so it might be worth looking into these two.
13:36:22 [ddavis]
13:36:26 [CyrilRa]
13:36:54 [CyrilRa]
13:37:31 [ddavis]
Bin_Hu: I'll try to capture that later.
13:37:37 [ddavis]
... Any other input?
13:37:41 [kaz]
13:37:54 [ddavis]
ack kaz
13:38:12 [ddavis]
kaz: As you might know, the W3C MMI group will hold a workshop on 22nd and 23rd July in New York
13:38:22 [ddavis]
... We'll talk about a standard protocol for device integration.
13:38:42 [ddavis]
... 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.
13:38:48 [kaz]
-> MMI Workshop (FYI)
13:39:04 [ddavis]
Bin_Hu: I'll try to summarise everything after this meeting so you'll have something to take to the workshop.
13:39:21 [ddavis]
kaz: Sheau will also be there.
13:40:13 [ddavis]
Bin_Hu: Let's move on the next use case - "Use Case Two – TV Triggers 2nd Screen"
13:41:50 [ddavis]
Sheau: Where is the content source from?
13:41:58 [ddavis]
Bin_Hu: The source is the set-top box.
13:42:18 [ddavis]
Sheau: Maybe at this point, are we thinking that the tablet and STB are communicating?
13:42:31 [ddavis]
... e.g. to a common server?
13:43:21 [ddavis]
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.
13:44:08 [ddavis]
Sheau: If we drill down from the use case, the function seems to be coordinating between the tablet and STB.
13:44:32 [ddavis]
... So the STB and tablet are already communicating or is the function coming from the cloud?
13:45:01 [ddavis]
Bin_Hu: It's unclear to me at which moment we should such architectural models in the discussion.
13:45:22 [ddavis]
... For now I would think that maybe a peer-to-peer communication also serves this communication function.
13:46:12 [ddavis]
... So in this scenario, I'm not sure whether the requirements are based on the architectural model
13:46:23 [ddavis]
... so we should keep it as open as possible at this stage.
13:46:54 [ddavis]
Sheau: OK. Until we need something, don't think ahead too much.
13:47:32 [ddavis]
... so maybe some words in the use case are unnecessary, e.g. about the overlay.
13:48:18 [ddavis]
... For example, maybe the user is not already running a particular application.
13:48:49 [ddavis]
ddavis: Like push notifications?
13:48:55 [ddavis]
Sheau: More expensive than that.
13:49:03 [ddavis]
Bin_Hu: So we have some requirements:
13:49:13 [ddavis]
... 1. a method for the STB and tablet to communicate
13:49:16 [kaz]
Present: kaz, ddavis, CyrilRa, Bin_Hu, Sheau, Glenn, Sung_Hei_Kim, Wook Hyun
13:49:20 [kaz]
Meeting: Web and TV IG - Media APIs TF
13:49:30 [ddavis]
... 2. synchronisation of content
13:49:31 [kaz]
rrsagent, draft minutes
13:49:31 [RRSAgent]
I have made the request to generate kaz
13:49:44 [ddavis]
... 3. a method to wake up the application on the user's device, e.g. tablet
13:49:47 [Sheau]
13:49:55 [kaz]
Chair: BIn_Hu
13:49:58 [kaz]
rrsagent, draft minutes
13:49:58 [RRSAgent]
I have made the request to generate kaz
13:50:01 [ddavis]
... for example push or something more full-featured than simple push.
13:50:31 [ddavis]
... The web application that receives the push, also needs to get push content so it needs two steps..
13:50:57 [ddavis]
... One for the client to wake up and one to fetch content from the server.
13:51:21 [ddavis]
... so this could be a gap for an existing push specification.
13:51:36 [ddavis]
... Any other comments/suggestions?
13:52:18 [ddavis]
... Moving on to the next use case - "Use Case Three – Tablet EPG"
13:55:01 [ddavis]
ddavis: The user should also be able to save for later - add to a queue.
13:55:12 [ddavis]
Bin_Hu: OK, I'll make a note of that.
13:55:16 [kaz]
13:55:22 [ddavis]
ack kaz
13:55:34 [ddavis]
kaz: Is there specific time span for the EPG?
13:55:57 [ddavis]
... For example, Japanese providers usually use just one week but sometimes we'd like to see longer, e.g. one month.
13:56:06 [ddavis]
Bin_Hu: Good question, I don't know.
13:56:24 [ddavis]
glenn: Usually two weeks, I think
13:57:39 [ddavis]
Sheau: How does that fit into this use case?
13:58:14 [ddavis]
kaz: Maybe we should extend the use case a bit to include such time span information.
13:58:30 [ddavis]
Bin_Hu: I understand. Most important is that this is context-based.
13:58:38 [ddavis]
... Timestamp is one form of context.
13:59:08 [ddavis]
... For when the provider provides an EPG or targeted entertainment.
13:59:20 [kaz]
zakim, who is here?
13:59:20 [Zakim]
On the phone I see skim13, Kazuyuki, ddavis, CyrilRa, Bin_Hu, sheau, glenn, Mark_Vickers, +31.62.252.aaff
13:59:22 [Zakim]
On IRC I see Mark_Vickers, Mark_Vic_, cc, RRSAgent, glenn, Sheau, Bin_Hu, ddavis, whyun, skim13, Zakim, kaz, trackbot, timeless, sangwhan
13:59:28 [kaz]
Present+ Mark_Vickers
13:59:34 [kaz]
rrsagent, draft minutes
13:59:34 [RRSAgent]
I have made the request to generate kaz
13:59:42 [ddavis]
Sheau: The choice of movies would depend on many factors.
13:59:52 [ddavis]
... They may be different depending on the time.
14:00:06 [ddavis]
... Also there will probably be a personalisation filter.
14:00:18 [ddavis]
... They are somewhat secondary.
14:00:28 [ddavis]
... Probably out of scope for our discussion.
14:00:49 [kaz]
zakim, mute me
14:00:49 [Zakim]
Kazuyuki should now be muted
14:01:03 [ddavis]
Sheau: Sorry - I have to leave now in time for my next meeting.
14:01:20 [ddavis]
Bin_Hu: I'll let you know after I've updated the document.
14:01:25 [Zakim]
14:02:06 [ddavis]
Bin_Hu: The requirement is targeted entertainment based on, e.g. watching history, timestamp, local tradition, user profile, etc.
14:02:18 [ddavis]
... with suggestions for the user.
14:02:46 [ddavis]
... Any further suggestions or comments?
14:03:24 [ddavis]
Bin_Hu: OK, moving on to the next use case - "Use Case Four – Content Sharing"
14:04:45 [ddavis]
... No comments?
14:05:18 [ddavis]
... I can see a requirement that the user should be able to share a link/video in the way they choose.
14:05:43 [ddavis]
... If it's an image, they might be able to share the content directly between devices.
14:06:01 [ddavis]
... Also, authentication, authorization, content protection, maybe even payment could be supported.
14:06:30 [CyrilRa]
CyrilRa has joined #Webtv
14:06:58 [ddavis]
... Maybe we'd need a payment API.
14:07:23 [ddavis]
ddavis: There is currently no API but there is a payment Task Force looking into it.
14:07:40 [ddavis]
Bin_Hu: Any other suggestions?
14:08:03 [ddavis]
... Let's move on to the next use case - "Use Case Five – Content Search"
14:09:49 [Zakim]
14:09:53 [ddavis]
... Requirement from this is that the system should be able to communicate with the backend of search services.
14:10:13 [ddavis]
... Second requirement is service/content aggregation
14:10:18 [Zakim]
14:10:34 [ddavis]
... so that the content provider can provide an aggregated list of content/services.
14:10:56 [ddavis]
... Also, there should be some kind of parental control.
14:11:32 [ddavis]
... or targeted content filtering.
14:11:51 [ddavis]
glenn: Parental control can be combined with authentication
14:11:59 [ddavis]
... because of the use of user profiles.
14:12:03 [glenn]
14:12:12 [ddavis]
\me sorry!
14:12:34 [glenn]
14:12:35 [ddavis]
s/\me sorry!//
14:13:42 [ddavis]
ddavis: We should think about the connection period and whether there's a timeout.
14:14:30 [ddavis]
@@@: If the user is watching something in DVR mode and pauses, we should allow for that.
14:14:47 [ddavis]
... A "life goes on" mode.
14:15:02 [ddavis]
Bin_Hu: I'll add that to the requirements.
14:15:33 [ddavis]
... Thank you, that's helpful.
14:15:52 [ddavis]
... Let's move on the next use case: "Use Case Six – Tuner Control thru Web Application"
14:16:14 [ddavis]
... Maybe this is a chance for our colleagues in ETRI to help.
14:16:38 [ddavis]
whyun: We have reported this use case, based on the presentation shown at 2012 TPAC meeting.
14:17:03 [ddavis]
... Web on TV needs to consider the Tuning APIs. We've been concentrating on these features.
14:17:13 [ddavis]
... We need the web application to be able to control the tuner.
14:17:18 [kaz]
14:18:03 [ddavis]
skim13: [Reads use case: ]
14:21:11 [ddavis]
... Any questions/comments?
14:21:56 [ddavis]
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.
14:22:08 [ddavis]
... Will the user be able to search for something in the EPG?
14:22:42 [ddavis]
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.
14:23:10 [ddavis]
... So the user can also search for what they want. Maybe with a tablet but we're thinking of a web-based TV environment.
14:23:25 [ddavis]
Bin_Hu: So the control device is a keypad like a Google TV controller?
14:23:42 [ddavis]
... Like a remote keyboard.
14:24:03 [ddavis]
skim13: People will have a TV like a computer with the ability to control with a remote.
14:24:28 [ddavis]
Bin_Hu: Maybe there's the ability to pair the remote control e.g. with Bluetooth.
14:24:43 [ddavis]
... Then the application can actually access the TV tuner.
14:24:45 [kaz]
q+ to ask about the difference based on countries (include country/area code as well?)
14:24:56 [ddavis]
... What kind of requirements are you thinking of?
14:25:18 [ddavis]
skim13: We're thinking of a local tuner URI
14:25:41 [ddavis]
... And a channel ID for identification
14:26:00 [ddavis]
... Also the TV stream itself should be accessible from within the TV browser itself.
14:26:30 [ddavis]
Bin_Hu: So I have three requirements...
14:26:34 [ddavis]
... One is channel ID
14:26:45 [ddavis]
... Two is support for TV stream within the browser
14:26:46 [kaz]
14:27:03 [ddavis]
... Three is a tuner ID, but maybe this can be combined with the requirement for the channel ID.
14:27:16 [kaz]
ack k
14:27:17 [Zakim]
kaz, you wanted to ask about the difference based on countries (include country/area code as well?)
14:27:22 [ddavis]
ack kaz
14:27:45 [ddavis]
kaz: Given that the TV stream is based on country, we need to think about that.
14:27:56 [ddavis]
... E.g. Japanese has it's own ID system, other countries too.
14:28:02 [ddavis]
... The URI system should consider that.
14:28:31 [ddavis]
Bin_Hu: So the TV channels need to be country or region based.
14:29:07 [ddavis]
... Now the last use case - "Use Case Seven – Channel Bounded Applications"
14:29:56 [ddavis]
skim13: [talks through use case 7]
14:30:01 [Zakim]
14:31:39 [ddavis]
Bin_Hu: The requirement seems to be context-based.
14:32:12 [ddavis]
... The user needs to get content relevant to the context.
14:32:26 [ddavis]
... For example, during a football game, getting extra info.
14:32:59 [ddavis]
... Maybe authentication is needed again, to ensure trust.
14:33:28 [ddavis]
skim13: Mostly this context is controlled by the broadcast service provider.
14:33:35 [ddavis]
... It's a channel-bound application.
14:34:24 [ddavis]
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.
14:34:42 [ddavis]
... Following that, we can have further discussion and maybe more use cases.
14:35:07 [ddavis]
... So, we've gone over time. Let's finish up.
14:35:36 [ddavis]
Action: Bin_Hu to create draft of the requirements for the group to read through and discuss.
14:35:36 [trackbot]
Error finding 'Bin_Hu'. You can review and register nicknames at <>.
14:36:02 [ddavis]
Bin_Hu: Suggest that we adjourn for today - let's speak again in two weeks.
14:36:20 [ddavis]
... and hopefully get feedback from the MMI workshop.
14:36:27 [Zakim]
14:36:29 [Zakim]
14:36:30 [ddavis]
... Thanks, speak to you next time.
14:36:35 [Zakim]
14:36:41 [Zakim]
14:36:47 [skim13]
skim13 has left #webtv
14:37:47 [Zakim]
14:37:53 [ddavis]
rrsagent, generate minutes
14:37:53 [RRSAgent]
I have made the request to generate ddavis
14:38:31 [whyun]
whyun has joined #webtv
14:39:11 [ddavis]
FYI: I'll finish off the minutes tomorrow (Japan time) as Kaz would like to make some manual edits to them.
14:39:48 [Bin_Hu]
Thanks Daniel
14:40:53 [Zakim]
- +31.62.252.aaff
14:45:54 [Zakim]
disconnecting the lone participant, Mark_Vickers, in UW_WebTVIG()9:00AM
14:45:56 [Zakim]
UW_WebTVIG()9:00AM has ended
14:45:56 [Zakim]
Attendees were Kazuyuki, ddavis, +1.818.406.aaaa, +1.425.214.aabb, +1.917.693.aacc, CyrilRa, Bin_Hu, sheau, glenn, +31.23.556.aadd, skim13, +31.23.556.aaee, Mark_Vickers,
14:45:56 [Zakim]
... +31.62.252.aaff
14:54:31 [kaz]
kaz has joined #webtv
16:51:16 [kaz]
kaz has joined #webtv
16:56:29 [Zakim]
Zakim has left #webtv
17:14:14 [kaz]
kaz has joined #webtv
17:17:15 [kaz]
kaz has joined #webtv
17:21:15 [kaz]
kaz has joined #webtv
17:27:16 [kaz]
kaz has joined #webtv
17:55:18 [kaz]
kaz has joined #webtv
18:01:06 [kaz]
kaz has joined #webtv
18:03:19 [kaz]
kaz has joined #webtv