Web and TV IG - Media APIs TF Call -- 27 Nov 2013

<jcverdie> can anyone hear me ? I can't hear anyone

<jcverdie> https://docs.google.com/spreadsheet/ccc?key=0AvACjV6qSvmxdEctdjYwa2JOalZLOG10elE1LVRZNlE

<scribe> Meeting: Web and TV IG - Media APIs Task Force call

<scribe> scribenick: ddavis

Gap Analysis

jcverdie: For the NSD spec, the Tuner Control can probably be changed to a red cross

+1 from me

<jcverdie> any other opinion about a red cross for tuner control, and go ahead w/ a CG ?

jcverdie: At TPAC we discussed that this is specific enough to probably have its own community group.

<kaz> Google doc

ddavis: There didn't seem to be any objections at TPAC so I'm happy to change this.

kaz: I'm fine with moving ahead and generating a small spec in a CG. But do we really want to do that? Is there a possibility to bring this to other working groups?
... Maybe we could double check.

jcverdie: OK, we could, but which groups could take this?
... Probably, none of these groups have this in their charter.
... Do you have a group in mind?

kaz: Yes, Device APIs or SysApps.

jcverdie: We could ask the group chairs about this.

kaz: During TPAC, we talked about creating CGs for small specs with the IG chairs.
... The CGs would have to cooperate with existing groups such as HTML WG, Device APIs, SysApps, etc. as well as TV IG.
... The chair of the CG would have to talk to the other groups and ask for comments. Collaboration is key.

jcverdie: So this is a topic for the moderators and chairs.
... If we contact the Device APIs or SysApps group, or whether we create a new CG.
... I can contact them.

<scribe> ACTION: jcverdie to contact the TV IG chairs about whether Tuner Control should have its own Community Group or be part of an existing group, such as Device APIs or SysApps [recorded in http://www.w3.org/2013/11/27-webtv-minutes.html#action01]

<trackbot> Created ACTION-175 - Contact the tv ig chairs about whether tuner control should have its own community group or be part of an existing group, such as device apis or sysapps [on Jean-Charles Verdie - due 2013-12-04].

jcverdie: Moving on to WebRTC
... As Giri is not here, let's ping him offline.
... For File API, skim13 is here. Can you tell us more about Device-to-device content transfer?

skim13: I wasn't sure of the relevance of this requirement to File API.
... There seem to be some design and scope issues.
... For this use case we need to consider two types of content transfer.
... For URL transfer, it doesn't affect File API but if it's transfer of the content itself then it could be relevant. I wasn't sure whether to put a "?" or leave it blank.
... You can share the file using e.g. WebSockets, so there might not be any connection with File API.

<whyun> Kaz, I'm not with skim13, and struggling to connect with IP phone

skim13: For general protection, it's not relevant to File API but if it's content protection it could be relevant.
... The same for media content protection offline too.

jcverdie: I would consider only the transfer of content, not URLs so I would put a green box there.
... I have no strong opinion about the other ones.
... For content streaming, I would leave it blank. It can be covered by WebRTC or other groups.
... And the same for content protection.

ddavis: I'd agree for content protection, probably content streaming as well.

jcverdie: Let's see what other people say as well when they read the minutes.

skim13: For File API Writer, the relevancy is the same for content transfer.
... Also for content protection, similarly, it's not relevant.

jcverdie: Thank you. Anything to add, anybody?
... Next, IndexedDB API

Louay: We have a lot of question marks.
... The issue is about storage capability in general. It depends on the requirements.
... It's not clear from the requirements if there's the need to store information in the local db or not, hence the "?"
... If it's needed to store content here, we can switch it to green.

<jcverdie> requirement discussed: http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Service_Aggregation_Mechanism

Louay: I think for content download, IndexedDB can also link with the File API, so we need IndexedDB API here.

jcverdie: I agree with you - it's not very clear whether we have to store something in a db or not.
... I think we need to refine the requirement.
... It's the same for the service synchronisation.
... I don't remember who put this requirement in but we'll have to find the originator and ask them to refine it.
... The other was device authentication mechanism.

Louay: We could use IndexedDB for storing some authentication info, but I think the Web Crypto API is more relevant.

jcverdie: I agree. Any other opinions?
... No objections so we can remove the "?" and proceed.
... Next is payments.

Louay: This is similar to authentication mechanism.
... If we need to store data in a db then it's relevant.

jcverdie: There's a new group called Web Payments so we should contact them to consider our requirements, therefore it should be a separate column.

Louay: Agreed.
... Content download is "yes" because you can use File API to store the data, but you also have metadata which can be stored in IndexedDB.
... Content recording while watching is the same.

jcverdie: Good, so we're left with the two question marks.
... For these, we need to refine the requirements.
... Next let's do Web Crypto by Yosuke.

yosuke: I think to remove the two question marks we need to refine the requirements.
... The authentication requirements are quite vague - not so clear.

jcverdie: Your suggestion is to go back to the requirements and make them clearer?

yosuke: Yes.

<jcverdie> http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements#Device_Authentication_Mechanism

jcverdie: Looking at the API requirement, I agree it's difficult.

<jcverdie> ACTION: jcverdie to contact moderators to discuss the 4 reqs which are unclear [recorded in http://www.w3.org/2013/11/27-webtv-minutes.html#action02]

<trackbot> Created ACTION-176 - Contact moderators to discuss the 4 reqs which are unclear [on Jean-Charles Verdie - due 2013-12-04].

jcverdie: OK, let's move on...

Try to assign Service Worker, HTML 5 and HTML 5.1.

Louay: I can do Service Worker.

jcverdie: It's not really clear what we need to do for HTML5 and HTML 5.1

ddavis: My feeling is that they're not really relevant. They were included because they're broad specs but probably they don't cover our requirements after all.

kaz: Service Worker is related to SysApps work on application lifecycle. I think that's also related to MMI group's application lifecycle.
... Maybe I can work with Louay and Ansi from Intel about this.

jcverdie: You mean working with SysApps?

kaz: This is not directly related to HTML5 markup but related to the new idea of application lifecycle, owned by Anssi from Intel, etc.

jcverdie: So maybe we should add a column.

kaz: Yes, I think so.

jcverdie: Let's do it for SysApps. Can I assign it to you?

kaz: Maybe we can add other columns after Louay and maybe I can help him.

jcverdie: So Louay will start with Service Worker and kaz will add SysApps later if needed.

<Louay> I agree

New template for use cases

jcverdie: At TPAC we talked about our use cases being lost when we end this work.
... The way we store the use cases in the wiki is not appropriate for finding the information in the future.
... There's a link above.
... The idea is to have a use case next to a name
... @@@ - (naughty word because it didn't work)
... It worked yesterday
... OK, I'll try to find the page again and send it to the public group.
... The idea was to have each use case on a separate place and their requirements listed as well.
... Also, to have information about the outcome, so in future we can refer to a use case and see what happened with it.
... It should make more sense.
... Well that was quick!
... Any other business to discuss while we're here?
... Not hearing anything so we can adjourn the meeting.
... Just a reminder - we wanted to end this TF by TPAC. We missed that but we want to finish everything before the end of the year.
... So we should have the opportunity to review everything by the time of our next call.
... If this is not possible for you, please let me, Bin or Olivier know so we can re-assign.

kaz: The Testing TF has finished their work so we can use their slot for this work if necessary.
... In other words, weekly.

jcverdie: We could try it.
... If we see from the gap analysis that there is not enough progress, we could cancel the meeting.

Confirmation: There will be a call at this time next week (Wednesday)

jcverdie: Nothing else?
... OK, thank you, meeting adjourned.

<jcverdie> thanks daniel

<jcverdie> for scribing so well :D

- DRAFT -

Web and TV IG - Media APIs TF Call

27 Nov 2013

Attendees

Contents

Gap Analysis

Try to assign Service Worker, HTML 5 and HTML 5.1.

New template for use cases

Summary of Action Items

Scribe.perl diagnostic output