W3C <http://www.w3.org/>


  Device APIs and Policy Working Group Teleconference


    21 Jul 2011

Agenda
<http://www.w3.org/2009/dap/wiki/F2F_Agenda_19,_20,_21_July_2011,_Paris>

See also: IRC log <http://www.w3.org/2011/07/21-dap-irc>


    Attendees

Present
    Ernesto_Jimenez, SungOk_You, Francois_Daoust, Robin_Berjon,
    Frederick_Hirsch, Josh_Soref, Laszlo_Gombos, Kihong_Kwon,
    Sullivan_Bryan, Kyung-Tak_Lee, Wonsuk_Lee, Jerome_Giraud,
    Youngsun_Ryu, Ingmar_Kliche, Soonbo_Han, Wang_Johnson, Cecile_Marc
Regrets
Chair
    Robin_Berjon, Frederick_Hirsch 
Scribe
    Josh_Soref


    Contents

  * Topics <#agenda>
     1. Continued review of deliverables in draft Charter (rechartered)
        <#item01>
     2. Review of APIs that are not making progress <#item02>
     3. HTTP-based APIs (based on WebKit feedback) <#item03>
     4. Issue Review <#item04>
     5. Action Review <#item05>
     6. AoB <#item06>
  * Summary of Action Items <#ActionSummary>

------------------------------------------------------------------------

<trackbot> Date: 21 July 2011

<fjh> trackbot, start telecon

<trackbot> Meeting: Device APIs and Policy Working Group Teleconference

<trackbot> Date: 21 July 2011

<robin> http://www.w3.org/2011/07/DeviceAPICharter

<fjh> ScribeNick: ingmar


      Continued review of deliverables in draft Charter (rechartered)

<fjh> discussion of what should be exposed to application and what
should not, with example of reading audio volume

<Josh_Soref> I don't think that the Application needs to know anything
about Audio Levels

<Josh_Soref> If it wants to show or have the option of showing Captions,
it should just do so

<bryan> Anything that is typical of user behavior, e.g. turning off data
usage when roaming, does not need to be an API.

<Josh_Soref> [charter-item] An API to read the current audio volume
level of a device

fjh: I hear consensus that the volume read API might be another charter
item which we will not work on

<robin> http://w3c-test.org/dap/proposals/request-feature/

fjh: introducer is on our list of things to do
... regarding privacy there are different rules in US/Canada and the EU,
we might need to look at this

<discussion about the charter and if we need to work on all deliverables>

robin: the charter defines the bounderies for the IPRs, it does not
oblige to work on a specific deliverable


      Review of APIs that are not making progress

<fjh> Gallery, http://dev.w3.org/2009/dap/gallery/

wonsuk: had an action item to review the gallery API
... need to do elaborate on use cases and requirements
... will provide input for the use cases and requirements section until
end of August

robin: it will be interesting to look at Gallery API on how it could
work with the HTTP approach

<fjh> ACTION-216?

<trackbot> ACTION-216 -- WonSuk Lee to reformulate gallery API to look
like contacts API -- due 2010-07-21 -- OPEN

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

<fjh> ACTION-368?

<trackbot> ACTION-368 -- WonSuk Lee to collect and summarize current use
cases for Gallery API and includes a draft doc -- due 2011-03-23 -- OPEN

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

<fjh> ACTION-314?

<trackbot> ACTION-314 -- Anssi Kostiainen to react on media gallery use
cases -- due 2010-12-15 -- OPEN

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

<fjh> aCTION-216 closed

<trackbot> ACTION-216 Reformulate gallery API to look like contacts API
closed

wonsuk: will work on ACTION-368 until end of August

<fjh> ACTION-216: first need to review use cases and requirements, see
ACTION-368, then decide on next steps

<trackbot> ACTION-216 Reformulate gallery API to look like contacts API
notes added

fjh: there was a decision at the last TPAC to kill AppLauncher, we
should remove it from the DAP page

<fjh> http://dev.w3.org/2009/dap/privacy-rulesets/


      HTTP-based APIs (based on WebKit feedback)

robin: we received feedback that some of the APIs we designed might be
candidates for HTTP based APIs.
... we discussed this at least a year ago and didn't reach consensus on
a generic approach

Josh_Soref: it should be relatively straight forward to do a limited
binding for HTTP

<robin> http://www.w3.org/TR/WebIDL/

bryan: we should have a short discussion on the rationale

<robin>
http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0061.html

<bryan> Also
http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0083.html

<lgombos_> also related -
https://lists.webkit.org/pipermail/webkit-dev/2011-July/017621.html

robin: if we would not define an API we would exclude a lot of services
(as the browser would only have integration of the local contacts and
probably a small list of HTTP based data sources)

bryan: points out that JS libraries could be used to access different
HTTP based data sources

Josh_Soref: accessing the datasources using JS has security implications

bryan: we started to develop an API for local data sources such as
contacts and now discussing a generic API for network based data
sources. This is a change in scope.

<fjh> two models - direct access to local or web based providers, vs all
access mediated by local that then syncs with others as needed

<discussion on what you could do with JS vs. what should be implemented
in the browser>

bryan: makes the point that we started to do simple things for local
services, we should keep things simple and not make it more complex by
involving network based services

Josh_Soref: a network based API could be valuable if the browsers use
e.g. network based access to the local contact database, i.e. the local
database would be handled in the same way as a network based data source

robin: will start to write a first WebIDL mapping and Josh will help and
review

fjh: what does it mean for the contacts spec? Do we need to change
something?

Josh_Soref: we might need to add some fields

<fjh> discussion - if we move away from javascript + idl approach then
idl would only serve as developer documentation, code directly written
to access web info, no tool for pre-processing?

<fjh> this suggests that this approach would require something like web
introducer to achieve complete api, including security etc?

<fjh> discussion as to whether this is actually simpler for developer

<fjh> I am concerned that we are making many assumptions in this
assumption about what the browser/ua will do yet if that is not
specified it may not occur.

<fjh> This could be an issue for privacy, user consent etc

<fjh> How can we require implementation of both web introducer and a
contacts spec in combination - a conformance requirement document?

Josh_Soref: want the UA to allow the user to synthesize a contact
instead of only taking it from existing data sources

robin: synthesizing contacts is an implementation detail

<Josh_Soref> [ I provided the example of me going to a street fair and
being asked to drop in a card into a Bowl for a contest ]

<Josh_Soref> [ I could take my own business card from my wallet, or some
other card I collected, or I could write down some items onto a piece of
paper and drop that in. ]

<fjh> interface changes and performance concerns?

<Josh_Soref> [ I could even write out some items from an existing card,
or cross items out from a card ]

<fjh> synthesized contact = returning portion of information from
contact, effectively creating a virtual contact

<fjh> robin - performance issue could be naive implementation, using
HTTP locally with overhead etc.

<fjh> ISSUE: how would feature discovery work for REST APIs

<trackbot> Created ISSUE-118 - How would feature discovery work for REST
APIs ; please complete additional details at
http://www.w3.org/2009/dap/track/issues/118/edit .

<bryan> For a URL-based approach, browser processing (e.g. what is
returned in XHR response) would need to be clearly defined

<bryan> How a URL-based approach (which would appear to be directly
usable by developers) would work with existing auth scheme such as OAuth
would need to be addressed in the spec.

<Zakim> Josh_Soref, you wanted to respond to fjh to explain that the
http approach means less work for Browser vendors which increases
likelyhood of them implementing

fjh: the HTTP approach would add more complexity on the definition of
the API

<bryan> With a URL-based approach, it would be more likely that
developers would make errors in creating the URLs - this is the same
issue as using MIME type attributes to define video capture API options.

<bryan> We would have to use caution to avoid duplicating similar
RESTful API work, e.g. the OMA/OneAPI APIs.

<robin> https://github.com/andreasgal/dom.js/blob/master/tools/idl2domjs
-> idl2js

<lgombos_> bryan - can you drop in a link for OneAPI (for contacts)

fjh: the discussion would benefit from an example, we need to think
about security, privacy, discovery

<fjh> in walking through the example

<Zakim> ernesto_jimenez, you wanted to ask josh for clarification on the
HTTP approach he has in mind

<bryan> Overall there seems to be little difference in the expected
implementation cost.

<bryan> Do we expect other groups to move in this direction as well,
e.g. why doesn't the File API use the URL approach? What about IndexedDB
etc?

<fjh> good question - how is a remote database handled?

<bryan> Do we expect a general move away from both markup and Javascript
APIs? Why do we need the <audio> tag when we can have an audio:// URL to
invoke the same API?

<fjh> general question is one of uniformity of approach across webapps,
dap, HTML5 etc

<bryan> Link to OneAPI:
https://oneapi.aepona.com/authsec/portal/tws_gsma/Resources/Library

<ernesto_jimenez> I asked about the implications of using an HTTP API vs
a Javascript API. Robin pointed out that using a restful approach
doesn't require browser code necessarily. I pointed out that HTTP access
to contacts we can do already and we would just be standardising the
HTTP interface from the server side, if we want browser UI, device
contacts, etc. you need to write code in the browser no matter if the
API is JavaScript or HTTP

Josh_Soref: the reason why there is a audio element is that the object
element was a disaster

<fjh> I suggest issues of uniformity can be handled by TAG, also
architecture approach

<robin> *ACTION:* Frederick to raise the HTTP vs JS architectural issue
with the TAG [recorded in
http://www.w3.org/2011/07/21-dap-minutes.html#action01]

<trackbot> Created ACTION-441 - Raise the HTTP vs JS architectural issue
with the TAG [on Frederick Hirsch - due 2011-07-28].

<bryan> Between the (at least) three approaches to defining APIs
(declarative, procedural, RESTful), which one is used needs to be based
upon rationales that are commonly understood (e.g. communicated by TAG)
and used by the W3C groups in consistent ways to guide their API
development.

<fjh> short term plan - review example of REST API for contacts review
and look for issues

<robin> *ACTION:* Robin to produce a REST binding example for Contacts
(client, server, protocol) [recorded in
http://www.w3.org/2011/07/21-dap-minutes.html#action02]

<trackbot> Created ACTION-442 - Produce a REST binding example for
Contacts (client, server, protocol) [on Robin Berjon - due 2011-07-28].

robin: we need to ask the TAG about some general issues, for the short
term we can work on the HTTP binding for contacts
... we don't know at the moment on how to select the URL, the assumption
for the moment is that the URL available

<fjh> laszlo - have specific fixed URL or variable/pluggable URL

<fjh> robin also notes this is where web introducer

bryan: does our work towards a REST binding mean that we move away from
a JS binding?

robin: if we find that the REST approach is a good way to go we will
follow this, but anybody could also do a JS or even a Java binding

<fjh> summary - what I suggested before that JS API is easier for
developer, HTTP API offers other benefits

bryan: I understand that the group shifts focus to REST, but I would
prefer to have multiple bindings including JS

fjh: we need to wait to have some more concrete examples to better
understand the issues and decide on how to move on


      Issue Review

<Josh_Soref> ScribeNick: Josh_Soref

<scribe> Scribe: Josh_Soref

<fjh> http://www.w3.org/2009/dap/track/issues/open

<fjh> ISSUE-81?

<trackbot> ISSUE-81 -- How to represent dates? ES has Date but with no
TZ information; using strings is less than ideal; do we have to create a
Web Dates specification? -- open

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

fjh: that affects calendar
... so we can wait

ISSUE-87?

<trackbot> ISSUE-87 -- Degree of ruleset transmission with API calls,
how often, which -- open

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

ISSUE-88?

<trackbot> ISSUE-88 -- User interaction for ruleset confirmation when
multiple APIs are used to provide functionality, usability etc -- open

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

ISSUE-89?

<trackbot> ISSUE-89 -- Clarify how rulesets interact with pre-existing
relationships -- open

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

fjh: I have an action, I'm going to look at them

ISSUE-92?

<trackbot> ISSUE-92 -- Sysinfo, permissions for get vs monitor; -- open

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

ISSUE-96?

<trackbot> ISSUE-96 -- Some properties of sysinfo are static so monitor
might not make sense -- open

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

fjh: given where we're going with sysinfo, i'm not sure what we're doing
with their issues
... ISSUE-92, I'll follow up offline
... ISSUE-96 was Dom saying this would be moot if we reshape it
... So we're going to split things up into things like sensors

robin_: yeah, we can close 92 and 96

ISSUE-92 CLOSED

<trackbot> ISSUE-92 Sysinfo, permissions for get vs monitor; closed

ISSUE-96 CLOSED

<trackbot> ISSUE-96 Some properties of sysinfo are static so monitor
might not make sense closed

<fjh> ISSUE-92: revisit when working on new specs dealing with this
material

<trackbot> ISSUE-92 Sysinfo, permissions for get vs monitor; notes added

<fjh> ISSUE-96: revisit when working on new specs dealing with this
material

<trackbot> ISSUE-96 Some properties of sysinfo are static so monitor
might not make sense notes added

<fjh> ISSUE-95?

<trackbot> ISSUE-95 -- Different regulatory environments and
relationship to privacy and rulesets -- open

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

<fjh> *ACTION:* fjh to review various ruleset issues and follow up
[recorded in http://www.w3.org/2011/07/21-dap-minutes.html#action03]

<trackbot> Created ACTION-443 - Review various ruleset issues and follow
up [on Frederick Hirsch - due 2011-07-28].

ISSUE-105?

<trackbot> ISSUE-105 -- Should the capture hint in HTML Media Capture be
specified through a MIME parameter? -- open

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

fjh: We'll leave this open on Dom, but it might be moot

ISSUE-107?

<trackbot> ISSUE-107 -- How to better integrate URIs schemes in
Messaging API -- open

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

robin: I think this one can be closed

CLOSE ISSUE-107

<trackbot> ISSUE-107 How to better integrate URIs schemes in Messaging
API closed

<fjh> ISSUE-107: done

<trackbot> ISSUE-107 How to better integrate URIs schemes in Messaging
API notes added

<fjh> ISSUE-113?

<trackbot> ISSUE-113 -- AddEventListener in Battery Status has side
effects -- open

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

<robin> we need to process
http://www.w3.org/2009/dap/track/issues/raised as well

<bryan_> Replacing the OneAPI link I provided earlier, this one does not
require a OneAPI developer account:
https://oneapi.aepona.com/sec/portal/tws_gsma/Resources/Library

<fjh> ISSUE-108?

<trackbot> ISSUE-108 -- Should Contacts API have MUST instead of SHOULD
for extended attributes, is this a general issue for all specs? -- raised

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

robin: oh, I now understand what it is

<robin>
http://dev.w3.org/2009/dap/contacts/#extended-contact-properties-and-parameters


robin: we have a SHOULD for extensions having a vendor prefix

<fjh> "Non-standard, private properties and parameters should have a
prefixed name starting with X (U+0058 LATIN CAPITAL LETTER X) or use a
vendor-specific prefix. Extended properties and parameters can be
defined bilaterally between user agents without outside registration or
standardization. "

robin: MUST would mean we'd need to be able to test it

Josh_Soref: we can actually test it by iterating over the object has own
properties
... skipping properties we define.
... and skipping properties which have a prefix.

fjh: so let's make it a MUST ?

robin: I'm opening the spec so we can edit it

*RESOLUTION: We will change the SHOULD to a MUST in the second paragraph
of section 6*

<fjh> ISSUE-108: resolved by changing SHOULD to MUST in section 6

<trackbot> ISSUE-108 Should Contacts API have MUST instead of SHOULD for
extended contact properties, is this a general issue for all specs?
notes added

<fjh> ISSUE-108 closed

<trackbot> ISSUE-108 Should Contacts API have MUST instead of SHOULD for
extended contact properties, is this a general issue for all specs? closed

<fjh> ISSUE-109?

<trackbot> ISSUE-109 -- We need solid use cases for Feat Perms if it's
going to fly -- open

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

robin: it's unclear that implementers want to do this
... there's been pushback from mozilla

<fjh> ISSUE-109: closed

<trackbot> ISSUE-109 We need solid use cases for Feat Perms if it's
going to fly notes added

fjh: so... doing this should be based on what is right

robin: it would be good to have introductory use cases as we have for
other specs

fjh: we have an action item for that

<fjh> ISSUE-109: will need new section on use cases and requirements,
being added to all docs

<trackbot> ISSUE-109 We need solid use cases for Feat Perms if it's
going to fly notes added

ISSUE-113?

<trackbot> ISSUE-113 -- AddEventListener in Battery Status has side
effects -- open

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

ISSUE-114?

<trackbot> ISSUE-114 -- Battery spec should note relative ordering of
battery low versus battery critical in terms of criticality -- open

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


      Action Review

<fjh> http://www.w3.org/2009/dap/track/actions/open

<fjh> ACTION-148?

<trackbot> ACTION-148 -- Bryan Sullivan to compare user interaction
input with what already available in HTML5 / WebApps -- due 2010-03-25
-- OPEN

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

ACTION-148?

<trackbot> ACTION-148 -- Bryan Sullivan to compare user interaction
input with what already available in HTML5 / WebApps -- due 2010-03-25
-- OPEN

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

CLOSE ACTION-148

<trackbot> ACTION-148 Compare user interaction input with what already
available in HTML5 / WebApps closed

robin: we covered this by adjusting the charter for the new charter

<fjh> ACTION-148: covered in rechartering

<trackbot> ACTION-148 Compare user interaction input with what already
available in HTML5 / WebApps notes added

ACTION-229?

<trackbot> ACTION-229 -- Richard Tibbett to go through
http://tools.ietf.org/html/rfc5546 and ensure the bindings provided map
-- due 2010-10-22 -- OPEN

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

CLOSE ACTION-229

<trackbot> ACTION-229 Go through http://tools.ietf.org/html/rfc5546 and
ensure the bindings provided map closed

robin: we can close because richt looked at it and made changes

ACTION-230?

<trackbot> ACTION-230 -- Wojciech Maslowski to specify "add to calendar"
based on ICS-objects opening -- due 2010-08-05 -- OPEN

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

robin: that was from a writable-calendar

CLOSE ACTION-230

<robin> issue-78?

<trackbot> ACTION-230 Specify "add to calendar" based on ICS-objects
opening closed

<trackbot> ISSUE-78 -- Capture has a minimisation problem with EXIF data
(e.g. it could be Geotagged) -- closed

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

<fjh> ACTION-230: for writable calendar, group shifted to readable

<trackbot> ACTION-230 Specify "add to calendar" based on ICS-objects
opening notes added

ACTION-251?

<trackbot> ACTION-251 -- John Morris to review privacy text related to
ISSUE-78 for capture -- due 2010-10-20 -- OPEN

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

CLOSE ACTION-251

<trackbot> ACTION-251 Review privacy text related to ISSUE-78 for
capture closed

ACTION-257?

<trackbot> ACTION-257 -- Richard Tibbett to define what goes on for
concurrent calls to find() when there is no error callback (and step
three also needs to define that); then report to group so we can do the
same to SysInfo get -- due 2010-09-29 -- OPEN

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

CLOSE ACTION-257

<trackbot> ACTION-257 Define what goes on for concurrent calls to find()
when there is no error callback (and step three also needs to define
that); then report to group so we can do the same to SysInfo get closed

ACTION-281?

<trackbot> ACTION-281 -- Dominique Hazaël-Massieux to take a stab at
updating the API Requirements documents -- due 2011-05-10 -- OPEN

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

CLOSE ACTION-281

<trackbot> ACTION-281 Take a stab at updating the API Requirements
documents closed

robin: we've dropped that document in favor of events

ACTION-297?

<trackbot> ACTION-297 -- Robin Berjon to draft up TZDate -- due
2010-11-11 -- OPEN

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

<fjh> ACTION-257: addressed in document

<trackbot> ACTION-257 Define what goes on for concurrent calls to find()
when there is no error callback (and step three also needs to define
that); then report to group so we can do the same to SysInfo get notes
added

robin: still open...

ACTION-300?

<trackbot> ACTION-300 -- Claes Nilsson to start working on use cases and
requirements for video/audio conference à la <device> element -- due
2010-11-12 -- OPEN

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

CLOSE ACTION-300

<trackbot> ACTION-300 Start working on use cases and requirements for
video/audio conference à la <device> element closed

robin: this is now in the RTC WG

ACTION-307?

<trackbot> ACTION-307 -- Richard Tibbett to send email to list with
resolutions for open issues against contacts, clarifying status -- due
2010-11-24 -- OPEN

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

<fjh> ACTION-300: in RTC WG

<trackbot> ACTION-300 Start working on use cases and requirements for
video/audio conference à la <device> element notes added

CLOSE ACTION-307

<trackbot> ACTION-307 Send email to list with resolutions for open
issues against contacts, clarifying status closed

robin: because it was done
... email to the list sent

ACTION-314?

<trackbot> ACTION-314 -- Anssi Kostiainen to react on media gallery use
cases -- due 2010-12-15 -- OPEN

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

CLOSE ACTION-314

<trackbot> ACTION-314 React on media gallery use cases closed

ACTION-315?

<trackbot> ACTION-315 -- Dominique Hazaël-Massieux to look into pop-up
windows in Permissions draft -- due 2011-05-11 -- OPEN

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

ACTION-320?

<trackbot> ACTION-320 -- Richard Tibbett to make Calendar like Contacts
in every possible way -- due 2010-12-22 -- OPEN

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

CLOSE ACTION-320

<trackbot> ACTION-320 Make Calendar like Contacts in every possible way
closed

robin: that's done...

<fjh> ACTION-320: implemented

<trackbot> ACTION-320 Make Calendar like Contacts in every possible way
notes added

ACTION-329?

<trackbot> ACTION-329 -- Robin Berjon to maintain coordination with
HTML+Speech on
http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0057.html; include
Claes in the discussion -- due 2011-01-26 -- OPEN

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

robin: that's a continuous action
... not sure what to do with it
... we're on the calls

CLOSE ACTION-329

<trackbot> ACTION-329 Maintain coordination with HTML+Speech on
http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0057.html; include
Claes in the discussion closed

robin: it's the "hypertext coordination group"

<robin> http://www.w3.org/MarkUp/CoordGroup/

<fjh> ACTION-329: Hypertext Coordination Group,
http://www.w3.org/MarkUp/CoordGroup/

<trackbot> ACTION-329 Maintain coordination with HTML+Speech on
http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0057.html; include
Claes in the discussion notes added

ACTION-330?

<trackbot> ACTION-330 -- John Morris to review SysInfo privacy
considerations section, and ISSUE-64 on "generic" -- due 2011-01-26 -- OPEN

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

CLOSE ACTION-330

<trackbot> ACTION-330 Review SysInfo privacy considerations section, and
ISSUE-64 on "generic" closed

<fjh> ACTION-330: restructuring sysinfo

<trackbot> ACTION-330 Review SysInfo privacy considerations section, and
ISSUE-64 on "generic" notes added

fjh: closing because it's sysinfo which is being split

robin: plus it relates to a closed issue

ACTION-338?

<trackbot> ACTION-338 -- Laszlo Gombos to look into multiple
permission/installable designs for APIs -- due 2011-02-23 -- OPEN

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

ACTION-339?

<trackbot> ACTION-339 -- Laszlo Gombos to go through existing DAP APIs
to see if there are use cases there for Feat Perms (or if the existing
approaches work better) -- due 2011-02-23 -- OPEN

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

CLOSE ACTION-338

<trackbot> ACTION-338 Look into multiple permission/installable designs
for APIs closed

CLOSE ACTION-339

<trackbot> ACTION-339 Go through existing DAP APIs to see if there are
use cases there for Feat Perms (or if the existing approaches work
better) closed

robin: ACTION-338 is heavily related to policy

lgombos_: ansi had some related work

robin: ACTION-339 is obsoleted by a new ACTION-XXX

lgombos_: we said that each spec needs to say things about
feature-permissions

ACTION-340?

<trackbot> ACTION-340 -- Frederick Hirsch to look at how we're doing
privacy by design -- due 2011-02-23 -- OPEN

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

ACTION-345?

<trackbot> ACTION-345 -- Laszlo Gombos to look at Microsoft feedback on
Capture API -- due 2011-03-16 -- OPEN

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

robin: the feedback was sent by Microsoft to the HTML Speech people

fjh: we'll keep this open

ACTION-359?

<trackbot> ACTION-359 -- Bryan Sullivan to split out a generic sensors
API (based on ambientlight/proximity/etc) from sysinfo -- due 2011-03-23
-- OPEN

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

robin: bryan, you have an action item to write up the API

bryan_: I was hoping to do this
... I was hoping to have a submission

ACTION-360?

<trackbot> ACTION-360 -- Suresh Chitturi to see at possibilities of APIs
for access to device characteristics -- due 2011-03-23 -- OPEN

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

fjh: we have suresh looking for things

Josh_Soref: I think suresh is now me...

<robin> *ACTION:* Josh to investigate ACTION-360 with Suresh to figure
out if it can be closed or should be reassigned [recorded in
http://www.w3.org/2011/07/21-dap-minutes.html#action04]

<trackbot> Created ACTION-444 - Investigate ACTION-360 with Suresh to
figure out if it can be closed or should be reassigned [on Josh Soref -
due 2011-07-28].

ACTION-361?

<trackbot> ACTION-361 -- Bryan Sullivan to provide use cases for device
characteristics access -- due 2011-03-23 -- OPEN

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

<fjh> ACTION-360: Josh to follow up with Suresh, ACTION-444

<trackbot> ACTION-360 See at possibilities of APIs for access to device
characteristics notes added

bryan_: I think this is part of sysinfo
... I suggest closing it if we aren't going to do anything with sysinfo
... I think there is a need for this, but I don't know that use cases
will change anyone's mind

fjh: I think having use cases enables people to consider doing work

Josh_Soref: I think in this WG we're trying to always have UCs
... HTMLWG, WebApps, WebEvents, GeoLocation and DAP all try to require UCs
... and that pretty much defines browsers

CLOSE ACTION-361

<trackbot> ACTION-361 Provide use cases for device characteristics
access closed

ACTION-362?

<trackbot> ACTION-362 -- Kangchan Lee to provide use cases for
sysinfo-like features -- due 2011-03-23 -- OPEN

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

CLOSE ACTION-362

<trackbot> ACTION-362 Provide use cases for sysinfo-like features closed

ACTION-364?

<trackbot> ACTION-364 -- Robin Berjon to get the COW started -- due
2011-03-23 -- OPEN

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

ACTION-368?

<fjh> anyone can bring a use case into the WG without an action, also a
proposal that is in scope

<trackbot> ACTION-368 -- WonSuk Lee to collect and summarize current use
cases for Gallery API and includes a draft doc -- due 2011-03-23 -- OPEN

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

ACTION-370?

<trackbot> ACTION-370 -- Robin Berjon to dive more deeply into Web
Intents/Web Activities in view of integration -- due 2011-08-22 -- OPEN

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

ACTION-374?

<trackbot> ACTION-374 -- Frederick Hirsch to complete Privacy Rulesets
with binding considerations -- due 2011-03-23 -- OPEN

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

ACTION-391?

<trackbot> ACTION-391 -- Dominique Hazaël-Massieux to look at overlap
between MediaFileData and HTMLVideoElement -- due 2011-04-27 -- OPEN

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

ACTION-396?

<trackbot> ACTION-396 -- Richard Tibbett to email the group looking for
editors for Calendar -- due 2011-05-25 -- OPEN

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

CLOSE ACTION-396

<trackbot> ACTION-396 Email the group looking for editors for Calendar
closed

fjh: he did the email...

ACTION-397?

<trackbot> ACTION-397 -- Robin Berjon to coordinate with HTML WG chairs
about Capture, include the HCG -- due 2011-05-25 -- OPEN

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

ACTION-408?

<trackbot> ACTION-408 -- Dominique Hazaël-Massieux to check if dom +
Suresh'es comments are integrated -- due 2011-06-15 -- CLOSED

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

ACTION-406?

<trackbot> ACTION-406 -- Frederick Hirsch to review feature request
access containers -- due 2011-06-08 -- OPEN

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

CLOSE ACTION-406

<trackbot> ACTION-406 Review feature request access containers closed

ACTION-411?

<trackbot> ACTION-411 -- Robin Berjon to reply to Jo about NetInfo --
due 2011-06-15 -- OPEN

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

ACTION-412?

<trackbot> ACTION-412 -- Robin Berjon to go through inactive specs and
ping editors to get a feel for their commitment to more work -- due
2011-06-15 -- OPEN

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

CLOSE ACTION-412

<trackbot> ACTION-412 Go through inactive specs and ping editors to get
a feel for their commitment to more work closed

fjh: we did that today

ACTION-413?

<trackbot> ACTION-413 -- Robin Berjon to contact Claudio Caldato from MS
and discuss media capture -- due 2011-06-15 -- OPEN

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

<fjh> ACTION-412: done during 21 July 2011 f2f

<trackbot> ACTION-412 Go through inactive specs and ping editors to get
a feel for their commitment to more work notes added

ACTION-414?

<trackbot> ACTION-414 -- Anssi Kostiainen to write up an overview of the
media capture landscape, with ideas of how to move forward -- due
2011-06-15 -- OPEN

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

ACTION-415?

<trackbot> ACTION-415 -- Robin Berjon to make all the changes to
Contacts from Dom's email
http://lists.w3.org/Archives/Public/public-device-apis/2011Jun/0050.html
-- due 2011-06-22 -- CLOSED

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

ACTION-417?

<trackbot> ACTION-417 -- Anssi Kostiainen to implement changes to
battery event based on feedback, and RESOLUTION from 20110629 -- due
2011-07-06 -- CLOSED

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

ACTION-416?

<trackbot> ACTION-416 -- Frederick Hirsch to investigate privacy
fingerprinting issues related to DAP -- due 2011-06-22 -- OPEN

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

[ Scribe has issues with sequences ]

fjh: ernesto_jimenez, do you have everything you need for your editor work?
... you need to set up keys for CVS
... you can do that with francois today here

Josh_Soref: I should also get set up for that...

ACTION-423?

<trackbot> ACTION-423 -- WonSuk Lee to draft the use cases and
requirements section for Battery -- due 2011-07-26 -- OPEN

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

ACTION-424?

<trackbot> ACTION-424 -- Josh Soref to draft the use cases and
requirements for Messaging, perhaps even take over Messaging editing --
due 2011-07-26 -- OPEN

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

[ Josh_Soref looks ]

ACTION-427?

<trackbot> ACTION-427 -- Frederick Hirsch to prepare web app best
practices for FPWD publication, including title change, shortname
change, and adding reference to MWBP -- due 2011-07-26 -- OPEN

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

CLOSE ACTION-427

<trackbot> ACTION-427 Prepare web app best practices for FPWD
publication, including title change, shortname change, and adding
reference to MWBP closed

fjh: I already did that

ACTION-429?

<trackbot> ACTION-429 -- Josh Soref to figure out if the PoCo handling
of personal names is okay under I18N rules -- due 2011-07-26 -- OPEN

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

ACTION-430?

<trackbot> ACTION-430 -- Josh Soref to provide sample input with
potential outputs. -- due 2011-07-26 -- OPEN

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

ACTION-432?

<trackbot> ACTION-432 -- Ernesto Jimenez to make a proposal for
ISSUE-116 and ISSUE-117 -- due 2011-07-27 -- OPEN

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

ACTION-433?

<trackbot> ACTION-433 -- Laszlo Gombos to reply to Anne about his
Permissions questions -- due 2011-07-27 -- OPEN

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

ACTION-434?

<trackbot> ACTION-434 -- Dominique Hazaël-Massieux to investigate if DAP
could use the XPointer registration code for feature registration -- due
2011-07-27 -- OPEN

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

ACTION-435?

<trackbot> ACTION-435 -- Laszlo Gombos to update the Permissions draft
based on f2f discussion and summary email from Robin in planning for
FPWD -- due 2011-09-01 -- OPEN

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

ACTION-436?

<trackbot> ACTION-436 -- WonSuk Lee to provide an example for
Permissions -- due 2011-07-27 -- OPEN

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

ACTION-437?

<trackbot> ACTION-437 -- Laszlo Gombos to talk to the Android people
about whether the Netinfo API is used and something they think was a
good idea -- due 2011-07-27 -- OPEN

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

ACTION-438?

<trackbot> ACTION-438 -- Josh Soref to talk to Brian Leroux about the
Netinfo API in PhoneGap to ask about uptake and feedback -- due
2011-07-27 -- OPEN

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

robin: I spoke with Brian about this
... pretty much every single phonegap api uses the connection api
... but I think they're using it for the wrong reason

ACTION-439?

<trackbot> ACTION-439 -- Bryan Sullivan to draft use cases for
proximity, ambient light, and ambient sound sensors. -- due 2011-07-27
-- OPEN

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

ACTION-440?

<trackbot> ACTION-440 -- Robin Berjon to create a wiki page with the
list of tags -- due 2011-07-27 -- OPEN

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

ACTION-441?

<trackbot> ACTION-441 -- Frederick Hirsch to raise the HTTP vs JS
architectural issue with the TAG -- due 2011-07-28 -- OPEN

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

ACTION-442?

<trackbot> ACTION-442 -- Robin Berjon to produce a REST binding example
for Contacts (client, server, protocol) -- due 2011-07-28 -- OPEN

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

ACTION-443?

<trackbot> ACTION-443 -- Frederick Hirsch to review various ruleset
issues and follow up -- due 2011-07-28 -- OPEN

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

ACTION-444?

<trackbot> ACTION-444 -- Josh Soref to investigate ACTION-360 with
Suresh to figure out if it can be closed or should be reassigned -- due
2011-07-28 -- OPEN

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

robin: End of Actions list
... 40 open actions


      AoB

<fjh> proposed RESOLUTION: The DAP WG thanks Orange and Cécile Marc for
excellent hosting

*RESOLUTION: The DAP WG thanks Orange and Cécile Marc for excellent
hosting*

ACTION fjh to review the changes needed for the home page and priority
list based on the new charter

<trackbot> Created ACTION-445 - Review the changes needed for the home
page and priority list based on the new charter [on Frederick Hirsch -
due 2011-07-28].

fjh: no meeting July 27
... we'll have a short meeting on Aug 3

proposed RESOLUTION: no call Aug 10

fjh: I don't know if we need a call on Aug 17
... robin and Dom are away

*RESOLUTION: no call Aug 10*

Adjourned

fjh: francois thanks for being Dom


    Summary of Action Items

*[NEW]* *ACTION:* fjh to review various ruleset issues and follow up
[recorded in http://www.w3.org/2011/07/21-dap-minutes.html#action03]
*[NEW]* *ACTION:* Frederick to raise the HTTP vs JS architectural issue
with the TAG [recorded in
http://www.w3.org/2011/07/21-dap-minutes.html#action01]
*[NEW]* *ACTION:* Josh to investigate ACTION-360 with Suresh to figure
out if it can be closed or should be reassigned [recorded in
http://www.w3.org/2011/07/21-dap-minutes.html#action04]
*[NEW]* *ACTION:* Robin to produce a REST binding example for Contacts
(client, server, protocol) [recorded in
http://www.w3.org/2011/07/21-dap-minutes.html#action02]
 
[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version
1.135 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2009-03-02 03:52:20 $