See also: IRC log
<trackbot> Date: 25 August 2010
<dom> ScribeNick: Claes
<darobin> Scribe: Claes
<fjh> next F2F WG questionnaire and TPAC registration and information
<fjh> WG questionnaire (for all), http://www.w3.org/2002/09/wbs/43696/tpac2010dap/
<fjh> TPAC registration (for in-person attendees) http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/
<fjh> March F2F questionnaire (Seoul, Korea)
<dom> [the F2F questionnaire is closing today - should I extend it or do we want to make a resolution today for the dates?]
fjh: Extend it
<dom> (I've updated the questionnaire closing date to next week)
<fjh> Approve 18 August minutes
RESOLUTION: 18 August minutes approved
<fjh> Editorial update completed
<scribe> New version August 25
<fjh> proposed RESOLUTION: Publish updated WD of Device API Access Control Use Cases and Requirements on 26 August 2010.
<darobin> [I'm always in favour of publishing]
Dom: Not read new version
... requests time
Robin: Put out CFC before
<dom> ACTION: Dom to review new version of policy-reqs [recorded in http://www.w3.org/2010/08/25-dap-minutes.html#action01]
<trackbot> Created ACTION-259 - Review new version of policy-reqs [on Dominique Hazaël-Massieux - due 2010-09-01].
RESOLUTION: Issue CFC before publishing updated WD of Access Control Requirements
<fjh> ACTION: fjh put out cfc for policy requirements [recorded in http://www.w3.org/2010/08/25-dap-minutes.html#action02]
<trackbot> Created ACTION-260 - Put out cfc for policy requirements [on Frederick Hirsch - due 2010-09-01].
fjh: Feel free to propose text for doc
<fjh> Updated, see http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0071.html
<fjh> Next steps - Remove section 2 and publish FPWD
Would like to publish as FPWD
<Zakim> dom, you wanted to ask about getting feedback from Doug/IanF
Dom: Would like to get feedback from Doug Turner and Ian Fette
... No response received yet
<fjh> ACTION: fjh to get feedback from Doug Turner and Ian Fette [recorded in http://www.w3.org/2010/08/25-dap-minutes.html#action03]
<trackbot> Created ACTION-261 - Get feedback from Doug Turner and Ian Fette [on Frederick Hirsch - due 2010-09-01].
fjh: Would like to get a wider view by publishing
Suresh: Why listing only BONDI and Android?
<dom> [FWIW, +1 on publishing something; but I think we shouldn't miss the opportunity to attract people that have stated interest on this topic]
fjh: Want to get a starting point by informaional text on what we have today, easier to make progress once we have something started
<fjh> ACTION: fjh to clarify in features document to clarify that BONDI and Android material are informative examples and that result will be DAP [recorded in http://www.w3.org/2010/08/25-dap-minutes.html#action04]
<trackbot> Created ACTION-262 - Clarify in features document to clarify that BONDI and Android material are informative examples and that result will be DAP [on Frederick Hirsch - due 2010-09-01].
Suresh: Want's only DAP features as normative and other stuff as informative
Dom: not complete enough for publishing
<dom> ACTION: Dom to take a stab at DAP features doc [recorded in http://www.w3.org/2010/08/25-dap-minutes.html#action05]
<trackbot> Created ACTION-263 - Take a stab at DAP features doc [on Dominique Hazaël-Massieux - due 2010-09-01].
<trackbot> ACTION-210 -- Alissa Cooper to summarize and add issues to ruleset doc -- due 2010-07-21 -- OPEN
John is not here..
Liaisaon from OMA on CAB
<Suresh> Latest version of OMA CAB XDMS spec: http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-CAB/Permanent_documents/OMA-TS-CAB_XDMS-V1_0-20100816-D.zip
OMA suggests that we adopt CAB and that we look for some common subset from CAB, PoCo etc
<AnssiK> this PoCo mapping to others (by Chris Messina) may be useful: http://spreadsheets.google.com/pub?key=pSGbbhtwI4kN_nJ1GXeQ7Qg
Robin: OMAproposes that we support common fields between these formats
... either adopt complete CAB or subset of common standards
Richard: Lots of overlap
Ansi: PoCo mapping format
... see link above
<fjh> richard: is DAP goal to be compliant with OMA or across various formats in the table?
Richard: Our objective? Objective to comply to OMA or to these other formas
Suresh: Option 1: OMAformat, Option 2: DAP provides common fileds and provides mapping table
... prefers Option 2
... we have vCard, PoCo, CAB
<AnssiK> [more PoCo related resources at: http://wiki.portablecontacts.net/Software-and-Services-using-Portable-Contacts]
Suresh: look at suggestion 2
... our main task is API
... look at other formats
Tlr: Do we know the OMA work relates to vCard 4 work?
<dom> (I think a mapping table would help get a better idea of the situation; but I doubt an API floating above vocabularies would be useful)
Suresh: We know that vCard4 was limited.
<darobin> [fwiw I agree with dom — it would be good to fill out that spreadsheet with CAB to see if there's enough overlap for it to be useful ]
Suresh: OMA has mapping between CAB to vCard 2.1
<darobin> [it would be nice to keep the model we have and add a "Mapping to CAB" annex — assuming it's even possible...]
<dom> [As an example, LDAP has defined such an API without a well-defined vocabulary; as a result, interoperability across LDAP clients is nightmarish]
Tlr: How stable?
Suresh: Will be frozen in a week.
Tlr: A bunch of moving parts, Mozilla seems to be bringing PoCo to IETF
<fjh> tlr suggests convergence is happening toward vcard 4, thus would prefer not to specify yet another format
Tlr: hate to see us specify yet another format
<richt> Any public links to PoC dicussions in IETF vCard efforts?
Tlr: we could try to get a relevant people (PoCo, vCard, OMA, us) together, first by an e-mail list
Richt: We have the beginning of some thng converging
... interesting discussion in vCard4. Could we work with them?
... OMA view on vCard4
<fjh> richard asks if OMA is working on supporting vcard4 and when a new version might happen
Suresh: OMAhas mapping towards vCard 2.1 and 3
<Suresh> Suresh: getting all the groups together will be a long shot and the quicker solution would be to stick to common fields across the different formats
Rich: An API comptable with PoCo if vCard4 is aligned and aligned with CAB?
Robin: Needs a speradsheet as basis for a possible mapping
<AnssiK> +1 to Robin's proposal
Rich: Start with wiki
<darobin> ACTION: richt to produce a spreadsheet of sorts showing overlap/mapping/correspondance between vcard4, poco, cab, and us [recorded in http://www.w3.org/2010/08/25-dap-minutes.html#action06]
<trackbot> Created ACTION-264 - Produce a spreadsheet of sorts showing overlap/mapping/correspondance between vcard4, poco, cab, and us [on Richard Tibbett - due 2010-09-01].
Robin: we are currently missing information if mapping is at all possible
<richt_> ideally we will endorse THE format - not one format or another :)
<Suresh> The question is as a group do we want to endorse a format?
<richt_> that still requires a lot of work across all the different groups.
Tlr: A spreadsheet will put the discussion on a more informed basis.
<darobin> +1 to talk, but I want the data first!
Tlr: there ought to be some way of achieving convergence
... next step will be to tie together relevant people at a common place
Robin: Great plan
<tlr> Badulescu, Blanchet, Celik, Hanson, Smarr, Messina, Daboo
<darobin> ACTION: tlr to send an email to start the Contacts Schema Alignment discussion [recorded in http://www.w3.org/2010/08/25-dap-minutes.html#action07]
<trackbot> Created ACTION-265 - Send an email to start the Contacts Schema Alignment discussion [on Thomas Roessler - due 2010-09-01].
Suresh: Wants to participate
<darobin> Robin: any news?
<darobin> tlr: need to figure out if we need to split the call so as to help Koreans, I'm working on it and will dig into it
Tlr: Basic plan to see if we can separate the lunar cal discussion into different tme slot
Suresh: Current draft reflects what we discussed in London
... confortable with current draft for the basic use cases
<dom> [err... the draft has already been published as FPWD, right?]
<dom> Messaging FPWD
<darobin> Messaging issues
Robin: Keep coming back to scoping issues
... don't know how to solve them
... want clear use cases for these APIs for the browser use case without policy
<dom> +1 to robin
<trackbot> ACTION-253 -- Suresh Chitturi to make proposals for Contacts and Messaging features in a trusted context due in three weeks -- due 2010-08-31 -- OPEN
Suresh: We might define options for only browsers version widgets
... have a solid API that is browser API and subset for widgets?
... will look at Action -253 next week
<Suresh> The idea is that we have a full API (for trusted environement) and create a compatible subset that would be targeted for the Browser
Look at privacy text but John not here