See also: IRC log
<trackbot> Date: 18 November 2009
<marengo> i'm not [IPCaller]
<ilkka> +Present Ilkka_Oksanen
<BryanSullivan> +present BryanSullivan
<darobin> Scribe: Arve
<darobin> ScribeNick: arve
<Suresh> Suresh just joined the bridge
fhirsch: Geolocation WG is taking on API for orientation and acceleration data from device
<maxf> arve: does it mean that that item won't be covered by this WG?
<BryanSullivan> "Acceleration" is not the same as "accelerometer", correct?
<maxf> robin: yes
<dom> I think Acceleration is the same as accelerometer
robin: This WG will not take on these item
<BryanSullivan> Accelerometer should be outside their scope
<Dzung_Tran> Did someone pass along the Compass spec that I did to the Geolocation WG?
suresh: we need to find a way to handle overlap with other groups
BryanSullivan: Accelerometer is not the same as acceleration
<BryanSullivan> Accelerometer is in general an example issue for sensor API's - GeoLocation is a special case.
we should be careful about geolocation wg expanding their scope
drogersuk: How do we logically separate accelerometer and acceleration data?
<Suresh> We need find a way to integrate other "device APIs" work (e.g. geo-location, accelorometer) in to DAP WG deliverables or at the minimum reference them
<dom> [as a point of order, I think people would better react on announcements when they're made on the list, rather than waiting for the call to make their points]
<Zakim> darobin, you wanted to point out that this is a good reason to do anything related to policy outside of the API specs and to point out that we've already resolved that "general
<drogersuk> my point doesn't seem to have been minuted:
<drogersuk> drogersuk: We need to look at the clear logical separations between functionality - e.g. geolocation and accelerometer, they are probably independent functions
<darobin> RB: to Suresh's point, I would like to say that we should simply do policy orthogonally from APIs so that we can also cover other WGs' APIs
<darobin> RB: to Bryan's I would like to point out that we're not working on generic sensors, so there's no chartered requirements to prevent Geo from doing Accelerometer — if they have the bandwidth then by all means we should be happy to have less to do
<maxf> Geolocation WG's action item where draft on "orientation and acceleration" is proposed: http://www.w3.org/2009/11/03-geolocation-minutes.html#action05
<marcin> +1 to orthogonality
<Suresh> I agree with what Robin just said in separating the policy from APIs
<dom> [I think that "FUture APIs are not considered a priority" is a sufficient statement to make to clarify the situation]
<darobin> +1 to dom
<marcin> +1 to dom & darobin
+1 to dom
<drogersuk> we don't want to discourage people from creating new things though
<drogersuk> it just won't be discussed as it is not in charter
<marcin> specifying policy for existing APIs will be a good exercise for the future APIs
<fhirsch> F2F Scheduling
<scribe> ACTION: dom will update home page to reflect "Future apis are not a priority" [recorded in http://www.w3.org/2009/11/18-dap-minutes.html#action01]
<trackbot> Created ACTION-61 - Will update home page to reflect "Future apis are not a priority" [on Dominique Hazaël-Massieux - due 2009-11-25].
<dom> PROPOSED RESOLUTION: next WG F2F in Prague on March 16 to 18
drogersuk: 16-18 might collide with SXSW for some members
<richt> I may go to SXSW but it is not yet confirmed
drogersuk: need to avoid overlap with omtp meeting, there seems to be none
darobin: only overlap with SXSW currently seems to be drogersuk
drogersuk: there will be noe overlap with OMTP
dom: april an alternative
arve: would prefer march
<fhirsch> prefer march
<darobin> drogersuk: OMTP are always happy to host in London
fhirsch: would propose resolution
<darobin> ACTION: Robin to contact Prague uni to ask if we can meet on 16-18/03 [recorded in http://www.w3.org/2009/11/18-dap-minutes.html#action02]
<wonsuk> +1 for March
<trackbot> Created ACTION-62 - Contact Prague uni to ask if we can meet on 16-18/03 [on Robin Berjon - due 2009-11-25].
RESOLUTION: Meeting date set to 16-18/03 2010
fhirsch: Is the meeting 2.5 days or 3?
+1 to 2.5
<Claes> +1 for 2.5
<wonsuk> +1 for 2.5
<Laura_Arribas> +1 for 2.5
<marengo> +1 for 2.5
<drogersuk> lol make it 3.5 then
<darobin> I think 5.5
<marcin> 0 to 2.5 and/or 3
<AnssiK> why not 2^2?
proposed resolution: meeting will be 2.5 days?
RESOLUTION: meeting will be 2.5 days
<darobin> RB: we could perhaps start at 11 the first day and finish at 1530 the last day
fhirsch: any objections to approving minutes from last meeting
<fhirsch> Policy Requirements Editors Draft updated
fhirsch: please review document
<scribe> ACTION: Laura_Arribas to review http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0044.html [recorded in http://www.w3.org/2009/11/18-dap-minutes.html#action03]
<trackbot> Sorry, couldn't find user - Laura_Arribas
<dom> ACTION: Laura to review http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0044.html [recorded in http://www.w3.org/2009/11/18-dap-minutes.html#action04]
<trackbot> Created ACTION-63 - Review http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0044.html [on Laura Arribas - due 2009-11-25].
<Laura_Arribas> ACTION: Laura Arribas to review last reqs document [recorded in http://www.w3.org/2009/11/18-dap-minutes.html#action05]
<trackbot> Created ACTION-64 - Arribas to review last reqs document [on Laura Arribas - due 2009-11-25].
[?] Contacts API updated to use vCard
<fhirsch> richard notes has updated contacts using vcard, working on security considerations and use cases
<fhirsch> Markup for implicit consent
<Suresh> richard, can you post the link to the contacts API draft, please?
<richt> Contacts API Latest Editor's Draft: http://dev.w3.org/2009/dap/contacts/Overview.html
<maxf> ok. I'll call back
<richt> regarding the contacts api: you may need to do a refresh or clear cache. I was having problems with the etags (or something) not refreshing the page.
<dom> Bryan, http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/att-0120/minutes-2009-10-07.html#item06 re agreement to publish FPWD
<trackbot> ACTION-47 -- Laura Arribas to provide input on trust model and access control model definitions -- due 2009-11-10 -- PENDINGREVIEW
maxf: I had the action item to explore reusing security from file upload control
for implicit user consent
maxf: the idea was to figure out if model applied to other apis
<dom> +1 on figuring the process to specify possible markup aspects of our APIs as we go
fhirsch: does this apply for widgets and/or webapps?
maxf: will investigate
<maxf> arve: do we have the necessary expertise in the area?
<maxf> … just as much about usability
<fhirsch> frederick asks where we define input types, robin notes either in HTML WG or here as appropriate, can do later
<BryanSullivan> +1 to no "one shoe fits all"
<maxf> … I would propose relieveing max of his action item and revisit it later
<fhirsch> need to define input element for each API , part of API definition
<maxf> … e.g. file system access. There's a lot about making the API usable. … geolocation ...
<Suresh> i don't believe this model of input="xx" fits all the use cases,
<richt> agree with suresh but we need use cases in our documents though to justify that.
<fhirsch> max, can you please check status of HTML WG and how process would proceed for defining input types
<dom> [I think the idea behind MaxF's action was to put some ideas on the table that we can take from when looking at specific APIs]
Suresh: too early to agree on the topic
<BryanSullivan> we need to recognize that a UI-based approach will not address all use cases, e.g. to create accessible webapps or that work well in input/output constrained devices.
Suresh: are we restricting ourselves to this, or is it just one of many options
fhirsch: it's one option, not _the_ option
<dom> [well, the important thing would be to look at specific use cases that wouldn't be addressed by this, so that we understand better the limits of the approach]
<dom> [I think the people that are skeptic should do that :) ]
<AnssiK> <input type="foo"> approach is nice in a sense it provides both programmatic (via DOM API) and declarative (ie. markup) mechanisms
+1 to darobin's written proposal
<trackbot> ACTION-47 -- Laura Arribas to provide input on trust model and access control model definitions -- due 2009-11-10 -- PENDINGREVIEW
<Dzung_Tran> agree with robin, each person who owns their API needs to apply the input/output as you see fit
<dom> ScribeNick: dom
Laura: both approaches are significantly similar
... the major difference is that Nokia considers the trust manager and the access manager separately
... the access manager makes the final access decision
... BONDI has a different architecture — the trust decision is included in the access manager
... there are also differences in the policies
... Nokia consider 2 polices: trust, and access control
... BONDI doesn't make that differenciation and includes everything in the same policy
<lgombos> have a hard limit, have to drop of, sorry
Laura: I would welcome reviews on my summary
... I don't have specific ideas on how to integrate in the requirements document
Frederick: I'm not quite sure why BONDI wouldn't consider access control and trust management as separate concerns
<richt> unfortunately I need to leave the call for another meeting :(
Frederick: I need to look more closely in the specs
<richt> I will catch up with the minutes and follow up on the mailing list.
<Dzung_Tran> So should we review and discuss on the mail list?
Laura: it allows to group permissions in different domains
<Suresh> i don't think trust and access control should be treated separately, a decision needs to be take with both into account
Bryan: the distinction between trust and policy in Nokia is essentially a way to organize the data (the files)
... it's equivalent to what we have in BONDI
... they're functionally equivalent, it's just the way the data is organized
Frederick: so Policy Management is out of scope of our work, but it has an impact on our scope of work on policy definitions
... I'll look more closely to the BONDI specs
David: in BONDI, we've left open policy management
... In the discussions on the mailing list, I'm not sure what are the alternatives on defining a policy framework at some point (e.g. for filesystems API)
Frederick: could you send an email on that topic?
David: I've done that already
Bryan: the management of policy (storage, updates, user decision involvement) is out of scope
... the definition of a policy file, an expression of a policy as a set of API permissions etc, should be in scope
... it's not directly influenced by policy management
... it's more dependent on APIs and their security aspects
... if we go deeper into UI considerations, we also need to take into account enabling a similar set of features in a policy-based approach
Frederick: I keep coming back to the question of who's writing the policy
... if you don't have a model of this, I think it's hard to understand the use cases for the policy framework
Robin: we've discussed making Capture a priority item for the roadmap
<drogersuk> correction to minutes above: For people who are saying we don't need policy - I don't see the alternative once you've run out all the ways of designing the API securely apart from deferring the decision to the user - I'd like to see input to this because it will help the FileAPI and FileSystem API discussions progress
PROPOSED RESOLUTION: Make capture (Video/Photo/Sound) a priority API
RESOLUTION: Make capture (Video/Photo/Sound) a priority API
Robin: within the priority documents, I would like to assign action items for people to come up with first editors drafts
... we already have one for contacts (Richard), but everyone is welcomed to help
... Richard has already started working on Calendar, but would be helpful if he got help
... what about messaging?
Claes: I'm interested to take on that
Robin: Daniel Coloma was also interested
<Dzung_Tran> I can take on Capture
<scribe> ACTION: Claes to provide an editors draft of the Messaging API - due in two weeks [recorded in http://www.w3.org/2009/11/18-dap-minutes.html#action06]
<trackbot> Created ACTION-65 - provide an editors draft of the Messaging API [on Niklas Nilsson - due 1970-01-01].
Frederick: suresh, did you mention you were interested in Calendar?
Suresh: yes, but RObin said Richard was working on it
<nwidell> ACtion-65 should be on nwidell
Suresh: I'll work with him
<trackbot> ACTION-65 -- Niklas Nilsson to provide an editors draft of the Messaging API -- due 1970-01-01 -- OPEN
Robin: what about Capture? Dzung?
<scribe> ACTION: Dzung to provide an editors draft of the Capture API [recorded in http://www.w3.org/2009/11/18-dap-minutes.html#action07]
<trackbot> Created ACTION-66 - Provide an editors draft of the Capture API [on Dzung Tran - due 2009-11-25].
Ingmar: I'm happy to help on Capture as well
Robin: if any of the editors don't have access to CVS, please contact Dom (but not DOM)
... what about FileSystems?
... I'll take a stab at it
<scribe> ACTION: Robin to provide a first editors draft of the FileSystems API [recorded in http://www.w3.org/2009/11/18-dap-minutes.html#action08]
<trackbot> Created ACTION-67 - Provide a first editors draft of the FileSystems API [on Robin Berjon - due 2009-11-25].
Bryan: I'll provide feedback on it
Robin: We've had sysInfo in CVS for a while
... please provide feedback as soon as possible
... so that we can decide to move to FPWD
Bryan: I've provided input FWIW
<Dzung_Tran> Sorry what is FWIW?
<trackbot> ACTION-58 -- Bryan Sullivan to make a concrete proposal with a vocabulary-based approach to system & events, with a few examples (e.g. battery level) -- due 2009-11-11 -- OPEN
Bryan: regarding the FWPD of requirements, it wasn't clear to me that we had reached consensus on the content of the document
... I'd like to see my set of requirements integrated in the document
... it looks like new requirements are impeded to get in the document
<fhirsch> FPWD simply means to publish draft which is subject to change
Robin: as an editor, I was hoping you would provide help in adding your reqs there
... put it in the document — that will make it more likely for people to react :)
David: maybe there should be a separate call for editors to help them set them up
Robin: I'm not saying that people should always put their feedback in the doc; but when not getting feedback, it can be a useful tool
... regarding helping editors, it would be helpful to know what the questions are
... send me emails, and then I can figure out the best format to help people out
Maxf: you've listed the 4 priority APIs documents, but also listed capture which is in the "other" category
Robin: we've just resolved to make it a priority
MaxF: but what happens with the other ones?
... I'm in the editors pool
... I could either help on the priority ones, or start working on another one
Robin: it's perfectly fine to start on a new one; we might just spend less time discussing it
MaxF: who wrote Sys and Events?
Maxf: I'd like to help with that one
<drogersuk> just to understand, is this based on any of the input?
Robin: please coordinate on the list
<Dzung_Tran> Sure, no problem
David: is SysInfo based on any of the input doc?
Robin: I think it's something Dzung came up with
<Dzung_Tran> Yes, it is based on Nokia, BONDI, ..
David: Would Dzung be willing to look at the input to the charter and integrate it in SysInfo
<drogersuk> ok thanks
Robin: Dzung says on IRC it's based on Nokia and BONDI
... it probably took them into account
David: Ok, just wanted to clarify that point
[@@@]: I'm seeing a lot of regrets for next week
Robin: we might have to cancel
<Dzung_Tran> I think we should cancel
[xxx]: can't we make a decision now?
+1 on canceling
<fhirsch> need to decide in advance so people can plan
<Dzung_Tran> Most people in US are out on Thanksgiving holiday
RESOLUTION: no meeting next week, next meeting on Dec 2
<marengo> /me bye
<marcin> bye bye