# Device APIs and Policy Working Group Teleconference

## 07 Jul 2010

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Robin_Berjon, Frederick_Hirsch, James_Salsman, Dan_Burnett,
Neil_Stratford, Ilkka_Oksanen, James_, Salsman, Anssi_Kostiainen,
Suresh_Chitturi, Alissa_Cooper, Dominique_Hazael-Massieux, Erica_Newland,
erica_newland, John_Morris, Paddy_Byers, Maria_Oteo, Richard_Tibbett,
Daniel_Coloma, Ingmar_Kliche

Regrets

    Laura_Arribas, Marco_Marengo, Niklas_Widell

Chair

    Robin_Berjon, Frederick_Hirsch

Scribe

    Paddy_Byers

## Contents

  * [Topics][5]

    1. [Minutes approval from 30 June][6]

    2. [Policy][7]

    3. [APIs][8]

    4. [Contacts][9]

    5. [Gallery][10]

    6. [Capture][11]

    7. [Calendar][12]

    8. [Messaging][13]

    9. [Administrative item][14]

  * [Summary of Action Items][15]

* * *

<trackbot> Date: 07 July 2010

<darobin> nstratford: welcome to the group! it'd be nice if you could
introduce yourself a little at the beginning of the call

<enewland> p+ erica_newland

<darobin> Scribe: Paddy_Byers

<darobin> ScribeNick: paddy

<scribe> scribenick:paddy

<fjh> james question - initial configuration vs remote management

fjh: I sent out a draft agenda for the F2F.

... the F2F will be next week

... We have had logistics issues with the size of the room

... so far I think all latecomers have been accommodated

<darobin> [F2F agenda draft][16]

fjh: if you think you're coming, pls make sure Dom knows

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0042.html][17]

dom: you absolutely need to be registered if you're coming

<fjh> please indicate if you have any comment or suggestions on the agenda

dom: we are again fitting in the maximum number that we can accommodate

<fjh> logistics page [http://www.w3.org/2009/dap/wiki/LondonF2F2010][18]

fjh: logistics page is up

... I think this has all the details you need

... Anything else to say about F2F?

... the timing: it is Weds-Fri

... different times each day so check the agenda

### Minutes approval from 30 June

<fjh> [http://www.w3.org/mid/503B5689-741F-437E-
AE13-8E613ECCE84F@nokia.com][19]

**RESOLUTION: Minutes from 30 June approved**

### Policy

fjh: Just sent a reply to Dom to the list

... I understand where you're coming from but wonder if we are just going to
reinvent XACML

... I guess you've suggested a couple of things in your email

<dom> [Dom's reply to FJH's reply][20]

fjh: then go from there, eg try to incrementally invent WARP

... but I think these things are so different

... on the other hand, we already have contributions that address these issues

... perhaps we have more of a model than we think we do

paddy: in BONDI tried to do something simple but ended up with XACML to avoid
reinventing the wheel

fjh: as soon as there is any complexity, you will end up with something
similar

dom: I agree, I replied to the message with clarifications

... waht i meant by suggestio n to extend WARP wasn't intended to substitute
for policy framework

... but instead to address another part of the problem

... ie the part where authors declare what they want to do

... now, having looked more closely at WARP and how it is used for widgets

... I don't think that the framework we have fits very well with the kinds of
restrictions we might want to impose

... .eg restrictions that are specific to the way an API works

... so I think we need to look at a representative sample of APIs

... before we can know whether or not the model is applicable

... but not questioning whether or not XACML is the might model approach

... still not convinced that we understand the space of restrictions well
enough

... one of the things I sought to do in my reply is to take an action to look
are one or two APIs more closely

... as exemplars

fjh: I think what you're saying is that it is hard to link the abstract model
to actual APIs

... and I agree with this

<dom> **ACTION:** Dom to document a couple of APIs restrictions and see how it
impacts policy work [recorded in [http://www.w3.org/2010/07/07-dap-irc][4]]

<trackbot> Created ACTION-205 - Document a couple of APIs restrictions and see
how it impacts policy work [on Dominique Hazaël-Massieux - due 2010-07-14].

fjh: I will read the mail more carefully

... anyone else can help?

... also, is someone in a position to be able to approach the browser aspects
as well?

James: I would like to review all of the APIs from a consumer perspective

... and look at the privacy and policy implications of all of their
interactions

fjh: we started to look at privacy already, but if you could look at policy
especially that would be good

James: what aspects, other than privacy, do we wish to control?

fjh: Well there are several concerns addressed by access control

... there may be external control for various business reasons

... as well as user-driven control

... avoidance of prompts is one aspect

James: I would like to see something based on initial configuration

... I don't think that's incompatible with user-selectable preferences

... I would be happy to look through all the APIs with this in mind

fjh: I think the issue is how to convert concepts into something concrete,
usable, deployable, yet not too simpistic

... if you could do that, and send to list, that would be great

... I don't have much more to say

darobin: don't have much to add

... but if we are looking at usage situations for widgets then we should look
at <feature>

Suresh: a couple of observations

... for WARP, we think it is designed for widget authors to declare their
intent

... .however <feature> element is exactly that

... but <access> talks about policy-based access

<fjh> need for review and applicability of feature and access elements as
currently defined

Suresh: eg the spec says that in the default policy the UI must deny access

... so I think it is specified in-between author's intent and actual policy

... so I see some correlation but maybe not usable for our purposes as-is

... when I look at the policy framework I see three variables:

... what I think would be interesting would be to see if we can come up with a
schema like config.xml in Widgets

... perhaps we could come up with a simple expression language

... if we add some attribute for environments to config.xml would that be
enough?

... I would like to see how far we can do by extending what was done in
Widgets

fjh: I think the XACML model alread applies to what you are talking about

... so it is a question of tying the abstract model to the concrete things we
do

... I don't think we need to rework the model itself

... I'm against having a separate but "equivalent" language

suresh: just looking on the face of it we should be able to come up with
something simpler

fjh: we have a list of abuse cases but not enough "use cases"

<fjh> paddy notes confusion between parties, e.g. WARP sites to request
access, default deny, if request, get it by default., access element.

<fjh> paddy notes runtime should be also able to use policy determined by
someone other than web site author, to manage access

<fjh> suresh asks who whether author is policy writer

<fjh> paddy responds that this is noted in the BONDI use cases, various roles
and process

<dom> (policy wins over the authors intents)

suresh: thanks for the clarification

<fjh> need to separate author stated intent and runtime policy

suresh: it looks like do want to separate the author's intent from the runtime
policy

fjh: anything anyone else can do before F2F?

... I will take a look again at the BONDI docs

... one other discussion relating to permissions API

... but lets leave that discussion to the list

### APIs

darobin: I was hope to close the last ongoing issues with sysinfo

... but we don't have Bryan and I'm reluctant to make decisions in his absence

James: I have a serious disagreement about some of this

... I think there are seious privacy implications and implications on us as
engineers

<fjh> ACTION-204?

<trackbot> ACTION-204 -- Robin Berjon to step into the Bryan/James thread in
the hope of helping find consensus -- due 2010-07-07 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/204][21]

<darobin> close ACTION-204

<trackbot> ACTION-204 Step into the Bryan/James thread in the hope of helping
find consensus closed

James: so where is the line between the information needed that customers will
expect versus privacy

... customers and consumers will expect that corporations adhere to thie
expectations wrt privacy

... the line between privacy concerns and database schema is an extrmely
blurry line

darobin: I don't think there is a dispute about whether or not these issues
exist

<dom> [James' list of information he wants added in Network interface][22]

darobin: but the issue is whether or not we address them in these fields in
sysinfo

James: I didn't expect it to come up here either

... I guess I can say positively that AT&T do not degrade DNS quality

... they don't actually return invalid database results

... but some companies are know to do this

<richt> well, what can we do about that at the API level?

James: that's the kind of esoteric issue we can't deal with

<Zakim> dom, you wanted to suggest this is not something that device typically
provides info on

James: but issues as to whether or not DNS is accurate is an issue that we can
deal with, and seems to me to be necessary

... if it's not necessary then I'd like to hear why

dom: I don't think the question is whether it is important or not

... but I don't think the information is available from the device

... so we wouldn't necessarily expose it through a device API

... I think it is clearly out of scope

... so sysinfo seems to be pretty much finished based on info you can get from
the device

James: ifconfig output would give you the information needed to determine
bandwith

... similarly you could determine whether or not certain DNS requests are
resolved

dom: but these are network info issues

James: but a network device is just another kind of system device

darobin: I think it is too low level

fjh: I'd like to ask 2 things:

... first, bandwidth is there as a property so isn't this already addressed?

... second, we have already been discussing privacy extensively

... this has already been pruned to keep it simple, and bandwidth appears to
be listed. may need extensibility

... it could be refined later

thomas: take the DNS thing as an example

... there are other organisations that deal with this sort of thing

... and make very clear statements about what is expected of DNS

... there is a large ecosystem of politics, business etc about that

... also issues relating to whether or not you can do peer-to-peer for example

... the way a lot of those sort of politics work out is that people look for
win-win situations

... and this requires all relevant parties to be at the table

... such as the network operations divisions of companies

... and getting to a real win-win is more than just creating a javascript API

... so since we can't do that I suggest that we keep our own task to just
defining the API

... that is not intended to understate the importance of what you're raising

jmorris: I agree with thomas

... making these issues a precondition to defining an API seems like it will
just stall us

... but we should think about how to address it in other fora

... to get networks to be as transparent as possible

... once that happens, we can think about how to expose that info to a web
applciation

james: where do you draw the line: eg bandwidth?

<tlr> +1 to John

jmorris: we've limiting it to things we can reasonably expect a device to know

... we do not generally have access to this information right now

... but I think right now there is no common datapoint whereby a device can
discover the privacy policy of its network

james: I think most of the issues a device can figure out does not include the
privacy policy

... I think we can make progress on it after the privacy F2F

<fjh> should we add to document note that the items are those that the device
can figure out itself?

james: and a format is needed to be able to express such policies

... since then networks will be able to see how they can be measured

... instead of being measured just on their marketing capability

... and the possibilities should not be dismissed lightly

darobin: you are preaching to the choir here

jmorris: I agree it would be great to discuss outside of DAP

james: I have to ask: where is the right place to address this?

darobin: I think the W3C staff can help us understand the right place to
address this?

... on sysinfo is we assume that the current issue is moved out of scope

... then are we nearing publishability? Shall we go to CfC or wait for Bryans'
input?

james: I'd like to ask that the decision is delayed until after the privacy
workshop

darobin: it would be after the w'shop anyway because there is a 1 week comment
period

<richt> Agree with jmorris. I think we should also delay the decision until
after the F2F...still a lot for Bryan to respond to

darobin: any objection to CfC?

dom: I object, based on the upcoming w'shop and F2F

... which will limit the time available for thorough review

... personally I will not have time to review

... I will not formally object but I would rather not

<darobin> PROPOSED RESOLUTION: Two weeks CfC on SysInfo LC

darobin: would it be OK to say the CfC period is 2 weeks?

<tlr> +1 to two weeks

<richt> yep, two weeks would be good as Dom said.

fjh: remember there probably won't be a meeting in 2 weeks

darobin: we can decide by email

**RESOLUTION: Two weeks CfC on SysInfo LC**

### Contacts

richt: want to talk about DOM integation of the contacts API

... as discussed on the email

... so unifying what you can do via a non-form-based control as well as by
programmatic means

<richt> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0026.html][23]

richt: key question is where would the work be done? bearing in mind how close
this is to the discussion in HTML5?

... should the two groups work together?

darobin: we can definitely do work on this and coordinate if there is interest

risht: the same discussion relates to other areas

... and there are interesting topics to discuss between the groups

... the same issue arises with MediaCapture

suresh: just a question for richt for clarification:

... can you clarify what is the advantage of this approach, and does it have
the same power as the JavaScript approach?

... you can get access to the contact list but do you have the same
functionality you would have from JavaScript?

richt: you can get the objects by declarative means, but then use the objects
via JavaScript in the same way

<darobin> [+1 to Dom]

richt: you can use the JavaScript API to do the same operations

suresh: we have this service.contacts to get access to the contacts object

... is that the main distinction?

<Zakim> dom, you wanted to ask about formally bringing <device> in DAP, and to
suggest keeping contacts API as is for now

dom: I think we have talked about <device> again and again

... eg capture, and now contacts

... the proposal made by Hixie to DAP.

... would he be interested in making a formal proposal to DAP?

... I think integration with the <device> tag is interesting

... but perhaps we should leave that to a later stage and concentrate on the
current API for now

fjh: do we need a formal action or resolution here?

<darobin> [we can ask HTML WG, rather than WG]

dom: we need an action for someone to get in contact with Hixie

richt: don't want it to lose its place in the HTML spec

... but I don't want to lose it from DAP either

suresh: are we going to have a problem with HTML5 being a moving target?

dom: there will be issues but they can be addressed

<richt> that's it for contacts. everything else will be discussed at the F2F
next week.

dom: but the main question is whether or not we have an interest in working on
that aspect of the spec

... including having an editor, and dealing with issues with IPR commitments
etc

<richt> fyi, someone will lead the API discussion now that darobin has left?

<richt> sorry...for my information, I guess

ilkka: I have found it problematic to add attributes to MediaCapture because
of the way the HTML5 spec is written with no scope for extension

fjh: so are you saying it should not go into DAP?

<dom> [note that if we leave it to the HTML WG, it won't be taken up before X
years]

Ilkka: yes, what we have now in DAP would be better moved into HTML5

fjh: my suggestion is that someone talks to hixie

... maybe dom can talk to see what his reaction is before we progress with
this discussion

<dom> **ACTION:** Robin to contact Hixie about future of <device> tag work
[recorded in [http://www.w3.org/2010/07/07-dap-irc][4]]

<trackbot> Created ACTION-206 - Contact Hixie about future of <device> tag
work [on Robin Berjon - due 2010-07-14].

<scribe> **ACTION:** Robin to talk to Ian Hickson about interaction with HTML5
[recorded in [http://www.w3.org/2010/07/07-dap-irc][4]]

<trackbot> Created ACTION-207 - Talk to Ian Hickson about interaction with
HTML5 [on Robin Berjon - due 2010-07-14].

### Gallery

fjh: is there anything to be said on this call?

AnssiK: I put in some feedback on Gallery, until then it had been dormant

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0029.html][24]

AnssiK: perhaps now there will be some discussion

... you had some concrete conments

<dom> (editors are Kangchan and Wonsuk)

AnssiK: is there something specific that the WG needs to decide, or can the
editor deal with this?

... I think we should make the simplest use cases easy

<dom> ACTION-143?

<trackbot> ACTION-143 -- Anssi Kostiainen to provide feedback on the list on
Gallery API -- due 2010-06-15 -- PENDINGREVIEW

<trackbot> [http://www.w3.org/2009/dap/track/actions/143][25]

AnssiK: so I proposed dropping the galleries interface completely

<richt> I agree with Anssi's sentiment of dropping the Gallery API.

AnssiK: concentrate on the high-value use cases of accessing media objects and
metadata

... I think also same API design could be shared with contacts

fjh: have people had a chance to look at this?

... I think we can agree on it at the F2F

<fjh> **ACTION:** Wonsuk to review comments from anssi
[http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.html][24]
[recorded in [http://www.w3.org/2010/07/07-dap-irc][4]]

<trackbot> Created ACTION-208 - Review comments from anssi
[http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.html][24]
[on WonSuk Lee - due 2010-07-14].

AnssiK: I know that this API, as it stands now, is not useful

<fjh> **ACTION:**kangchan to review comments from anssi
[http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.htm][26]
[recorded in [http://www.w3.org/2010/07/07-dap-irc][4]]

AnssiK: you cannot do anything with it except get metadata

<fjh> **ACTION:** kangchan to review comments from anssi
[http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.htm][26]
[recorded in [http://www.w3.org/2010/07/07-dap-irc][4]]

<trackbot> Created ACTION-209 - Review comments from anssi
[http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.htm][26]
[on Kangchan Lee - due 2010-07-14].

AnssiK: you cannot get the media data (eg images) itself

... what is believed to be the status (eg how much done)?

... I would say it is a very early draft

<richt> ...the Gallery API is a copy from BONDI. I think an API based around
the FileSystem API with the MediaArray interface in Media Capture API would be
a much more sensible approach.

<AnssiK> perhaps I'll send my additional comments to the ML

fjh: thanks AnssiK

<AnssiK> One additional comment was that shouldn't there be a uri/url/URL
attribute on MediaObject object? Perhaps MediaObject could inherit from Blob?

### Capture

fjh: There was an ETA question from darobin

<dom> [Media Capture API restructured][27]

fjh: there has been various discussions on the email list

... what would you like to discuss?

ilkka: there are two versions of capture API

<fjh> Form Based Access: [http://dev.w3.org/2009/dap/camera/Overview.html][28]

<fjh> Programmatic API: [http://dev.w3.org/2009/dap/camera/Overview-
API.html][29]

ilkka: one is about form-based capture with the <input type=file> element

... the other is pure JavaScript API

... on the mailing list there is discussion ongoing about more detailed aspect
of each specification

... I think this is best discussed on the mailing list

fjh: can this be done before the F2F so we can make decisions?

ilkka: I think the detailed issues are solvable

... but the main question as to whether or not we move the form-based approach
to HTML5

... will not be solved by then

James: I agree with supporting the form-based approach into HTML5

... but using the JavaScript API can you capture and then store the captured
media to a file?

ilkka: yes, if you have FileWriter (which may trigger a prompt)

<richt> I would like to support both approaches. JS API approach with well-
defined interfaces AND a form-based approach hooking in to low-level JS API
interfaces. It is very doable IMO.

fjh: just to clarify, are you supportive of the form-based approach?

James: I am in favour of both

fjh: It sounds like people are generally in favour

... apart from the question of where things should be moved, we are close to
settling it

ilkka: lets address it at the F2F

### Calendar

fjh: anything new to be said?

... nothing new

### Messaging

fjh: where are we with messaging?

danielcoloma: we sent a message a few hours ago

... we are preparing a new proposal now

<dom> [Plan for update of messaging API][30]

danielcoloma: we will submit before F2F

fjh: thanks - anything else to discuss?

suresh; I think the best way forward is to pick up where we left off, which is
what Daniel seems to be doing

scribe: if we can pick up from the earlier thread it would be a good start

danielcoloma: yes, that's what we are doing

### Administrative item

fjh: Propose no calls on 21 July and 28 July

... so next call is 4 August

... any objection or concern?

**RESOLUTION: calls on 21 July and 28 July are cancelled**

fjh: is that it?

... if not, lets adjourn

... see you next week

... we have published agenda and we will do the best we can to stick to it

... but flexibility is required

suresh: appreciate putting my topics in the afternoon

... but happy to be flexible

... is there a bridge set up?

dom: I have confirmation that we can have a bridge

fjh: adjourned

## Summary of Action Items

**[NEW]** **ACTION:** Dom to document a couple of APIs restrictions and see
how it impacts policy work [recorded in [http://www.w3.org/2010/07/07-dap-
irc][4]]

**[NEW]** **ACTION:** kangchan to review comments from anssi
[http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.htm][26]
[recorded in [http://www.w3.org/2010/07/07-dap-irc][4]]

**[NEW]** **ACTION:** Robin to contact Hixie about future of <device> tag work
[recorded in [http://www.w3.org/2010/07/07-dap-irc][4]]

**[NEW]** **ACTION:** Robin to talk to Ian Hickson about interaction with
HTML5 [recorded in [http://www.w3.org/2010/07/07-dap-irc][4]]

**[NEW]** **ACTION:** Wonsuk to review comments from anssi
[http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0029.html][24]
[recorded in [http://www.w3.org/2010/07/07-dap-irc][4]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][31] version 1.135 ([CVS
log][32])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0031.html

   [4]: http://www.w3.org/2010/07/07-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #ActionSummary

   [16]: http://www.w3.org/mid/1C510657-258D-48B8-A2BB-D8A71D693CAF@nokia.com

   [17]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0042.html

   [18]: http://www.w3.org/2009/dap/wiki/LondonF2F2010

   [19]: http://www.w3.org/mid/503B5689-741F-437E-AE13-8E613ECCE84F@nokia.com

   [20]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0048.html

   [21]: http://www.w3.org/2009/dap/track/actions/204

   [22]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0019.html

   [23]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0026.html

   [24]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0029.html

   [25]: http://www.w3.org/2009/dap/track/actions/143

   [26]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0029.htm

   [27]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0033.html

   [28]: http://dev.w3.org/2009/dap/camera/Overview.html

   [29]: http://dev.w3.org/2009/dap/camera/Overview-API.html

   [30]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jul/0043.html

   [31]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [32]: http://dev.w3.org/cvsweb/2002/scribe/