See also: IRC log
Bin_Hu: Any questions from the
previous meeting minutes?
... No questions, so approving the previous meeting minutes.
... Next, reviewing 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
... 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.
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
... 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
... We also have use cases contributed from ETRI
... Do you have any suggestions to move forward?
skim13: What we're doing is
... I think we can continue like this.
Bin_Hu: Back to today's
... Let's start trying to summarise the requirements from the use case list.
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
... 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
... 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
... 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.
Bin_Hu: I'll try to capture that
... Any other input?
kaz: As you might know, the W3C
MMI group will hold a workshop on 22nd and 23rd July in New
... 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
... 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
... 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
... 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
... 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
... 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
... 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
... 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
... 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
... 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.