W3C

Device APIs and Policy Working Group Teleconference

29 Sep 2010

Agenda

See also: IRC log

Attendees

Present
Bryan_Sullivan, Mohammed_Dadas, Suresh_Chitturi, Robin_Berjon, Frederick_Hirsch, Dominique_Hazael-Massieux, erica_newland, Dzung_Tran, Anssi_Kostiainen, Ilkka_Oksanen, Soonho_Lee, Richard_Tibbett, Niklas_Widell
Regrets
Claes_Nilsson, Marco_Marengo, Thomas_Roessler
Chair
Robin_Berjon, Frederick_Hirsch
Scribe
Rich

Contents


<trackbot> Date: 29 September 2010

<darobin> Scribe: Rich

<darobin> ScribeNick: richt

Administrative

fjh: TPAC coming up with registration.

<fjh> next F2F WG questionnaire and TPAC registration and information

<fjh> WG questionnaire (for all), http://www.w3.org/2002/09/wbs/43696/tpac2010dap/

<fjh> TPAC registration (for in-person attendees) http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/

fjh: now would be a good time to register.

<fjh> "Media Capture API" published as First Public Working Draft, updated draft of “HTML Media Capture” published

fjh: Media Capture FPWD and HTML Media Capture published.

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0136.html

<fjh> Manyoung Cho, Opera joined WG

Minutes Approval

<fjh> Approve 22 September minutes

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/att-0127/minutes-2010-09-22.html

<fjh> proposed RESOLUTION: Minutes from 22 Sept 2010 approved

RESOLUTION: Minutes 22/09 approved

Permission Draft

<fjh> FPWD CfC http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0128.html

fjh: don't have any objection to publication. Suresh, we have things to consider.

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0137.html

Suresh: no objection. just trying to clarify a few aspects and comments for consideration.
... how do we create identifiers. Per operation or blanket access. Similar discussions could be had on other APIs.

fjh: WARP is not a dependency to progress our specs?

Suresh: We talk about identifiers for use as features. WARP is indicating which domains can access which APIs.

Robin: That's not correct

<Zakim> dom, you wanted to note that WARP doesn't allow to tailor API access per domain at this time, only network access

Robin: WARP defines the domains which a widget can access. It's network protection not Device API protection.

<fjh> I suggest we remove WARP from this discussion

Suresh: No relation between DAP feature and WARP access?

Robin: None at all.

fjh: Suggest not to include WARP in discussion.
... Do we want to publish this now? We need to work out the details but with the change in direction it might be worth publishing.

<dom> (note that the draft already covers somewhat the one shot/duration aspect)

fjh: Makes sense to publish before the F2F.

<Suresh> since we talked several times on the realtionship between domains and APIs for access controls, I thought it made sense to refer to WARP

Bryan: Calrify the duration of permission. What is the meaning of 'one-shot'?

<fjh> we probably need to deal with one-shot versus permissions over time

<fjh> generically

Bryan: Once I give access to a contact do I get access to further changes to that contact.
... ?

<dom> (you can actually keep access to the file for even longer than a session through localStorage I think)

<fjh> bryan suggests we need to review in context of file API

<Suresh> but as WARP apparetly is not to feature element but for the entire widget control, it does not fit here

fjh: Could be published next week. Gives us a couple of weeks before TPAC tied get it in more shape.
... could then publish again after TPAC.

Robin: Wants to publish early and often.

Dom: That makes sense
... Depends on specific feedback on the draft.

PROPOSED RESOLUTION: Publish FPWD of Permissions Draft

<dom> (api-perms is the current shortname)

<dom> http://dev.w3.org/2009/dap/api-perms/

RESOLUTION: Publish FPWD of Permissions Draft (api-perms)

<dom> ACTION: Dom to get api-perms published as FPWD [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action01]

<trackbot> Created ACTION-277 - Get api-perms published as FPWD [on Dominique Hazaël-Massieux - due 2010-10-06].

<fjh> plan to publish next week, probably Tue, maybe Thur

fjh: Let's take it to the list and progress the spec.

Suresh: Just to repeat, right now we have identifiers tied to individual operations and other one-to-n. Could we have identifiers for the entire API?

fjh: We can get there. Let's take it to the list.

Privacy

fjh: Offline comms with Alissa and John. Updates coming in the next week or two.
... Alissa has recorded the issues related to Privacy Rulesets, and is planning to update that document. Can't do it today.
... on the call

Contacts

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0134.html

Robin: No need to look in to the async thing. It's solved.
... Other item is schema alignment. Discussion making some progress on list.
... could make progress if we define the issues with the remaining fields (on list)
... still need coordination and alignment with others
... so let's continue the current discussion on the list
... we could look at use cases/problems with implementations/other suggestions?

Suresh: we don't need to discuss things like name, address, telephone, etc.
... one criteria is that the fields are common across formats.
... in the current draft only a few fields fall in to this criteria

<bryan> do we have a list of the problematic fields?

Suresh: whatever fields we take are consistently defined across the formats

Robin: Looking for a way to make a resolution. Happy with free form discussion and we've already done that a lot

Suresh: Starting with what we have, most is OK except for a few fields mentioned on the mailing list
... then we have agreement on the common fields. Then we look at the schema. Do we own them?/do we reference?
... finally we need to map to formats of interest to participants.

<darobin> Controversial list: updated, relationships, and anniversary

Richard: Updated is in all versions of vCard. Relationships and anniversary not strong feelings though they are part of the latest vCard draft and can be retro-fitted to previous vCard versions with x-

Suresh: Each format has different semantics and we need to address that.

Robin: we can map to different semantics which is different to not being supported at all in other formats.

Suresh: In CAB we moved sync to a separate layer. How much of this needs to be specified in the W3C API?

Robin: Most sync can be based off of a timestamp in most cases.

Suresh: organizations in the spec seems overkill. Maybe that could be simplified.

Robin: we are increasing the number of issues rather than decreasing them. If we put it on the mailing list then we can make progress.
... Suresh, if you can put this on the mailing list then we can move forward

I'm happy to remove that.

RESOLUTION: Drop 'relationships'. Keep 'updated' in the W3C Contacts API.

Suresh: Another issue is the descriptions for these elements.

Robin: You're refering to referencing PoCo for descriptions?
... The issue is the quality of the prose that we're referencing. Is it good enough?

Suresh: When we reference descriptions people assume we are basing our work on Portable contacts. Could be misleading.

Robin: we don't have any reference to a particular format.

Richard: in the introduction we say its agnostic to underlying formats. Is that not clear enough?

Suresh: we need to be clearer with that.
... not to do this at the normative level but create a mapping to formats in the annex.

Robin: The question is: Are the definitions we have today good enough?

Suresh: All fields are described in PoCo and OMA CAB. The meaning is fairly the same.
... so what do we use in our spec.
... ?

<darobin> ACTION: Suresh to propose harmonisation descriptions for Contacts fields [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action02]

<trackbot> Created ACTION-278 - Propose harmonisation descriptions for Contacts fields [on Suresh Chitturi - due 2010-10-06].

<darobin> Rich: if Suresh takes an action to do it, I'll be happy to incorporate

<darobin> Suresh: before the f2f

Suresh: How does the group see taking fields and mapping them to different formats?

<darobin> +1 to incorporate stuff based on detailed submissions

Richard: Better to compare on the list or on another medium. If it turns out to be interesting then we can consider putting it in the spec.

Robin: agrees

<Suresh> I will take a stab at this (i.e. to map our fields with different formats vCard, PoCo, CAB) and we can decide if we should put it in Annex.

I said that it's ok to take this to the next conf call instead.

<fjh> robin asks how to manage coordination

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0140.html

<darobin> Rich describes triggering the Contacts popup directly if on click, as for popups

<darobin> Window.open()

<darobin> -> http://www.w3.org/mid/Pine.LNX.4.64.1009231537090.3271@ps20323.dreamhostps.com Hixie on <device> for Contacts

<dom> I hope we get to discuss future of <device> element in DAP as well

Robin: The onclick stuff looks interesting. Certainly something to explore further.
... It's interesting and if we can model it on what HTML5 does for window.open that would be great.

<dom> ACTION-275?

<trackbot> ACTION-275 -- Richard Tibbett to review the delta between Contacts API and Mozilla's implementation http://www.w3.org/mid/1E15AA20-0551-49AB-B07D-19A0784E0316@mozilla.com -- due 2010-09-29 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/275

Robin: It simplifies the HTML Contact Sharing. That kind of optimization is what we want
... Any feedback from Mozilla?

Richard: Will follow up.

Capture

fjh: It will take a couple of weeks to work on the privacy aspects

Robin: ok

s/TOPIC: Captire/TOPIC: Capture

<Zakim> dom, you wanted to ask about <device>

Robin: Would be good if someone pings the Google guys to see if there's some kind of alignment on Media Capture

Dom: Asking about HTML or API alignment?

Robin: Both

Dom: Perhaps Illka could start discussions since he's the editor?

Illka: Yes. I can do that.

<darobin>

Robin: idea is to pick this thread up again. Does what we've described match what they are implementing? Are they interested in the next step, which is the API part?

Illka: Will follow up on this.

<darobin> [I wonder if the API part couldn't ask the same trick that richt just came up with for Contacts]

<darobin> ACTION: ilkka to talk to the Chrome folks about capture [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action03]

<trackbot> Created ACTION-279 - Talk to the Chrome folks about capture [on Ilkka Oksanen - due 2010-10-06].

darobin, I don't see why it couldn't apply to a few APIs.

<device> element

Robin: Dom you wanted to discuss?

Dom: Feedback from the HTML Working Group. Feedback suggested that DAP could be a good home for this.
... see if we have a plan for it and whether we are prepared to take it on.

Robin: Will ask Ian if he will edit the <device> stuff in the context of the DAP WG.
... group will need to create a resolution that we actually want to do this.

Dom: Talk to Ian and we'll go from there to produce a FPWD of the device element.

<darobin> ACTION: Robin to ping Hixie about editing <device> as part of DAP, based on answer we start CfC for publication [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action04]

<trackbot> Created ACTION-280 - Ping Hixie about editing <device> as part of DAP, based on answer we start CfC for publication [on Robin Berjon - due 2010-10-06].

Dom: if Ian agrees of course.

Robin: Charter-wise it's within our charter.

<fjh> I was wondering how it might impact our schedule, first step is to get feedback

Robin: HTML ML is starting to crunch on LC issues. It's high traffic. DAP ML may be better for cutting edge feature discussions.

Sys Info

<Zakim> dom, you wanted to ask what about event loop

Robin: Need to review. Dong-Young and Richard also need to review as per their actions.

Dom: Robin, you took an action to see how the HTML5 event loop fits in to the Sys Info spec. Any news?

Robin: Taking more time to review Sys Info than I thought but I'm doing that as I go.
... just figuring out exactly where it fits in. How much goes directly in to Sys Info and how much should be in the Device spec.
... same feedback that Richard had when integrating the event loop in to Contacts.

<bryan> FYI I made two proposals for closing action items (123,196).

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0062.html

API Requirements

fjh: we are collecting some things that might need to be put in to this document.
... Dom suggested we need to update this doc.
... agree with that.

Robin: Do we maintain it everytime we change our minds on what goes in to the specification. Or wait til CR and produce a doc that matches what we have accomplished?

<Zakim> dom, you wanted to suggest a yearly update doesn't seem too much

Robin: Does it need to be one big doc or split it?

Dom: Shouldn't spend too much time keeping it up to date right now but the last update was 1 year ago. Perhaps its a good time to communicate the changes in that time.
... I'm willing to take a go at this.

<dom> http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/

<darobin> ACTION: Dom to take a stab at updating the API Requirements documents [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action05]

<trackbot> Created ACTION-281 - Take a stab at updating the API Requirements documents [on Dominique Hazaël-Massieux - due 2010-10-06].

<dom> -1 on folding in individual specs

<dom> requirements don't belong to API descriptions in my mind

<fjh> I think there is value in having one separate document

Richard: How about folding requirements back in to their corresponding specs? i.e. Contact requirements in the Contacts spec.

<fjh> -1 on folding in individual specs, want to see commonality

<darobin> [can we agree to update the requirements and figure out where to stuff them later?]

Robin: Anything else on requirements

Messaging (redux)

<fjh> suggestion is that common patterns and requirements will emerge, helpful to see what is common to various APIs

<darobin> ACTION: Robin get the ball rolling again on Messaging issues on the list [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action06]

<trackbot> Created ACTION-282 - Get the ball rolling again on Messaging issues on the list [on Robin Berjon - due 2010-10-06].

Robin: I'll take an action item to get discussion happening on list again.
... You have proposals for closing some actions?

<darobin> ACTION-123?

<trackbot> ACTION-123 -- Bryan Sullivan to make a concrete proposal how Contacts could support use of specific address books -- due 2010-03-24 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/123

Bryan: Can close ACTION-123 due to public-contacts-coord.

<darobin> ACTION-196

<dom> (ACTION-123 is not about formats, it's about tracking source of contacts data)

<darobin> ACTION-196?

<trackbot> ACTION-196 -- Bryan Sullivan to incorporate edits from James proposal http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0174.html -- due 2010-06-23 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/196

Bryan: ACTION-196 has been checked by James so can be closed also.

Dom: On ACTION-196 not bound to schema or formats. Was how to specify writing back to a specific address book.

Suresh: This is related to service id?

Dom: Yes

Bryan: No proposal at the moment. Could leave it open but prefer to close it. Worked through the issues at the time but no proposal at the end.

<dom> +1 on closing action and issue

<darobin> issue-43?

<trackbot> ISSUE-43 -- Should we make the contacts API data-storage-aware? -- closed

<trackbot> http://www.w3.org/2009/dap/track/issues/43

<darobin> action-123 closed

<trackbot> ACTION-123 Make a concrete proposal how Contacts could support use of specific address books closed

I absolutely do not want to talk about this stuff.

<dom> (it's closed because it has been replaced by ISSUE-77)

<dom> ISSUE-77?

<trackbot> ISSUE-77 -- Contacts need management of address book, different role than contacts user -- raised

<trackbot> http://www.w3.org/2009/dap/track/issues/77

<dom> (we can mark ISSUE-43 / 77 as postponed)

<darobin> issue-43 postponed

<darobin> action-196

<darobin> action-196?

<trackbot> ACTION-196 -- Bryan Sullivan to incorporate edits from James proposal http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0174.html -- due 2010-06-23 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/196

Robin: You incorporated James's edits?

<darobin> action-196 closed

<trackbot> ACTION-196 Incorporate edits from James proposal http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0174.html closed

Bryan: I beleive so. James seems to have agreed a couple of weeks ago on the conf. call.

Robin: AOB?
... Call is adjourned.

<fjh> s/...on the call//

Summary of Action Items

[NEW] ACTION: Dom to get api-perms published as FPWD [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action01]
[NEW] ACTION: Dom to take a stab at updating the API Requirements documents [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action05]
[NEW] ACTION: ilkka to talk to the Chrome folks about capture [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action03]
[NEW] ACTION: Robin get the ball rolling again on Messaging issues on the list [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action06]
[NEW] ACTION: Robin to ping Hixie about editing <device> as part of DAP, based on answer we start CfC for publication [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action04]
[NEW] ACTION: Suresh to propose harmonisation descriptions for Contacts fields [recorded in http://www.w3.org/2010/09/29-dap-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $