Device APIs and Policy Working Group Teleconference

15 Sep 2010


See also: IRC log


Robin_Berjon, Frederick_Hirsch, Suresh_Chitturi, Anssi_Kostiainen, erica_newland, Fan_HU, Dominique_Hazael-Massieux, bryan_sullivan, Dong-Young_Lee, Maria-Oteo, Dzung_Tran, Ilkka_Oksanen, Richard_Tibbett, Balaji_NerellaVenkataramana
John_Morris, Niklas_Widell, Laura__Arribas, Claes_Nilsson, Marco_Marengo
Robin_Berjon, Frederick_Hirsch


<trackbot> Date: 15 September 2010

<dom> ScribeNick: Bryan

<scribe> scribenick: bryan


fjh: will plan to have a bridge at tpac

<dom> ACTION: Dom to request bridge reservation for TPAC [recorded in http://www.w3.org/2010/09/15-dap-minutes.html#action01]

<trackbot> Created ACTION-269 - Request bridge reservation for TPAC [on Dominique Hazaƫl-Massieux - due 2010-09-22].

<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> DOM 3 Last Call

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

<dom> (note that 22 people say they will attend to TPAC, but only 16 have effectively registered http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/registrants#DeviceAP )

fjh: minutes approval

minutes approval

<fjh> Approve 1 September minutes

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

fjh: 1st sept call

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

RESOLUTION: Minutes from 1 Sept 2010 approved

access control

<fjh> Published Tuesday 7 Sept, see http://www.w3.org/News/2010#entry-8886

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

<dom> Device APIs ACcess Control Use cases and Requirements (TR in Sep 7)

fjh: published 7 sept , updated in editors draft with use case stories, by dom

<dom> Access Control Use Cases editors draft

fjh: open to publishing as soon as new changes are agreed, e.g. with features

<dom> (I think publishing it along with the features draft sounds like a good idea)


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

fjh: updated the draft, dom suggested to remove features
... didn't go into features as trouble finding use cases for it in BONDI

<fjh> bryan: notes that features were intended to be used for API versioning

<fjh> bryan: capabilities probably enough if at same level of granularity

<dom> (we already resolved not to worry about APIs versioning)

<fjh> bryan: ok with not using features in DAP

suresh: thats OK in BONDI context given the explanation by bryan

<richt> no API versioning was the very first decision this working group made :)

<dom> (I propose the stop talking about "features" or "capabilities", but only talking about "permissions"

suresh: in the context of widgets we need though some representation of the APIs as feature tags

fjh: isn't that the same as the API

<darobin> [+1 to dom, though the DOM has "feature strings"]

suresh: may not need the same level as BONDI provided, but in what the feature config requires we need to define features


fjh: we don't need features ala bondi to do permissons but do in config

<Suresh> At the minimum we need to specify the "features" that are required for using our APIs in the context of widgets

<darobin> what Widgets have is "feature": http://www.w3.org/TR/widgets/#feature0

dom: my proposal goes a bit further - rather than capabilities and features, focus instead on permissions

<Suresh> yes so we need to standardize the set of "feature names" which is an IRI

james: re granularity, the issue is connotation , i.e. what you want your devices to be able to do. re features and capabilities its more about how to write the document - if we use only features, where are the capabilities supposed to go

fjh: permissions would be more obvious - the feature/capabilties model in bondi adds complexity we dont need

james: where would capabilities go if taken out

fjh: essentially the same thing, we can discuss granularity, but attempts to access are permitted or not. we need the concept of permissions fundamentally, and also a way to define those things that are permitted or not

dom: want to focus only on permissions, not a distinction between features and capabilities

fjh: maybe misunderstood that the intent was to remove capabilities
... meant that we need trust domains, permissions, and naming to bind to feature elements in widget spec

james: supports the proposal

<Suresh> Widgets spec requires that the feature names is a IRI

fjh: re using feature strings vs abstracted device capabilities, robin had a proposal to define capabilities and prefix as needed with a base API reference

bryan: would like to have the more generic string to enable a single policy for different APIs using the same device capabilities

fjh: versioning would still need to be considered

<maoteo> I was not

fjh: summary, we dont need features and will call the things permissions, id the method that applies to a permission with a string
... propose dom do work on that

RESOLUTION: we will not include the concept of features in the DAP V1 work

fjh: clarifying, features here means specifically as used in the bondi sense
... we are collapsing features and capabilities into one thing and calling them permissions

bryan: bondi included the distinction to enable control of permission for device capabilities shared by different APIs

<dom> [I think the high level resolution is that we're using a single layer of permissions, more than on the specific word]

james: recommend using the term with a positive rather than permission

fjh: thinks permissions has a positive connotation connotation

<Suresh> access pemissions

fjh: permissions is used elsewhere and we should use the same term
... permissions is a straightforward concept

dom: at this time, what we are agreeing is to use a single layer of permissions - the name for that we can decide later on - as a start I will refer to permissions but we can settle that later

james withdraw the objection

james: withdraws the objection

<dom> PROPOSED RESOLUTION: we will use a single layer model for access permissions

RESOLUTION: we will use a single layer model for access permissions

james: can we defer or resolve to replace the work permissions with a more positive connotation

<dom> ACTION-263 due next week

<trackbot> ACTION-263 Take a stab at DAP features doc due date now next week

fjh: let see what dom comes up with and we will discuss it on the list

<richt_> this conversation is becoming a bit circular right? perhaps dom can propose something and we can rediscuss on the call next week if necessary.

james: preferred to defer the resolution

<richt_> take it to the mailing list?

dom: the resolution is only about the modeling and not the name/terms of the concepts in it

WARP in browser context

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

<fjh> not much to do with this

<fjh> right now

robin: dont recommend discussing this now

<fjh> keep it on the list

fjh: the proponents are not on the call


<fjh> action-210?

<trackbot> ACTION-210 -- Alissa Cooper to summarize and add issues to ruleset doc -- due 2010-07-21 -- OPEN

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



<darobin> http://lists.w3.org/Archives/Public/public-contacts-coord/

darobin: mailing list created for contacts coordination
... progressing toward common understanding
... a new draft was announced

<darobin> http://www.w3.org/mid/9B2983F7-D3C0-4EE3-B9AF-BDCE6B53271B@robineko.com

richt: the draft looks into formats, proposed extensions, look at the cvs diff log for the changes

darobin: made a post about pending op
... any sync in wrt needs to define the way it works in terms of HTML event loops and task queues
... basically a mental model to explain the way things happen
... e.g. if a request is cancelled before completion the two actions related to this need to put on a task queue so they are handled in the right order

richt: so the need is to understand the process model etc
... the HTML device spec has pending op specified, is that the best place to put this

darobin: different APIs will have different needs re what to do when cancel is called - so we need specific text for each spec

richt: will see what can be done for contacts re this

darobin: we can use the text for the other APIs as template
... anne form opera will be able to help

<dom> [I've added the need to look at asyncronous calls in terms of the HTML5 event loop in http://www.w3.org/2009/dap/wiki/ApiCheckList]

suresh: was on the contacts coordination call - thought we should discuss this and decide what is next
... we got info on what is being done but there was no decision on how to converge - do we want to discuss this now or give more time for this

tlr: there is an ongoing discussion between ietf and poco -that needs time
... the mapping between vcard3 and cab needs to be considered as this might impact vcard4
... the OMA has the action item to review the info available

suresh: expecting Christina to respond - she has the action

tlr: that response should clarify the story

suresh: looking back at the API, don't know what happened to the note re contacts schema for further study

richt: made some changes to reflect the call discussion, so removed the note re poco schema. we are not now saying that we are compatible with poco etc

<tlr> also my fault; I probably referred to our API as PoCo-based on multiple occasions

richt: but focusing on extensions, how to include them
... still up in the air, not a specific mapping to vcard or poco

suresh: the formats refer to poco schema still - seems to be dependent

richt: those attributes are vcard attributes (all are)

suresh: need to reflect the open issue re formats

richt: will put a statement back in

<dom> Dom's comments on updated contacts draft

suresh: some comments were provided on the list re attributes related to social networking - we should avoid dependency on these e.g. relationships

richt: these are vcard4 attributes

<dom> [relationship can be used outside of a social network, I would think]

suresh: to be useful, we need a service tied to the contacts format

<dom> (this is all about ISSUE-98)

<dom> ISSUE-98?

<trackbot> ISSUE-98 -- On what data model should the contacts API be based? -- open

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

richt: don't agree we have social attributes specifically - this is still ongoing and we need to continue the coordination work on the coord list
... we need to be active in that discussion to influence it
... do detail the specific issues on the list

suresh: a lot depends upon convergence in the coord group - we need a plan b in case that does not happen

richt: the timelines for poco and vcard are their own - we could go for example with a vcard subset and let the market decide what is useful
... looking at including an html integration part to the spec - may delay until we address current feedback
... this will include integrating with the device element of html

darobin: concerned about the dependency in the spec - maybe better outside

<dom> (separate spec sounds better to me)

richt: how about a non-normative section


darobin: action on John for privacy, not here so that will wait

james: on device element with audio, there are no open echo cancellation algorithms

darobin: its unclear whether the device element is in scope for this group
... the element is a couple of months away from being published - but a good point for the a/v part of the device element

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

<richt_> HTML Device is already being implemented: https://labs.ericsson.com/blog/beyond-html5-conversational-voice-and-video-implemented-webkit-gtk ;)

darobin: we have an open cfc for capture - believe most comments have been resolved

<dom> ilkka: not all, but most of them

in the lab

<darobin> [group goes textual due to ilkka's noise]

<darobin> ilkka, are the missing ones important?

<dom> [I'm hoping the remaining issues be documented in the draft itself]

darobin: we are trying to check if all the changes have been included - need to know if we can move ahead and publish - if the remaining issues are minor, propose to move forward with a pwd

<darobin> ilkka, can you put notes for the issues that weren't fixed?

darobin: need to put notes for the issues that weren't fixed?

illka: ok

darobin: anyone objecting to publishing with notes?

james: there were some concerns about objections re audio

<richt_> I believe that the audio format was discussed on the WHATWG without resolution (what to choose is the problem).

james: does anyone object to a proposed audio format?

dom: we discussed this and had resolved to not recommend a default at this time

<richt_> start of discussion on WHATWG: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028337.html

<dom> PROPOSED RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document

james: have w3c considered what should be default formats?

darobin: yes, unsure where though

<dom> (+1 on audio codec discussion belonging to HTML WG)

tlr: the location for that should be in HTML5 in the html wg

james: did that two weeks ago and there was no objection
... at least one member said it would be difficult to obtain concensus

dom: suggest to move this to html wg where there is a defined process for consensus

darobin: we don't want different spec in w3c to recommend different options

<darobin> RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document

RESOLUTION: publish Media Capture API as new draft with issues highlighted in the document

<darobin> ACTION: Ilkka to add notes to the MCAPI draft and ping Robin when ready [recorded in http://www.w3.org/2010/09/15-dap-minutes.html#action02]

<trackbot> Created ACTION-270 - Add notes to the MCAPI draft and ping Robin when ready [on Ilkka Oksanen - due 2010-09-22].


<darobin> http://lists.w3.org/Archives/Public/public-calendar-coord/

darobin: new coordination call and mailing list - suggest to join if you have interest
... on the call, we discussed status and call connects group described their work including caldav restful version and xcal, json version etc - we agreed to keep in touch on the issues

<Zakim> dom, you wanted to ask about schedule/roadmap for calendar API FPWD

dom: we had talked about publishing a pwd for calendar - wonder about the status

<dom> (also, what about TimezonedDate publication?)

richt: long overdue, stuck re a couple of issues. A good way forward e.g. xcalendar and mapping to js - will get the draft ready in the next two weeks to month

darobin: good to get it out before tpac

richt: can do

<darobin> http://dev.w3.org/2009/dap/calendar/TimezonedDate.html

dom: re creating a new timezone date interface, drafting is in progress and can this be included in the near term?

richt: a rough draft is in progress, not sure what approach to use

darobin: a service requires a connection and service discovery

james: it would be useful to discuss the underlying julian date and what info is available from it

darobin: when we publish calendar we should try to include this

james: include the ISO spec with a description of the number of bits it takes

richt: the ISO format is the cause of the problem


darobin: not much movement since the last version - we need to review the draft to move to last call soon

<Zakim> dom, you wanted to ask about pendingop

<richt_> Using an ISO date in a recurring rule there is no way to represent a timezone rule (or timezone id). Instead it uses timezone offset at a fixed point in time. That does not represent the time for any further recurring date of the event.

dom: re need to integrate with HTML5 event loops - this is needed here also

<richt_> ...if the timezone offset changes to -4 then the ISO representation (of e.g. -5)will be coordinating the call at the wrong time.

darobin: yes, all async interfaces need that so it needs to be included before last call

<richt_> ...hence the TimezonedDate object

darobin: would rather solve it once for all specs

<darobin> ACTION: Robin to figure out the event loop stuff for sysinfo [recorded in http://www.w3.org/2010/09/15-dap-minutes.html#action03]

<trackbot> Created ACTION-271 - Figure out the event loop stuff for sysinfo [on Robin Berjon - due 2010-09-22].

<dom> ISSUE: Sysinfo asynchronous calls needs to be expressed in terms of events loop

<trackbot> Created ISSUE-102 - Sysinfo asynchronous calls needs to be expressed in terms of events loop ; please complete additional details at http://www.w3.org/2009/dap/track/issues/102/edit .

james: should the capture API be closer to last call - due to issues with network attributes
... are there any attributes that are off limits - any restrictions on what the network attributes can include
... for example packet sniffing

darobin: what is the relationship with sysinfo

james: we need a wide variety of quality of service metrics

darobin: we resolved that, and unless there is new info we have agreed on the current set of attributes

<dom> james, do you have a pointer to a specific proposal for additions?

james: still think there is a need to a wide array of quality of service metrics from the network interface

<dom> [SysInfo is certainly not targeted for use by network engineers]

Summary of Action Items

[NEW] ACTION: Dom to request bridge reservation for TPAC [recorded in http://www.w3.org/2010/09/15-dap-minutes.html#action01]
[NEW] ACTION: Ilkka to add notes to the MCAPI draft and ping Robin when ready [recorded in http://www.w3.org/2010/09/15-dap-minutes.html#action02]
[NEW] ACTION: Robin to figure out the event loop stuff for sysinfo [recorded in http://www.w3.org/2010/09/15-dap-minutes.html#action03]
[End of minutes]

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