# Device APIs and Policy Working Group Teleconference

## 27 Jan 2010

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Robin_Berjon, Frederick_Hirsch, Ilkka_Oksanen, Niklas_Widell, Dzung_Tran,
ThomasRoessler, Dominique_Hazael-Massieux, Claes_Nilsson, Brad_Lassery,
Suresh, Suresh_Chitturi

Regrets

    Arve_Bersvendsen, David_Rogers, John_Morris, Laura_Arribas,
Marcin_Hanclik, Marengo_Marco, Paddy_Byers

Chair

    Robin_Berjon, Frederick_Hirsch

Scribe

    nwidell

## Contents

  * [Topics][5]

    1. [Administrative][6]

    2. [Minutes Approval][7]

    3. [Policy][8]

    4. [API][9]

    5. [AoB][10]

  * [Summary of Action Items][11]

* * *

<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

### Administrative

<scribe> ScribeNick: nwidell

Agenda ok

Announcements:

<fjh> The Contacts API has now made it officially as First Public

<dom> [Contacts API FPWD][12]

<fjh> Working Draft: [http://www.w3.org/TR/2010/WD-contacts-api-20100121/][12]

### Minutes Approval

**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][13]

### Policy

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0168.html][14]

<Suresh> no concentration:-)

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0185.html][15]

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][16]

<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][17]]

<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][18]

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][19]

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][20]

<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][21]

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][22]

<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][23]

<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][24]

<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][25]

fjh: We need to have progress on security use cases:

<dom> [Policy requirements editors draft][26]

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][27]

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0171.html][28]

<fjh> issue-63?

<trackbot> ISSUE-63 -- network API: "encrypted" property is meaningless --
RAISED

<trackbot> [http://www.w3.org/2009/dap/track/issues/63][27]

<dom> [MaxF take on encrypted attribute][29]

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

### API

<dom> [CfC for SysInfo FPWD][30]

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][31]

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][32]]

<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][30]

<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][33]

<dom> **ACTION:** thomas to deal with publication of SysInfo as FPWD [recorded
in [http://www.w3.org/2010/01/27-dap-minutes.html#action03][34]]

<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/][35]

<dom> [Dom's comments on Calendar API (including points on recurrence)][36]

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][37]]

<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][38] .

<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][39]]

<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][40]

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][41] .

<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][42]

<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][43]

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

### AoB

<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

## Summary of Action Items

**[NEW]** **ACTION:** dom to request transition of Sysino to FPWD [recorded in
[http://www.w3.org/2010/01/27-dap-minutes.html#action02][32]]

**[NEW]** **ACTION:** Robin to contact Mark about a concrete LREST proposal
[recorded in [http://www.w3.org/2010/01/27-dap-minutes.html#action01][17]]

**[NEW]** **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][37]]

**[NEW]** **ACTION:** thomas to deal with publication of SysInfo as FPWD
[recorded in [http://www.w3.org/2010/01/27-dap-minutes.html#action03][34]]

**[NEW]** **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][39]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][44] version 1.135 ([CVS
log][45])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0189.html

   [4]: http://www.w3.org/2010/01/27-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #ActionSummary

   [12]: http://www.w3.org/TR/2010/WD-contacts-api-20100121/

   [13]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/att-0167/minutes-2010-01-20.html

   [14]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0168.html

   [15]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0185.html

   [16]: http://www.w3.org/2009/dap/track/issues/66

   [17]: http://www.w3.org/2010/01/27-dap-minutes.html#action01

   [18]: http://www.w3.org/2009/dap/track/actions/85

   [19]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0187.html

   [20]: http://www.w3.org/2009/dap/track/actions/16

   [21]: http://www.w3.org/2009/dap/track/actions/46

   [22]: http://www.w3.org/2009/dap/track/actions/45

   [23]: http://www.w3.org/2009/dap/track/actions/48

   [24]: http://www.w3.org/2009/dap/track/actions/79

   [25]: http://www.w3.org/2009/dap/track/actions/77

   [26]: http://dev.w3.org/2009/dap/policy-reqs/

   [27]: http://www.w3.org/2009/dap/track/issues/63

   [28]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0171.html

   [29]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0177.html

   [30]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0170.html

   [31]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0192.html

   [32]: http://www.w3.org/2010/01/27-dap-minutes.html#action02

   [33]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0182.html

   [34]: http://www.w3.org/2010/01/27-dap-minutes.html#action03

   [35]: http://dev.w3.org/2009/dap/calendar/

   [36]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0198.html

   [37]: http://www.w3.org/2010/01/27-dap-minutes.html#action04

   [38]: http://www.w3.org/2009/dap/track/issues/71/edit

   [39]: http://www.w3.org/2010/01/27-dap-minutes.html#action05

   [40]: http://lists.w3.org/Archives/Public/public-device-
apis/2010Jan/0183.html

   [41]: http://www.w3.org/2009/dap/track/issues/72/edit

   [42]: http://www.w3.org/2009/dap/track/issues/54

   [43]: http://www.w3.org/2009/dap/track/issues/72

   [44]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [45]: http://dev.w3.org/cvsweb/2002/scribe/