<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

Welcome

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

Minutes approval

<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0045.html

fh: asking about minutes approval

<drogersuk> I am here, 'this passcode is not valid: 3279#' :-(

<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0045.html

<fhirsch> RESOLUTION: Minutes from 30 Sept approved

Policy Segment - API Identification

<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

policy - use of model dialogs

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

Policy action review

<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.

API Segment

<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

Adjourn

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/margin/marcin/
Succeeded: s/anssi/marcin/
Succeeded: s/open/opens/
Succeeded: s/were/we're/
Succeeded: s/drogersuk:/paddy:/
Found Scribe: Anssi Kostiainen
Found ScribeNick: AnssiK
Default Present: Kangchan
Present: Kangchan Ilkka_Oksanen Robin Dzung_Tran Paddy_Byers wonsuk AnssiK Niklas_Widell Marcin_Hanclik Jere_Kapyaho Laura_Arribas Richard_Tibbett Claes_Nilsson Brian_LeRoux
Regrets: Dominique Hazaël-Massieux Marco_Marengo maxf
Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0066.html
Found Date: 07 Oct 2009
Guessing minutes URL: http://www.w3.org/2009/10/07-dap-minutes.html
People with action items: marcin robin