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

Draft F2F Minutes Day 3, 2010-03-18

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Thu, 18 Mar 2010 09:44:57 -0400
Message-Id: <44E8BA71-6E71-451E-AB34-F736A22E3541@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Draft F2F Minutes Day 3, 2010-03-18, HTML follows text.

regards, Frederick

Frederick Hirsch
Nokia




# Device APIs and Policy Working Group F2F Meeting Day 3

## 18 Mar 2010

See also: [IRC log][3]

## Attendees

Present

    Ruth_Vazquez, DAP-In-Prague, Dominique_Hazael-Massieux, Marco_Marengo,
Wonsuk_LEE, Johnson_Wang, LauraA, Anssi_Kostiainen, Ilkka_Oksanen,
bryan_sullivan, Richard_Tibbett, Aurelien_Guillou, Ingmar_Kliche,
Jesus_Martin, Frederick_Hirsch, Robin_Berjon, Daniel_Coloma, Kangchan_Lee

Regrets

    Thomas_Roessler, Google_members

Chair

    Robin_Berjon, Frederick_Hirsch

Scribe

    marengo, bsulliva

## Contents

  * [Topics][4]

    1. [Messaging API][5]

    2. [Policy/Privacy/Security][6]

    3. [Gallery][7]

    4. [Policy/Privacy/Security][8]

    5. [other APIs][9]

    6. [Charter][10]

  * [Summary of Action Items][11]

* * *

<trackbot> Date: 18 March 2010

<marengo> ScribeNick: marengo

<dom> [Messaging API Editors draft][12]

### Messaging API

<darobin> RuthVazquez, should be good now

<RuthVazquez> yes it is! thank you

maxf: we'll have a walthrough of the document

... we're supporting sms, mms, email

... with basic functionalities: create, send, subscribe

... first sections are boiler-plate

<dom> [the messaging API relies on supportsType(), while the more JS-typical
way of doing this is to rely on the existence of an interface]

maxf: MessagingManager: create, supports, subscribe, unsubscribe methods

darobin: what about putting messagingType in MessageProperties?

dom: typical usage is something like messaging.email.create()

darobin: or something like createEmail(), createSMS(), ...

maxf: it's probably less scalable

AnssiK: it's similar to the Capture API, we have 3 separate methods

maxf: so it's message.mms.create(..) VS message.createMMS(..)

<scribe> **ACTION:** maxf to make subscribe() method use events [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action01][13]]

<trackbot> Created ACTION-132 - Make subscribe() method use events [on Max
Froumentin - due 2010-03-25].

bryan: what about filtering?

<marengo_scribe> -> a suggestion for extending messaging filtering:
[http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0131.html][14]

bryan: i'd like to subscribe to binary messages

... there's a reason for apps: they're efficient, compressed

... and delivered to a port

dom: it's also a matter of minimization

drogersuk: suggest to have a look at BONDI 1.1 Messaging API

<marengo_scribe> [BONDI 1.1 Messaging API][15]

bryan: we need a simple set of filters for typical use cases

maxf: difficult to define powerful filters, it's an application problem

darobin: can we reuse event targets

... and subclass the EventListener class

<dom> ACTION-132?

<trackbot> ACTION-132 -- Max Froumentin to look at messaging subscribe with
filtering and events -- due 2010-03-25 -- OPEN

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

<dom> [message.create() should really be renamed message.send()]

maxf: back to messaging.mms.create(...) vs messaging.createMMS(...)

dom: the 2nd would be more consistent with other apis

<dom> dom: (unless we need additional specialized methods per messages types)

ilkka: it's different from the capture API, what if someone wants to create a
twitter msg?

<dom> s/illka/ingmar/

maxf: we'll use messaging.createMMS(...)

<dom> **ACTION:** Maxf to change message.create(TYPE) to message.createTYPE()
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action02][17]]

<trackbot> Created ACTION-133 - Change message.create(TYPE) to
message.createTYPE() [on Max Froumentin - due 2010-03-25].

maxf: supports() becomes unnecessary

<dom> AnssiK: message.send() doesn't need to have itself as a parameter

<fjh> Chair: Frederick_Hirsch, Robin_Berjon

richt: Message should inherit from MessageProperties

bryan: is the ID assigned when the message is created?

maxf: when you create() the message, the object has its ID

darobin: messagingType -> type

<dom> maxf: errorCallback in send should be optional

darobin: we keep timestamp as it is, it doesn't keep timezone information

<dom> robin: probably less of a problem that Message.timestamp loses timezone
info; we can move to TimezonedDate() if we get define that

dom: is timestamp referred to creation or send/receive time?

bryan: could it be updated to the last event of the lifecycle?

dom: normally if you receive an email you only can see when it was sent, not
when you received it

<dom> **ACTION:** maxf to replace Message.timestamp with Message.sent and
Message.received [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action03][18]]

<trackbot> Created ACTION-134 - Replace Message.timestamp with Message.sent
and Message.received [on Max Froumentin - due 2010-03-25].

richt: SuccessCallback isn't defined

maxf: what do we need for successCB?

darobin: it could be just a function() object [see File API]

richt: in other APIs we return the updated (server-verified) object

maxf: this is a design pattern, it should be applied to other apis as well

dom: let's keep it simple for v1

<dom> ACTION-113: also check that "empty" callbacks should be described as
Function

<trackbot> ACTION-113 Propose a checklist of points to verify before LC for
APIs, including REST-ful, minimization, policy-binding notes added

maxf: in this case we don't need to receive a Message object back

... there are no use cases for it

<richt> **ACTION:** Summarize the SuccessCallback patterns and use cases for
each method (i.e. use Function or SuccessCallback(Message message)) [recorded
in [http://www.w3.org/2010/03/18-dap-minutes.html#action04][19]]

<trackbot> Sorry, couldn't find user - Summarize

<richt> **ACTION:** richt to summarize the SuccessCallback patterns and use
cases for each method (i.e. use Function or SuccessCallback(Message message))
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action05][20]]

<trackbot> Created ACTION-135 - Summarize the SuccessCallback patterns and use
cases for each method (i.e. use Function or SuccessCallback(Message message))
[on Richard Tibbett - due 2010-03-25].

<dom> **ACTION:** maxf to change message callbacks to be of type Function
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action06][21]]

<trackbot> Created ACTION-136 - Change message callbacks to be of type
Function [on Max Froumentin - due 2010-03-25].

maxf: MessageProperties interface has the usual fields that are found in the 3
types we considered

... do we have sequences or arrays?

<dom> ACTION-113: also check usage of Array vs sequences

<trackbot> ACTION-113 Propose a checklist of points to verify before LC for
APIs, including REST-ful, minimization, policy-binding notes added

<dom> [WebIDL Sequences][22]

<dom> [WebIDL Arrays][23]

bryan: so there's multiple distinct "to:" addresses

<scribe> **ACTION:** maxf to change sequences into arrays [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action07][24]]

<trackbot> Created ACTION-137 - Change sequences into arrays [on Max
Froumentin - due 2010-03-25].

darobin: attachment should be a list of blobs

<darobin> **ACTION:** Max to change array of DOMString attachments to array of
Blobs [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action08][25]]

<trackbot> Created ACTION-138 - Change array of DOMString attachments to array
of Blobs [on Max Froumentin - due 2010-03-25].

maxf: section 7: can it be removed?

... section 8: it shouldn't say we support multiple accounts at the API level

richt: should we support a subscribe() targeted to just one account?

darobin: then there's a need to be able to enumerate accounts, it gets
complicated

... what happens when you set an attribute which is not supported by the type?
(Eg. attachment for SMS)

... we should re-write that normative statement (section 5 - supported
messaging types)

<scribe> **ACTION:** maxf to fix section 5 "supported messaging types"
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action09][26]]

<trackbot> Created ACTION-139 - Fix section 5 "supported messaging types" [on
Max Froumentin - due 2010-03-25].

ilkka: attachments - how do you know the mimetype if it's a blob?

darobin: we should use a File array

**RESOLUTION: multiple account management is left to the UI**

<dom> **ACTION:** Maxf to turn array of paths into array of files for
attachments in Messaging API [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action10][27]]

<trackbot> Created ACTION-140 - Turn array of paths into array of files for
attachments in Messaging API [on Max Froumentin - due 2010-03-25].

bryan: "from" field should not be settable

<dom> close ACTION-138

<trackbot> ACTION-138 Change array of DOMString attachments to array of Blobs
closed

<scribe> **ACTION:** maxf to update the spec to make "from" field not writable
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action11][28]]

<trackbot> Created ACTION-141 - Update the spec to make "from" field not
writable [on Max Froumentin - due 2010-03-25].

<dom> ACTION-138: overtaken by ACTION-140

<trackbot> ACTION-138 Change array of DOMString attachments to array of Blobs
notes added

richt: when is "from:" set? at creation time?

dom: at send() time

<dom> dom: leaking the From is probably not a good idea

<dom> ... might not want to share my phone number or email with the app/site

bryan: does send() popup an UI which allows the user to review the message?

... and does the UI allow to select a default account for such operation?

<dom> richt: should we have two separate interfaces for Incoming and Outgoing
messages?

<dom> dom: with different readonly properties too

<dom> richt: would distinguish From in Incoming and Outgoing

<dom> dom: and bcc would also be different

<dom> maxf: I'll define two types and see what it looks like

<richt> From would be available in incoming (read-only) but not settable or
readable in outgoing

<dom> **ACTION:** maxf to propose two interfaces Outgoing and Incoming
messages for messaging API [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action12][29]]

<trackbot> Created ACTION-142 - Propose two interfaces Outgoing and Incoming
messages for messaging API [on Max Froumentin - due 2010-03-25].

<dom> PROPOSED RESOLUTION: Publish messaging API as FPWD once actions items
are implemented

no objections

**RESOLUTION: Publish messaging API as FPWD once actions items are
implemented**

bryan: what's the resolution about filters

maxf: we'll look at the BONDI proposal

AnssiK: section 6.3.2 mentions Outgoing messaging folder. it should be
rephrased to state that a UI will allow to choose the account

### Policy/Privacy/Security

<fjh> why not say, that the message has been sent

### Gallery

<marengo_scribe> [the Gallery API][30]

<fjh> s/<marengo> Topic: Policy\/Privacy\/Security//

wonsuk: the spec is inspired by the BONDI spec

... section 2.1 more examples are needed

... [describes the 2.1 usage example]

<dom> [Request for review of MAWG "API for Media Resource"][31]

wonsuk: section 3 is about security & privacy

darobin: there will be an external document, it will be referred here

... moves to section 4

<richt> Gallery API - get(..) vs find(..) ??

darobin: galleries interface. getGalleries() offers access to the Media
Galleries

... [describes gallery interface]

... GalleryProperties contains details about a specific Gallery

richt: GallerySuccessCB can be a function object

AnssiK: it might be beneficial to pass the object we're working on to the
callback

aguillou: can you add/remove objects from a gallery?

wonsuk: yes, such methods will be added

richt: what's open() actually doing

wonsuk: it could trigger some memory managerment options for allocating
resources

AnssiK: open() should be in its own interface, and be called synchronously

dom: do we want an open() or a find()?

... a find() with parameters for limiting the number of items

AnssiK: can we reuse something from MAWG?

wonsuk: it support 20+ media types

AnssiK: can we also layer something on the File API

bryan: the delta is the access to meta-data

AnssiK: what has been the implementation experience in bondi?

... any feedback?

... I'll send my comments on the list, and would appreciate some feedback from
BONDI

<richt> latest BONDI gallery spec: [http://bondi01.obe.access-
company.com/1_1_5179_145/gallery.html][32]

<scribe> **ACTION:** AnssiK to provide feedback on the list [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action13][33]]

<trackbot> Sorry, couldn't find user - AnssiK

<dom> **ACTION:** Anssi to provide feedback on the list on Gallery API
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action14][34]]

<trackbot> Created ACTION-143 - Provide feedback on the list on Gallery API
[on Anssi Kostiainen - due 2010-03-25].

<richt> BONDI Gallery demo: [http://bondi01.obe.access-
company.com/1_1_5179_145/gallery.html#ifGallery][35]

wonsuk: goes back to Gallery interface (changeView method)

... there is a getMediaObject for retrieving a media object by id

... GalleryProperties interface contains metadata about the gallery

... MediaObject IF is missing some functions (add, update, find, delete) which
will be defined soon

... MediaObjectProperties IF should inherit something from MAWG

<dom> [API for Media Resource 1.0][36]

bryan: [API for Media Resource] spec is intended to define a common set of
attributes which are common to all formats

... we should try to use a consistent set or properties

<dom> [Mapping tables of Ontology for Media Resource][37]

<dom> [Mapping to iTunes format][38]

wonsuk: ViewType IF describes how a gallery is displayed

<dom> [ViewType really is a filter/sorter interface; it needs to be renamed in
something easier to relate to]

wonsuk: ordering criteria, date filters

AnssiK: there could be a sort() method in Gallery

bryan: what about random filtering (e.g. shuffle)

AnssiK: it could be done by the app, if there's easy access to metadata

darobin: we're running out of time

bryan: let's align this with other filters in DAP APIs (eg. media item file
size)

drogersuk: there's some basic filter in ViewType

darobin: yes, it should be consistent through all the apis

wonsuk: there are no use cases in the spec, yet

... that's all for gallery

[5 minutes break]

### Policy/Privacy/Security

-> [http://dev.w3.org/2009/dap/privacy-reqs/][39] Privacy Reqs draft

fjh: goes through the updated version

... section 6: privacy requirements

... mentions minimization

... replicates the table we designed

... this could go FPWD

<dom> **ACTION:** Dom to take an editorial pass at privacy-reqs [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action15][40]]

<trackbot> Created ACTION-144 - Take an editorial pass at privacy-reqs [on
Dominique Hazaël-Massieux - due 2010-03-25].

-> [http://dev.w3.org/2009/dap/policy-reqs/][41] Policy Reqs draft

fjh: scrolls the doc

... section 8 use cases

... section 9: requirements

... concerned about the next steps (section 9.4.1, 9.4.2)

<scribe> **ACTION:** bryan to provide an architectural flow for Policy Reqs
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action16][42]]

<trackbot> Created ACTION-145 - Provide an architectural flow for Policy Reqs
[on Bryan Sullivan - due 2010-03-25].

LauraA: what's the relation with the joining of the BONDI and Nokia proposals
(it is ongoing work)

<dom> [I think we would better served with use cases than requirements for
policy]

<dom> Dave: the best way is probably to go ahead with the policy proposal

<dom> ... I think we'll find a common ground for the trust domains questions

<dom> Frederick: so I'll remove the privacy stuff out of policy-reqs, and
we'll leave policy-reqs on the side until we get a better idea of whether we
want to do something with it

<dom> Frederick: the threats considerations should also address the security
questions

<dom> ... what about sending a CfC for privacy-reqs as we agreed?

<dom> **ACTION:** Frederick to send a CfC on privacy-reqs when Dom is done
with edits [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action17][43]]

<trackbot> Created ACTION-146 - Send a CfC on privacy-reqs when Dom is done
with edits [on Frederick Hirsch - due 2010-03-25].

### other APIs

<dom> David: for Commlog, in BONDI, we are moving into a more general
telephony API

<darobin> AnssiK: what's the use case for receiving a call programmatically

<darobin> Bryan: customer care widget

<darobin> ... David's point is that the API has changed to only do logs, but
the calls are in the messaging API

<darobin> David: it's cleaner

<darobin> ... you might want to consider it, but I realise it's not in the
charter

<darobin> Bryan: in principle it's the ability to know abotu call events

<darobin> FJH: does telephony expand the scope and amount of work

<darobin> ... so it's the same functionality in a different place?

<darobin> David: BONDI has a commslog that does logging, then later we'll
extend to calls — but that's out of DAP charter

<darobin> David: if you were to drop Commslog we wouldn't be against it, so
long as its information goes somewhere

<dom> trackbot, you are wrong

<trackbot> Sorry, dom, I don't understand 'trackbot, you are wrong'. Please
refer to [http://www.w3.org/2005/06/tracker/irc][44] for help

<dom> trackbot, thanks

<trackbot> You are most welcome, dom

### Charter

<darobin> FH: it's a tight schedule

<darobin> ... it'll take at least a quarter to exit LC+CR

<darobin> ... that means we have to have things done soon

<darobin> Dom: one of the reason we have the end date is because people are
eagerly awaiting the result

<darobin> ... our work is more relevant if it finishes on time

<darobin> FH: we've agreed on where we're going

<darobin> .... things are well on their way

<darobin> ... for 10Q2-Q3 we have to get everything on Rec track

<darobin> ... [explains process really, really fast]

<darobin> ... you don't want to wait until CR before you do some interop
testing

<darobin> ... if we could avoid multiple LC it's nice

<darobin> ... after CR, PR

<darobin> ... next year needs to be all about CR

<darobin> .... so we have to finish LCs this year

<darobin> ?

<bsulliva> scribenick: bsulliva

fjh: gives an overview of the status, available on the home page

... tasks API, why are we waiting, is this simple with input contributions

dom: it may be as complicated as calendar

fjh: wait for calendar and layer it on top?

... can we draft the non-recurrent stuff first?

dom: we need at least an editor volunteer to get started

fjh: what happens if we get no volunteers

drogersuk: we can query the BONDI supporters that are DAP members who may be
able to provide input

<dom> **ACTION:** David to look for an editor for the Tasks API [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action18][45]]

<trackbot> Created ACTION-147 - Look for an editor for the Tasks API [on David
Rogers - due 2010-03-25].

fjh: if we know early, we will be better able to deal with the options

richt: calendar will help with the issues

fjh: applauncher, we need an editor

wonsuk: volunteers as editor

bsulliva: I can provide input

wonsuk: 4-6 weeks to get a draft started

fjh: appconfig, we dropped this and have nothing more to do

... user interaction, to webapps?

bsulliva: the modify the user interface e.g. menus are not covered by window
modes

fjh: do we need to do those at this time?

drogersuk: this should be done in V1

fjh: anssi suggested this was covered by the webapps API's

bsulliva: we need someone to survey webapps to determine the gaps

<dom> [Anssi's email on user interaction API requirements][46]

<AnssiK> [][47]

anssi: we have some options in HTML5 spec re menu controls

fjh: is someone familiar with BONDI able to decide if we have filled the gaps
already?

<AnssiK> [][48]

bsulliva: I will take this one on

<dom> **ACTION:** Bryan to compare user interaction input with what already
available in HTML5 / WebApps [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action19][49]]

<trackbot> Created ACTION-148 - Compare user interaction input with what
already available in HTML5 / WebApps [on Bryan Sullivan - due 2010-03-25].

darobin: will review what Bryan writes

fjh: on commlog, what are the next steps

<fjh> david suggests that part goes into messaging, and commlog might be
renamed telephony

drogersuk: we did not make a resolution - we need to make sure what was
intended for commlog goes into messaging and the rest into something else

... a suggestion is to pull the messaging parts out and defer the rest to a
telephony API for V2

anssi: you can use commlog to find the people you want to interact with

richt: we could take the approach of a generic log

drogersuk: we would be creating new concepts there, not basing that upon
established work

dom: commlog is more like accessing your mailbox

fjh: who can help with the commlog draft?

dom: we could add the read/log functions to the messaging API

drogersuk: we have an action to review the messaging input from BONDI for
guidance on that

... there are use cases where call log is useful

bsulliva: we could just call what's left as the telephony API

fjh: the proposal is for messaging to have the messaging log functions

drogersuk: we realized in BONDI that the logs should be associated with the
feature

<fjh> bsullivan notes messaging is a feature set, message log is a feature

dom: without the policy framework in place, putting those functions into a
common module also makes sense (one that is focused on log use, regardless of
the type)

richt: are you saying they should be common, as a distinct messaging API with
log features makes more sense

drogersuk: with focus on making developers's life easier, we decided to focus
on the distinct types of services, e.g. messaging and telephony as distinct
things

dom: communication is a common function regardless of the communication type

fjh: we said in the privacy discussion that you need access to the logs

dom: we maybe need an issue to continue this

<dom> ISSUE: should Communication Logs be part of the messaging API or part of
a telephony API?

<trackbot> Created ISSUE-82 - Should Communication Logs be part of the
messaging API or part of a telephony API? ; please complete additional details
at [http://www.w3.org/2009/dap/track/issues/82/edit][50] .

<dom> **ACTION:** David to summarize discussions on BONDI regarding
Communication Log/messaging/Telephony API [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action20][51]]

<trackbot> Created ACTION-149 - Summarize discussions on BONDI regarding
Communication Log/messaging/Telephony API [on David Rogers - due 2010-03-25].

fjh: re other deliverables, for interoper there is work to make sure things
work well, so they are better prepared for the formal call

... not sure the nature of DAP API's fit that model

... the call for implementations at CR can be prefaced with interop testing
within the group

... that is easier if you have interop testing in advance

... do we have enough vendors here to do that pre-interop, and who wtites test
cases?

... who will run them?

darobin: we will do both

drogersuk: a lot more than two interoperable implementations based upon BONDI
will likely implement the DAP API's

anssi: does the approach used in webapps work for us?

fjh: the real question is who?

seungyun: is it possible to base the testing on prototypes of web runtimes?

<fjh> we should confirm informal interop in June

dom: I think we should require at least two browsers and web runtimes

<fjh> dom notes will need two browser implementations plus 2 web runtime

fjh: a virtual interop may make sense

bsulliva: maybe some of the BONDI test framework would be useful to DAP

<dom> **ACTION:** David to send BONDI experience with testing for device APIs
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action21][52]]

<trackbot> Created ACTION-150 - Send BONDI experience with testing for device
APIs [on David Rogers - due 2010-03-25].

drogersuk: there might be 30 or more implementations to consider in this case

... we would like to follow similar approaches as Marcos did on the widgets
P&C

fjh: testable assertions may an issue for policy

... getting started on this by July should give us time

... re liaisons, do we need to worry about accessibility in API's?

darobin: have no concerns that come to mind

bsulliva: requiring user interaction is a concern for usability

fjh: anything else?

<dom> [Future Work for DAP][53]

drogersuk: do we have a wish list for V2?

fjh: should provide a heads up if it might inform our current work

darobin: AOB?

<dom> RESOLUTION: Thanks Jirka for hosting us!

<richt> Thanks!

fjh: once, twice, adjourned

## Summary of Action Items

**[NEW]** **ACTION:** Anssi to provide feedback on the list on Gallery API
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action14][34]]

**[NEW]** **ACTION:** AnssiK to provide feedback on the list [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action13][33]]

**[NEW]** **ACTION:** Bryan to compare user interaction input with what
already available in HTML5 / WebApps [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action19][49]]

**[NEW]** **ACTION:** bryan to provide an architectural flow for Policy Reqs
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action16][42]]

**[NEW]** **ACTION:** David to look for an editor for the Tasks API [recorded
in [http://www.w3.org/2010/03/18-dap-minutes.html#action18][45]]

**[NEW]** **ACTION:** David to send BONDI experience with testing for device
APIs [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action21][52]]

**[NEW]** **ACTION:** David to summarize discussions on BONDI regarding
Communication Log/messaging/Telephony API [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action20][51]]

**[NEW]** **ACTION:** Dom to take an editorial pass at privacy-reqs [recorded
in [http://www.w3.org/2010/03/18-dap-minutes.html#action15][40]]

**[NEW]** **ACTION:** Frederick to send a CfC on privacy-reqs when Dom is done
with edits [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action17][43]]

**[NEW]** **ACTION:** Max to change array of DOMString attachments to array of
Blobs [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action08][25]]

**[NEW]** **ACTION:** maxf to change message callbacks to be of type Function
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action06][21]]

**[NEW]** **ACTION:** Maxf to change message.create(TYPE) to
message.createTYPE() [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action02][17]]

**[NEW]** **ACTION:** maxf to change sequences into arrays [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action07][24]]

**[NEW]** **ACTION:** maxf to fix section 5 "supported messaging types"
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action09][26]]

**[NEW]** **ACTION:** maxf to make subscribe() method use events [recorded in
[http://www.w3.org/2010/03/18-dap-minutes.html#action01][13]]

**[NEW]** **ACTION:** maxf to propose two interfaces Outgoing and Incoming
messages for messaging API [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action12][29]]

**[NEW]** **ACTION:** maxf to replace Message.timestamp with Message.sent and
Message.received [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action03][18]]

**[NEW]** **ACTION:** Maxf to turn array of paths into array of files for
attachments in Messaging API [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action10][27]]

**[NEW]** **ACTION:** maxf to update the spec to make "from" field not
writable [recorded in [http://www.w3.org/2010/03/18-dap-
minutes.html#action11][28]]

**[NEW]** **ACTION:** richt to summarize the SuccessCallback patterns and use
cases for each method (i.e. use Function or SuccessCallback(Message message))
[recorded in [http://www.w3.org/2010/03/18-dap-minutes.html#action05][20]]

**[NEW]** **ACTION:** Summarize the SuccessCallback patterns and use cases for
each method (i.e. use Function or SuccessCallback(Message message)) [recorded
in [http://www.w3.org/2010/03/18-dap-minutes.html#action04][19]]


[End of minutes]

* * *

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

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

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

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

   [3]: http://www.w3.org/2010/03/18-dap-irc

   [4]: #agenda

   [5]: #item01

   [6]: #item02

   [7]: #item03

   [8]: #item04

   [9]: #item05

   [10]: #item06

   [11]: #ActionSummary

   [12]: http://dev.w3.org/2009/dap/messaging/

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

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

   [15]: http://bondi.omtp.org/1.1/apis/messaging.html

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

   [17]: http://www.w3.org/2010/03/18-dap-minutes.html#action02

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

   [19]: http://www.w3.org/2010/03/18-dap-minutes.html#action04

   [20]: http://www.w3.org/2010/03/18-dap-minutes.html#action05

   [21]: http://www.w3.org/2010/03/18-dap-minutes.html#action06

   [22]: http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence

   [23]: http://dev.w3.org/2006/webapi/WebIDL/#idl-array

   [24]: http://www.w3.org/2010/03/18-dap-minutes.html#action07

   [25]: http://www.w3.org/2010/03/18-dap-minutes.html#action08

   [26]: http://www.w3.org/2010/03/18-dap-minutes.html#action09

   [27]: http://www.w3.org/2010/03/18-dap-minutes.html#action10

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

   [29]: http://www.w3.org/2010/03/18-dap-minutes.html#action12

   [30]: http://dev.w3.org/2009/dap/gallery/

   [31]: http://lists.w3.org/Archives/Member/member-device-
apis/2010Mar/0001.html

   [32]: http://bondi01.obe.access-company.com/1_1_5179_145/gallery.html

   [33]: http://www.w3.org/2010/03/18-dap-minutes.html#action13

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

   [35]: http://bondi01.obe.access-
company.com/1_1_5179_145/gallery.html#ifGallery

   [36]: http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100309/

   [37]: http://www.w3.org/TR/mediaont-10/#property-mapping-table

   [38]: http://www.w3.org/TR/mediaont-10/iTunes.html

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

   [40]: http://www.w3.org/2010/03/18-dap-minutes.html#action15

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

   [42]: http://www.w3.org/2010/03/18-dap-minutes.html#action16

   [43]: http://www.w3.org/2010/03/18-dap-minutes.html#action17

   [44]: http://www.w3.org/2005/06/tracker/irc

   [45]: http://www.w3.org/2010/03/18-dap-minutes.html#action18

   [46]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Oct/0207.html

   [47]: http://lists.w3.org/Archives/Public/public-device-
apis/2009Oct/0212.html

   [48]: http://www.w3.org/TR/html5/interactive-elements.html#menus

   [49]: http://www.w3.org/2010/03/18-dap-minutes.html#action19

   [50]: http://www.w3.org/2009/dap/track/issues/82/edit

   [51]: http://www.w3.org/2010/03/18-dap-minutes.html#action20

   [52]: http://www.w3.org/2010/03/18-dap-minutes.html#action21

   [53]: http://www.w3.org/2009/dap/wiki/FutureWork

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

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



Received on Thursday, 18 March 2010 13:50:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:07 GMT