See also: IRC log
<trackbot> Date: 07 October 2009
<darobin> AnssiK, will you be joining the call today?
<darobin> Kangchan: it's too early, the call starts in 5 minutes
<Kangchan> Robin: Thanks..
<darobin> and the correct syntax is "Present+ KangchanLee" :)
<darobin> Victims list is: wonsuk, AnssiK, Mohammed, Daniel, Rob Ennals
<darobin> Scribe: Anssi Kostiainen
<darobin> ScribeNick: AnssiK
<dtran> +dtran
<dtran> +dtran
fh: everyone, please say "Present+ YourNick"
<fhirsch> TPAC registration and hotel reminder, registration until 23 October
fh: TPAC extended the lower registration fee period
... there's also a dial-up questionnaire, please fill it in if you plan to call in to TPAC
<fhirsch> Mobile Web Application Best Practices
<fhirsch> http://www.w3.org/TR/2009/WD-mwabp-20091006/
<fhirsch> ask for reviewed
<darobin> ACTION: Robin to review MWABP [recorded in http://www.w3.org/2009/10/07-dap-minutes.html#action01]
<trackbot> Created ACTION-26 - Review MWABP [on Robin Berjon - due 2009-10-14].
fh: the questionnaire is actually closed, so send an email to the members list instead
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0045.html
RESOLUTION: Minutes from 30 Sept approved
<drogersuk> I can hear you all now, thank you W3C office for letting me in!
<fhirsch> issue-26?
<trackbot> ISSUE-26 -- How to refer to API -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/26
fh: features, attributes, modules discussed in the context of Policy
<fhirsch> question of granularity of access control for APIs
marcin: not sure if agrees on the granularity level
<fhirsch> do we agree on granularity at method level, or group of methods called a feature
<fhirsch> how to deal with modules as a whole
marcin: ... in BONDI we added attributes and constants under feature
<fhirsch> what is approach to attributes
<Zakim> Thomas, you wanted to note that there are different security considerations for adding a contact or reading one
<fhirsch> note that we may want to raise issue for security related to events/callbacks
Thomas: question about an API that can access data storage
<tlr> the point is less about storage, but more about the distinct security considerations... This is an example.
marcin: you can do everything on storage
<brianleroux> +Brian_LeRoux
Thomas: for reading and writing or reading, depending on the UC I might have different security considerations
<tlr> thx
<brianleroux> ah, thx
marcin: current filesystem API from BONDI has filesystem.read and filesystem.write
... all methods and attributes are covered needed to read from the file
... CRUD mentioned
... as in Create, Read, Update, Delete
<fhirsch> marcin suggests that features need to be defined according to CRUD, one feature for each...
marcin: we'll need a CRUD design pattern for all the APIs
... example: open, read and close methods
... reading UC: we should also cover the constants
... opening a file uses reading and writing?
... someone who has access to the file reading UC could open a file in a write mode and open would be succesful in write mode
... what happens if someone opens the file in truncate mode
fh: the issue with callbacks and events
marcin: I don't know how it's expessed with a URI
<fhirsch> Marcin notes may not protect existing events, but restrict new events and handlers introduced in DAP
marcin: events such as keypress discussed
JereK: if you are given access to a function, callbacks should be also allowed
marcin: callbacks that are parameters to event listeners will be handled
<fhirsch> feature may include method plus input arg to be meaningful, eg file open with read or write input argument would correspond to different features
<tlr> declarative definition of handlers in mark-up
<tlr> input events
marcin: handlers such as onkeypress
<fhirsch> input events - see email from David Rogers...
marcin: handlers the concern, not the callbacks
fh: there's many ways code can be executed
<marcin> About features, possible principle: "protect information, not APIs that are behind it"
fh: URIs seem to be a good approach, there seems to be a general agreement
<marcin> About events: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0069.html
fh: hierarchical use of features
... one API can invoke another API
<fhirsch> issue-27?
<trackbot> ISSUE-27 -- [Policy] Is revocation in scope -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/27
fh: do we want to discuss revocation?
... there are many mechanisms
... wants to raise the issue explicitly
<JereK> charter, section 2.2: "The management of security policies ... is out of scope"
<fhirsch> management is out of charter scope, so I believe we should consider revocation out of scope
drogersuk: kill switches discussed
<fhirsch> but I suggest we can consider authentication in scope
drogersuk: we should leave the policy discussion to the end?
... do we have an e2e view re policy?
<drogersuk> I agree that the detail can be deferred, but we need to acknowledge it somewhere
<tlr> +1 to deferring
<drogersuk> in a policy overview doc or something
<drogersuk> so policy needs to come from somewhere and then go somewhere (good or bad) - e.g. removal / revocation / kill-switches / management
fh: do the others have comments re deferring to v.next?
<JereK> +1 to defer
<paddy> +1 to more time
<wonsuk> +1 to defer
<drogersuk> I agree with Paddy
<drogersuk> we need to scope
paddy: what's the scope for work we're deferring?
<fhirsch> proposed resolution- defer specifying revocation mechanisms or expressing them until v.next
paddy: BONDI specifics discussed
<drogersuk> anssik: paddy
<tlr> fjh - agreement: 1. defer, 2. keep some hooks
fh: paddy to provide a proposal for resolution
... I raised another issue on the list based on position papers
... feedback given we should not be so strict
... Geolocation API is a bit different
marcin: Geolocation spec not limited to dialogs
<fhirsch> issue-28?
<trackbot> ISSUE-28 -- [Policy] Requirement for NO security prompting -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/28
<Zakim> Thomas, you wanted to speak to a scope point here
Thomas: having too many conversation on security UIs
... non-modal UIs discussed
... we should not specify APIs which require modal dialogs
... modal dialogs are blocking
<marcin> +1 to non-blocking / asynchronous methods
Thomas: UA differences to be taken into consideration
fh: easy out for security policy to use modal dialogs
<tlr> +1
<fhirsch> action-15?
<trackbot> ACTION-15 -- Marcin Hanclik to review/compare device capabilities and features -- due 2009-09-30 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/15
<fhirsch> action-15 closed
<trackbot> ACTION-15 Review/compare device capabilities and features closed
marcin: sent an email re the action above
<fhirsch> action-23?
<trackbot> ACTION-23 -- Paddy Byers to open an issue and start a discussion on features/device capabilities -- due 2009-10-07 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/23
fh: capabilities and features under discussion
paddy: will send an email to the list
fh: any topics on policy I have missed?
... otherwise let's move on to APIs
<paddy> Scope excludes UA requirements relating to support for revocation, including support for specific certificate profiles, OSCP profiles, or any requirement to support certificate status/CRL checking.
<paddy> Scope includes ensuring there is provision within any formats or policy or trust model that may be necessary, under reasonably foreseeable use cases, to allow such requirements to be specified independently.
RESOLUTION: Scope excludes UA requirements relating to support for revocation, including support for specific certificate profiles, OSCP profiles, or any requirement to support certificate status/CRL checking.
... Scope includes ensuring there is provision within any formats or policy or trust model that may be necessary, under reasonably foreseeable use cases, to allow such requirements to be specified independently.
<darobin> http://dev.w3.org/2009/dap/api-reqs/Overview.html
darobin: please review the requirements so that we can publish it as a Note
... Working Draft actually before a Note
JereK: system information sensor access lumps sensors under sysinfo
... should those be split
... aka Sensor API
darobin: what should be in the first version of the requirements document
... the 1st version we put out do not have to be perfect
... ok to push the document out with the sensor issue?
<paddy> +1 for dedicated extensible sensor API
JereK: NFC mentioned
<drogersuk> NFC is a write and read transducer
<drogersuk> sensor and 'actuator'
Thomas: WD should be published ASAP
<Claes> +1 for extensible sensor API
<brianleroux> +1 to publish
darobin: any concerns re fast publication?
<brianleroux> +1 for sensors
fh: it would be valuable to get feedback, and publishing a WD is a good way to accomplish that
RESOLUTION: publish a Working Draft of the Requirements document before TPAC
darobin: proposing a doing quick actions review, if no specific issues
<brianleroux> hey, sorry my call dropped
<brianleroux> yes to file and camera
<fhirsch> action-19?
<trackbot> ACTION-19 -- Brian LeRoux to leroux to review contact, camera, file-system -- due 2009-09-30 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/19
ACTION-21?
<trackbot> ACTION-21 -- Bryan Sullivan to send comments about Arve's requirements for ISSUE-6 -- due 2009-09-30 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/21
darobin: AOB
... straw-poll on device object
drogersuk: about Contacts API, are we taking Nokia, BONDI and PhoneGap inputs as is or start from the scratch
darobin: we're starting with requirements gathering
... the draft was to kick-start the work
<drogersuk> so it could be 'another' API to add to the mixx
darobin: took parts from both Nokia and BONDI
<brianleroux> drogersuk: the more we look at the better / PhoneGap is an aggregate of all the mobile smartphones
drogersuk: concerned on the length of time it'll take to produce the specs
<brianleroux> however, for example, I quite like googles contacts api for gmail, etc
<drogersuk> what about design patterns for example?
darobin: we can start with existing inputs, but both have issues so it would not actually speed things up
drogersuk: design patterns should provide the basis for all the APIs
darobin: patterns easier to derive from concrete work
drogersuk: we should draw from the experience from the inputs
darobin: not sure how we're not using prior art to our advantage
drogersuk: to dive into specific API and doing it again could end up in doing more work
darobin: argument understood, not clear what is proposed to address it, publish patterns beforehand?
marcin: re design patterns, in BONDI we have tried to identify the patterns
... similar document could be delivered to DAP
<drogersuk> can we agree a clear strategy in terms of API design?
<darobin> ACTION: Marcin to provide a design patterns document before TPAC [recorded in http://www.w3.org/2009/10/07-dap-minutes.html#action02]
<trackbot> Created ACTION-27 - Provide a design patterns document before TPAC [on Marcin Hanclik - due 2009-10-14].
drogersuk: wants to see a strategy how we'll deliver the APIs instead adademic discussion on API design
darobin: AOB
Bryan: would like to see design patterns done fast, there's market momentum which would benefit us moving fast
drogersuk: looking at the inputs and conflicts in them
darobin: we have three primary inputs, in some cases four
<richt> q
darobin: it would be a bruising process if we start looking into inputs in details
drogersuk: can we identify areas where we agree on
darobin: beneficial approach for generic patterns
<drogersuk> in APIs too, not just the patterns
darobin: we as a group don't want to do the same mistakes as what's potentially present in the input