W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2010

Draft minutes 2010-04-28

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 28 Apr 2010 12:15:11 -0400
Message-Id: <4273B59E-1131-4D4E-8EC4-115E92D3C93C@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Attached are draft minutes from our teleconference today, 2010-04-28,  
for approval at next meeting. Thanks to Alissa for scribing, and Dom  
and Max for helping out.

HTML follows text.

regards, Frederick

Frederick Hirsch

# Device APIs and Policy Working Group Teleconference

## 28 Apr 2010


See also: [IRC log][4]

## Attendees


    Robin_Berjon, Frederick_Hirsch, Erica_Newland, LauraA, Anssi_Kostiainen,
Alissa_Cooper, David_Rogers, Dominique_Hazael-Massieux, Ilkka_Oksanen,
Suresh_Chitturi, Claes_Nilsson, Niklas_Widell, Maria_Oteo, Marco_Marengo,
Ingmar_Kliche, Soonho_Lee


    John_Morris, WonSuk_Lee


    Robin_Berjon, Frederick_Hirsch


    alissa, dom, maxf

## Contents

  * [Topics][5]

    1. [Admin][6]

    2. [Minutes approval][7]

    3. [Privacy][8]

    4. [API discussion][9]

    5. [parameter style][10]

    6. [editor for tasks][11]

    7. [misc APIs][12]

  * [Summary of Action Items][13]

* * *

<trackbot> Date: 28 April 2010

<alissa> ok

<alissa> scribenick: alissa

### Admin

<fjh> Privacy workshop, Mon/Tue 12-13 July 2010, London

Privacy workshop, Mon/Tue 12-13 July 2010, London


fjh: our F2F is now starting Weds, July 14

drogersuk: OMTP is flexible with hosting

<drogersuk> [http://www.ceop.gov.uk/][15]

drogersuk: also arranging a visit to CEOP one evening of F2F

<nwidell> (will be IRC only first 30 minutes of this call

<drogersuk> potentially we could setup two separate visits, but these will not
infringe directly on the meetings - they would be after

<inserted> ScribeNick: dom

frederick: not sure if we should have a 2 or 3 days meeting

... probably won't need to discuss privacy given that we'll have discussed it
for two days during the workshop before

Bryan: I suggest going for 3 days

... our F2F meetings are fairly productive

<AnssiK> personally I'm not avail for Fri

Robin: suggests 2.5 days to allow for people to leave early on Friday

... re privacy, I'm hoping we'll get new input from the workshop that will be
worth processing

Frederick: does anybody have a problem with 2.5 days?

David: we can accommodate for that one way or another re hosting

**RESOLUTION: Next F2F on July 14 to 16 in London**

<Suresh> does it end at 12:00noon on the 3rd day?

**RESOLUTION: Next F2F on July 14 to 16 in London, ending at 2 or 3pm on

frederick: our hosts will need to look into lunch & logistics

(note that attendance at the workshop requires sending a position paper)

### Minutes approval

<fjh> [http://lists.w3.org/Archives/Public/public-device-

<fjh> 21 April 2010

**RESOLUTION: Minutes of April 21st approved**

<scribe> ScribeNick: alissa

<fjh> Policy requirements and framework

<fjh> [http://dev.w3.org/2009/dap/policy-reqs/][17]

<fjh> **ACTION:** fjh to review policy requirements and propose changes
[recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action01][18]]

<trackbot> Created ACTION-166 - Review policy requirements and propose changes
[on Frederick Hirsch - due 2010-05-05].

<fjh> [http://dev.w3.org/2009/dap/policy/][19]

will resume scribing now

<fjh> layering model considerations can move to requirements doc?

fjh: Laura still needs to add trust domain stuff from Nokia

Laura: still working on it

... maybe done early next week

fjh: two different things in document

... 1 model of how security works

... 2 detailed XACML profile

... 1 very tied to 2

... XACML profile could be its own doc

... but issues still lie in model piece

... maybe need some layering to separate out XACML

dom: no problem with the length, but perhaps the scope

<fjh> we might want to split framework into model and separate xacml profile

dom: rules lang, ID model, model for environment, capacities model,policy
decision model -- lots of stuff

... makes it harder to get reviews, to get browsers to look at it, etc.

<dom> [Dom's comment on policy framework][20]

fjh: could make XACML part separate pretty easily

... not a whole lot in the rest of the doc

... need suggestions on way forward

<dom> **ACTION:** Dom to make a concrete proposal for policy framework based
on his comments [http://lists.w3.org/Archives/Public/public-device-
apis/2010Apr/0030.html][20] [recorded in [http://www.w3.org/2010/04/28-dap-

<trackbot> Created ACTION-167 - Make a concrete proposal for policy framework
based on his comments [http://lists.w3.org/Archives/Public/public-device-
apis/2010Apr/0030.html][20] [on Dominique Hazaël-Massieux - due 2010-05-05].

fjh: next step: Laura to finish, others to think about way forward

<fjh> comment from Claes

<fjh> <[http://lists.w3.org/Archives/Public/public-device-

Claes: tables defining the subject attributes -- didn't understand

<fjh> [http://dev.w3.org/2009/dap/policy/#subject-attributes][23]

Laura: have not had time to respond yet

Claes: important to be able to identify a unique web application, not just

<dom> (this is an example of why identity in itself is probably worth a spec
on its own :)

fjh: will take this to the list

<fjh> identity is one area to call out

Suresh: sent an email awhile ago asking how the warp (?) spec in widgets group
is relevant to policy

... if you run this against widget environment, widget config will come into

<fjh> [http://www.w3.org/TR/2010/CR-widgets-access-20100420/][24]

fjh: answer was that warp was an intermediate specification- we should look at

darobin: warp is in CR

... it's one use case, so if policy doesn't cover what warp does, that's a

Suresh: couldn't we just reference it?

darobin: it's fine to redefine it

... otherwise might have to caveat warp out

Suresh: if we can reference it, we should

darobin: not sure how reusable warp is, not certain

<fjh> issue: note relationship of WARP to DAP policy work

<trackbot> Created ISSUE-83 - Note relationship of WARP to DAP policy work ;
please complete additional details at
[http://www.w3.org/2009/dap/track/issues/83/edit][25] .

### Privacy

<fjh> privacy requirements

<fjh> [http://dev.w3.org/2009/dap/privacy-reqs/][26]

<fjh> [http://lists.w3.org/Archives/Public/public-device-

<fjh> this draft fills in details, removes ambiguous language and adds new

<fjh> this could impact API work

<scribe> **ACTION:** Alissa to incorporate edits into Privacy Requirements.
[recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action03][28]]

<trackbot> Created ACTION-168 - Incorporate edits into Privacy Requirements.
[on Alissa Cooper - due 2010-05-05].

<dom> (I had trouble with the interpretation of "mutually exclusive" in
Alissa's response; I think we should talk about subsetting relationships

fjh: had some placeholder text for APIs

<fjh> [http://lists.w3.org/Archives/Public/public-device-

<dom> ACTION-114?

<trackbot> ACTION-114 -- Alissa Cooper to phrase the temporary privacy section
-- due 2010-03-23 -- PENDINGREVIEW

<trackbot> [http://www.w3.org/2009/dap/track/actions/114][30]

<darobin> [yeah, that's part of what I was thinking about — but I need to
ground those ideas in examples to see if it would make sense]

fjh: can editors put in the text?

<soonho> (I am attending this conference call only via IRC.)

<scribe> **ACTION:** Frederick to insert temporary privacy language into the
APIs. [recorded in [http://www.w3.org/2010/04/28-dap-

<trackbot> Created ACTION-169 - Insert temporary privacy language into the
APIs. [on Frederick Hirsch - due 2010-05-05].

### API discussion

<darobin> ACTION-142?

<trackbot> ACTION-142 -- Max Froumentin to propose two interfaces Outgoing and
Incoming messages for messaging API -- due 2010-03-25 -- PENDINGREVIEW

<trackbot> [http://www.w3.org/2009/dap/track/actions/142][32]

darobin: hasn't been much feedback on this -- should we go ahead with it?

<darobin> [][33]

Suresh: don't see why we want to split into incoming and outgoing

... only distinguished by send

... if we split will need interface for draft message, e.g.

<dom> [Messaging API discussions at the F2F][34]

maxf: I don't have insight into which way we're going, just need to make a

... don't have a strong opinion

dom: we had the distinction because incoming should be read-only

... send on incoming doesn't make any sense

... maybe incoming/outgoing is misleading; it should be about whether it will
be sent

... distinction has value

darobin: same intf with different rules?

Suresh: have exception on send for incoming

<maxf> the proposal I had:

Suresh: can address use case with what we have

<maxf> ah, no.

darobin: might want to filter received messages to make them readable

bryan: messages should be editable in the inbox

<maxf> [http://www.w3.org/mid/4BCF032E.9050900@opera.com][36]

bryan: once you've stored a message, you need an ID to edit

... the attributes end up becoming similar between the two

... although there are exceptions

darobin: hearing more arguments in favor of single interface

Suresh: once we have folder management, we can come back to this

darobin: not strongly tied to folders

... sent mail folder is more of an implementation detail

Suresh: can tag msgs as sent or received

darobin: if object fields are similar, it's a small decision between object
type and type flag

... hearing stronger consensus for single interface

dom: already have a type flag

... need to disambiguate names

<Suresh> 'status'

**RESOLUTION: Messages have a single interface irrespective of their type.
Need a better name for type (status?).**

<darobin> close ACTION-142

<trackbot> ACTION-142 Propose two interfaces Outgoing and Incoming messages
for messaging API closed

maxf: so we're not keeping a per-type (MMS, SMS) interface then?

Suresh: should separate interfaces based on messaging type

... BONDI separates the interfaces

<darobin> [actually these two are half-orthogonal — if we have separate for
incoming/ougoing *and* for types we get IncomingSMS, OutgoingSMS,
IncomingEmail, ...]

Suresh: right now we create a superset interface and we're silent for what
doesn't apply

<darobin> [given a unified in/out interface, if we split we just get Email,

Suresh: implementations might have separate modules for different messaging

darobin: some implementations might only support email

Suresh: separation lets implementations pick

bryan: extension to specific message types is a useful approach (attachments
aren't relevant for SMS, e.g.)

... defining message types is a better approach

<maxf> +1 with Bryan: different interfaces handles the attribute errors

Suresh: makes spec longer

<dom> (which we'll have to do for incoming/outgoing :) )

Suresh: will miss exception cases

**RESOLUTION: Have multiple interfaces for different messaging technologies
(i.e., message types).**

<Zakim> darobin, you wanted to bring up numerical constants

<dom> (this relations to ACTION-139)

<dom> ACTION-139?

<trackbot> ACTION-139 -- Max Froumentin to fix section 5 "supported messaging
types" in Messaging API to clarify handling of non-supported attributes -- due
2010-03-25 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/139][37]

maxf: will wait to update until receiving something from Suresh

<maxf> I was asking about a resolution on the priority attribute

Suresh: priority attribute is not applicable for SMS and MMS, but it is for

... since we're separating, we should add it to email

bryan: why isn't priority applicable to MMS?

Suresh: it's not defined in the MMS spec

... user-defined priority

<dom> (another item that my MUA lets me set at writing time: reply-to)

dom: could have generic getheader and setheader?

darobin: concerned about security issues (in XHR had to jump hoops re headers)

<dom> (at least getHeader() should exist?)

<darobin> [yeah, getHeader() makes sense — note that it can return an array]

Suresh: list of headers is not long right now

darobin: there are many email headers

dom: PHP lets you write any header

bryan: could deal with security issues separately from API functionality

<nwidell> (maybe we should decide on abstraction level of Messaging API)

bryan: could define specific attributes for most common message fields, but
use others by name through generic mechanism

<dom> [we could WebIDL setter/getter? not sure if it's worth it, though]

<darobin> [email from Suresh: X-Original-To, Delivered-To, Received,
X-AuditID, X-MimeOLE, Content-class, MIME-Version....]

<darobin> **ACTION:** Robin to review the options for headers on emails
[recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action05][38]]

<trackbot> Created ACTION-170 - Review the options for headers on emails [on
Robin Berjon - due 2010-05-05].

<dom> ISSUE: which headers to support setting/getting in Messaging API?

<trackbot> Created ISSUE-84 - Which headers to support setting/getting in
Messaging API? ; please complete additional details at
[http://www.w3.org/2009/dap/track/issues/84/edit][39] .

darobin: lots of different headers that might need support

... will draft an email with use cases, review XHR

nwidell: question of size and scope of API

... do we really have a use case for replacing outlook?

<AnssiK> go for 80/20

bryan: providing a message where you can get/set fields by name, keeps API

... if we have something generic, market will find useful ways to leverage it

<maxf> ScribeNick: maxf

Suresh: we didn't talk about ability to identify messages by Service, like in

... people have different email accounts.

<darobin> +1

Suresh: retrieving by service is useful.

... e.g. different mailboxes

<darobin> [you get some emails from Opera, others from GMail, etc. different

Suresh: different accounts

<nwidell> +1 (was thinking about same thing before going AWOL ;-)

darobin: account-ID sounds better than service-ID

<darobin> [][40]

### parameter style

darobin: seems to be heading towards using object literals

... objections?

dom: I'm not sure I would call it a consensus

... about half and half

darobin: happy to keep discussion alive

dom: perhaps we need to wait a bit, see if anybody reacts further

darobin: ok

### editor for tasks

<dom> (this was about ISSUE-55)

darobin: david suggested he might be able to find someone

<dom> ACTION-147?

<trackbot> ACTION-147 -- David Rogers to look for an editor for the Tasks API
-- due 2010-03-25 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/147][41]

<drogersuk> Hello?

Suresh: is Tasks among the priority APIs?

<drogersuk> Can you hear me?

darobin: not necessarily, but editors would be welcome

drogersuk: didn't see any responses when I asked

<dom> close ACTION-147

<trackbot> ACTION-147 Look for an editor for the Tasks API closed

<dom> ACTION-147: no one took up the offer

<trackbot> ACTION-147 Look for an editor for the Tasks API notes added

darobin: then we might just have to wait

### misc APIs

darobin: we're going to need a test framework soon

<dom> [A Proposal for the Testing Framework, Soonho Lee][42]

<drogersuk> +1

darobin: dom also looked at it

<dom> wttjs

dom: I found WTTGS which generates test cases based on webidl

... it's not as good as it could be, not too good for async interfaces

<darobin> [][40]

<darobin> bah

<darobin> [][43]

darobin: widlproctools might be a better start. Hoping I'll be able to work on
it soon.

<darobin> s/-> [http://www.w3.org/mid/n2n708552fb1004071110x6d98c6e6t85e83eef0

<dom> ACTION-150?

<trackbot> ACTION-150 -- David Rogers to send BONDI experience with testing
for device APIs -- due 2010-03-25 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/150][45]

<darobin> s/drogersuk: trying to lobby for your case with new Bondi CEO (Geoff


<drogersuk> example of W3C minuting!

drogersuk: dom, let's speak offline about it, cause I think we have a plan.

<scribe> **ACTION:** drogersuk and Dom to speak offline on testing framework
[recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action06][46]]

<trackbot> Created ACTION-171 - And Dom to speak offline on testing framework
[on David Rogers - due 2010-05-05].

drogersuk: there's a large amount of interest, since manufacturers need to be
able to claim compliance

... we'd like to endorse Marcos' job with widgets specs

darobin: we should try and get him on this group to help. And we should try
and gather as much manufacturer power as possible

<darobin> ack !

<drogersuk> I need to jump onto another conference call, see you guys later

<dom> (regrets for next two weeks from me)

## Summary of Action Items

**[NEW]** **ACTION:** Alissa to incorporate edits into Privacy Requirements.
[recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action03][28]]

**[NEW]** **ACTION:** Dom to make a concrete proposal for policy framework
based on his comments [http://lists.w3.org/Archives/Public/public-device-
apis/2010Apr/0030.html][20] [recorded in [http://www.w3.org/2010/04/28-dap-

**[NEW]** **ACTION:** drogersuk and Dom to speak offline on testing framework
[recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action06][46]]

**[NEW]** **ACTION:** fjh to review policy requirements and propose changes
[recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action01][18]]

**[NEW]** **ACTION:** Frederick to insert temporary privacy language into the
APIs. [recorded in [http://www.w3.org/2010/04/28-dap-

**[NEW]** **ACTION:** Robin to review the options for headers on emails
[recorded in [http://www.w3.org/2010/04/28-dap-minutes.html#action05][38]]

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][47] version 1.135 ([CVS

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

   [4]: http://www.w3.org/2010/04/28-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #ActionSummary

   [14]: http://www.w3.org/2010/api-privacy-ws/

   [15]: http://www.ceop.gov.uk/

   [16]: http://lists.w3.org/Archives/Public/public-device-

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

   [18]: http://www.w3.org/2010/04/28-dap-minutes.html#action01

   [19]: http://dev.w3.org/2009/dap/policy/

   [20]: http://lists.w3.org/Archives/Public/public-device-

   [21]: http://www.w3.org/2010/04/28-dap-minutes.html#action02

   [22]: http://lists.w3.org/Archives/Public/public-device-

   [23]: http://dev.w3.org/2009/dap/policy/#subject-attributes

   [24]: http://www.w3.org/TR/2010/CR-widgets-access-20100420/

   [25]: http://www.w3.org/2009/dap/track/issues/83/edit

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

   [27]: http://lists.w3.org/Archives/Public/public-device-

   [28]: http://www.w3.org/2010/04/28-dap-minutes.html#action03

   [29]: http://lists.w3.org/Archives/Public/public-device-

   [30]: http://www.w3.org/2009/dap/track/actions/114

   [31]: http://www.w3.org/2010/04/28-dap-minutes.html#action04

   [32]: http://www.w3.org/2009/dap/track/actions/142

   [33]: http://lists.w3.org/Archives/Public/public-device-

   [34]: http://www.w3.org/2010/03/18-dap-minutes#item01

   [35]: http://www.w3.org/mid/4BD04FAA.2010107@opera.com

   [36]: http://www.w3.org/mid/4BCF032E.9050900@opera.com

   [37]: http://www.w3.org/2009/dap/track/actions/139

   [38]: http://www.w3.org/2010/04/28-dap-minutes.html#action05

   [39]: http://www.w3.org/2009/dap/track/issues/84/edit

   [40]: http://www.w3.org/mid/n2n708552fb1004071110x6d98c6e6t85e83eef0eef52de

   [41]: http://www.w3.org/2009/dap/track/actions/147

   [42]: http://www.w3.org/mid/490BF875279F7549BEBA47ADC8F369DB6C92435F8D@SKT-

   [43]: http://suika.fam.cx/www/webidl2tests/readme.en.html

   [44]: http://www.w3.org/mid/n2n708552fb1004071110x6d98c6e6t85e83eef0eef52de

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

   [46]: http://www.w3.org/2010/04/28-dap-minutes.html#action06

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

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

Received on Wednesday, 28 April 2010 16:16:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:19 UTC