See also: IRC log
<trackbot> Date: 27 January 2010
<darobin> there's the BONDI meeting at the same time, hence the regrets
<darobin> mmmmm, it can do it :)
<darobin> for some reason nwidell is not on the victims list!
<darobin> Niklas
I sccribed at F2F
I can do it
<darobin> Brad is also not on the scribes list
<dom> [regrets from me for next two weeks]
scribe nwidell
<Claes1> Present Claes_Nilsson
<dom> ScribeNick: nwidell
<scribe> ScribeNick: nwidell
Agenda ok
Announcements:
<fjh> The Contacts API has now made it officially as First Public
<dom> Contacts API FPWD
<fjh> Working Draft: http://www.w3.org/TR/2010/WD-contacts-api-20100121/
RESOLUTION: Minutes from January 20th approved
<fjh> 20 Jan
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/att-0167/minutes-2010-01-20.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0168.html
<Suresh> no concentration:-)
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0185.html
fjh: we need to make a decision on how to continue with the LRest vs API issue, please review discussions on the list
<dom> ISSUE-66?
<trackbot> ISSUE-66 -- Investigation around Virtual Web Devices / REST-ful oriented APIs -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/issues/66
<Zakim> dom, you wanted to propose that the next step on this would be a concrete API proposal from REST-proponents
dom: It is not clear how REST-ful APIs would help. We need a concrete REST proposal
... and then make a decision.
fjh: no decision/resolution on this call
<dom> ISSUE-66: could use a concrete API proposal to see how the various obstacles that have been evoked would be handled
<trackbot> ISSUE-66 Investigation around Virtual Web Devices / REST-ful oriented APIs notes added
thanks dom
<darobin> ACTION: Robin to contact Mark about a concrete LREST proposal [recorded in http://www.w3.org/2010/01/27-dap-minutes.html#action01]
<trackbot> Created ACTION-88 - Contact Mark about a concrete LREST proposal [on Robin Berjon - due 2010-02-03].
<fjh> action-85?
<trackbot> ACTION-85 -- Paddy Byers to provide his thoughts on LREST based on experience from BONDI's earlier discussions on the same -- due 2010-01-27 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/85
fjh: Please look on the list so we can have a decision soon
<dom> close ACTION-85
<trackbot> ACTION-85 Provide his thoughts on LREST based on experience from BONDI's earlier discussions on the same closed
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0187.html
fjh: Concerned in progress in security
<fjh> goal to publish FPWD of security requirements, what needs to be added
<fjh> action-16?
<trackbot> ACTION-16 -- Bryan Sullivan to help review/compare device capabilities and features -- due 2009-11-02 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/16
<fjh> action-46?
<trackbot> ACTION-46 -- Daniel Coloma to provide input of capability definition and semantics -- due 2009-11-10 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/46
fjh: We need progress on these actions (16+46)
<fjh> action-45?
<trackbot> ACTION-45 -- David Rogers to provide use case with threat model scenarios -- due 2009-11-10 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/45
<fjh> action-48?
<trackbot> ACTION-48 -- Suresh Chitturi to propose a definition for API access control, and a possible model for policy enforcement -- due 2009-11-10 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/48
<fjh> action-79?
<trackbot> ACTION-79 -- Paddy Byers to integrate his use cases in policy requirements -- due 2010-01-13 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/79
<fjh> action-77?
<trackbot> ACTION-77 -- John Morris to provide a discussion of requirements for privacy -- due 2010-01-19 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/77
fjh: We need to have progress on security use cases:
<dom> Policy requirements editors draft
suresh: We have not decided how to use features in assoc. with policies
<dom> ACTION-48 due 2010-02-10
<trackbot> ACTION-48 Propose a definition for API access control, and a possible model for policy enforcement due date now 2010-02-10
<Suresh> Will complete action-48 by Feb 10
fjh: We need to have something before f2f
<fjh> Sysinfo, ISSUE-63, encrypted attribute,
<dom> ISSUE-63?
<trackbot> ISSUE-63 -- network API: "encrypted" property is meaningless -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/63
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0171.html
<fjh> issue-63?
<trackbot> ISSUE-63 -- network API: "encrypted" property is meaningless -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/63
<dom> MaxF take on encrypted attribute
fjh: recaps discussion on issue-63
<dom> [isn't that backward though? shouldn't we remove it until it gets properly defined?]
<maxf> I'm happy to, yes
max: will update according to consensus
<Dzung_Tran> I think just remove it for now
<darobin> [conversely we could leave it in to get feedback]
tlr: Wants to remove encrypted due to risk of misuse (more harm than benefit)
<dom> [I would remove it, and maybe add an editors note on getting feedback around "secure connection"]
<darobin> [works for me]
<Dzung_Tran> works for me too
tlr: until there is an useful definition of secure channel. More specification is needed
... to indicate how the encrypted channel relates to what the app is using.
<tlr> maxf, I've had my computer on several network links a number of times
<maxf> tlr, I mean through the API
<dom> PROPOSED RESOLUTION: remove encrypted attribute from Network interface in sysinfo
<fjh> proposed resolution: remove encrypted property from API
<maxf> "PROPOSED": does that mean I should edit?
<maxf> or wait for minute approval?
fjh: Prefer to remove right away
<maxf> ok, I'll edit
<maxf> done
<dom> ISSUE-63: we remove the encrypted attribute from network interface before FPWD
<trackbot> ISSUE-63 network API: "encrypted" property is meaningless notes added
<dom> close ISSUE-63
<trackbot> ISSUE-63 network API: "encrypted" property is meaningless closed
RESOLUTION: remove encrypted attribute from Network interface in sysinfo
<dom> CfC for SysInfo FPWD
darobin: CofC SysInfo objections?
<fjh> I recommend we add additional text regarding status of document in FPWD,
<dom> Claes question on completeness of scope of SysInfo for FPWD
Claes: maybe we should add a few more things
<fhirsch> Implementers should be aware that this document is not stable. Implementers who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this document before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.
darobin: We can certainly add things later
<fhirsch> this is possible additional boilerplate text for all our documents
darobin: we have flexibility
<AnssiK> +1 to fjh provided boilerplate
Claes: would like to add a few more sensor apis, wants to be sure that we can add them later
darobin: encourages a proposal on the additional apis, or at least log an issue
fjh: proposes some extra boilerplate text to indicate that document might change
<dom> tlr, can you take the action of getting SysInfo published as FPWD? I can probably take care of the transition request, but probably not of the publication itself
RESOLUTION: publish SysInfo as FPWD
<dom> ACTION: dom to request transition of Sysino to FPWD [recorded in http://www.w3.org/2010/01/27-dap-minutes.html#action02]
<trackbot> Created ACTION-89 - Request transition of Sysino to FPWD [on Dominique Hazaël-Massieux - due 2010-02-03].
darobin: calendar/messaging
<tlr> dom, ok
darobin: please provide feeback
oops sorry
<fjh> sysinfo link - http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0170.html
<fjh> (Robin)
tlr: looking at calendar. Different from vcalendar format in not useful way
<fjh> Calendar draft http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0182.html
<dom> ACTION: thomas to deal with publication of SysInfo as FPWD [recorded in http://www.w3.org/2010/01/27-dap-minutes.html#action03]
<trackbot> Created ACTION-90 - Deal with publication of SysInfo as FPWD [on Thomas Roessler - due 2010-02-03].
tlr: what should be the relationship between vcard/contacts and vcalendar/Calendar.
<fjh> http://dev.w3.org/2009/dap/calendar/
<dom> Dom's comments on Calendar API (including points on recurrence)
tlr: if we don't get alignment we might end in big trouble.
suresh: studied what currents implementations do instead of the focus on specs
... tried to follow similar model as contacts, find common intersection
... wrt compatibilities we need to look at the differences between proposal and vcalendar
... but comments (from mail) are valid observations.
tlr: (soapbox) I don't want to built in incompatibilities
... (didn't get the last part)
darobin: intersection what is specified/what is available
<darobin> robin: intersection of what is available and compatible subset of specifications
suresh: we will look into vcalendar, but also look at icalendar
... will provide some feedback on the differences
<Zakim> Thomas, you wanted to also suggest taking this to the W3C/IETF liaison
<dom> [should we raise on issue on data model differences with ical (possible vcard too)?]
<darobin> ACTION: Suresh to investigate how to produce an intersection of existing APIs that is also a compatible subset of vCalendar/vCard [recorded in http://www.w3.org/2010/01/27-dap-minutes.html#action04]
<trackbot> Created ACTION-91 - Investigate how to produce an intersection of existing APIs that is also a compatible subset of vCalendar/vCard [on Suresh Chitturi - due 2010-02-03].
<tlr> dom, yes
<darobin> ISSUE: difference in data model between Contacts/Calendar APIs and vCard/vCalendar
<trackbot> Created ISSUE-71 - Difference in data model between Contacts/Calendar APIs and vCard/vCalendar ; please complete additional details at http://www.w3.org/2009/dap/track/issues/71/edit .
<darobin> ACTION: tlr to give a heads up to the IETF/W3C liaison for review and input from IETF around PIM [recorded in http://www.w3.org/2010/01/27-dap-minutes.html#action05]
<trackbot> Created ACTION-92 - Give a heads up to the IETF/W3C liaison for review and input from IETF around PIM [on Thomas Roessler - due 2010-02-03].
<dom> ACTION-92 due 2010-03-03
<trackbot> ACTION-92 Give a heads up to the IETF/W3C liaison for review and input from IETF around PIM due date now 2010-03-03
darobin: That summarizes API topics
<fjh> Messaging draft available http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0183.html
messaging:
<dom> [I read Messaging API, didn't have any real comments]
<fjh> suresh notes messaging and contacts need to be consistent, integrated
<Suresh> and the same with Calendar and Messaging
darobin: fix consistency a little bit later in the process
tlr: one of the patterns to use is to use URIs as soon as possible
... e.g SMS URI and SMS api use together.
<darobin> ISSUE: usage of URIs for sms, tel:, etc in PIM APIs
<trackbot> Created ISSUE-72 - Usage of URIs for sms, tel:, etc in PIM APIs ; please complete additional details at http://www.w3.org/2009/dap/track/issues/72/edit .
<dom> (I think we already had an issue for the uri schemes discussion: ISSUE-54)
<dom> ISSUE-54?
<trackbot> ISSUE-54 -- What messaging use cases cannot be fulfilled by existing URI schemes (mailto, sms, mms)? -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/54
<dom> [shall I close the dup ISSUE-72?]
<Zakim> fjh, you wanted to ask for clarification on the uri issue
<tlr> issue-72
<tlr> issue-72?
<trackbot> ISSUE-72 -- Usage of URIs for sms, tel:, etc in PIM APIs -- RAISED
<trackbot> http://www.w3.org/2009/dap/track/issues/72
<dom> [ok, that's a different perspective indeed]
<darobin> [ISSUE-54 is SMS.send("foo") versus <a href='sms:+336...?body=foo'>text robin</a>]
<fjh> tlr clarifies that ISSUE-54 relates to handing control to another app, versus ISSUE-72 and ability of APIS to work with URIs
thanks fjh
darobin: gentle reminder to do reviews