See also: IRC log
<trackbot> Date: 09 March 2011
<fjh> trackbot-ng, start telecon
<trackbot> Meeting: Device APIs and Policy Working Group Teleconference
<trackbot> Date: 09 March 2011
<scribe> scribeNick: nwidell
<fjh> Daylight savings time start
<fjh> http://lists.w3.org/Archives/Member/member-device-apis/2011Mar/0001.html
<fjh> W3C Workshop on Web Tracking and User Privacy
<fjh> http://www.w3.org/2011/track-privacy/
<fjh> 2nd Last Call Working Draft Transition announcement of the Ontology for Media Resource 1.0
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0028.html
<fjh> Robin already commented on previous draft
darobin some relationship with our work, may want to revisit API at later point
<fjh> Content security policy
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0014.html
dom: it is an interesting proposal, but fairly different scope compared to DAP
<fjh> dom notes security mechanism related to http headers, but different scope from dap, focus on cross-site scripting
<fjh> Universal control API
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0021.html
fjh: not quite sure what to do with proposal,
richt: it would beneficial to have other players in DAP, nice to bring work in
<richt> nice to bring other industries in to a well-balanced discussion forum.
darobin: They are interested, some quite interesting security issues, we should reach out to BBC about this, should take it into chartering discussion
<fjh> Overview of W3C technologies for mobile Web applications
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Feb/0108.html
<fjh> F2F is next week, no teleconference call, and no call following week.
<fjh> Approve 23 February minutes
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Feb/att-0105/minutes-2011-02-23.html
<Gyubong_Oh> I am not famillar with IRC. probably, yes, I am
RESOLUTION: Minutes from 23 February 2011 approved
<fjh> Draft agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_15,_16,_18_March_2011,_Seoul
darobin: Starting time (0900) ok?
fjh: good to have early start for people calling in.
<dom> richt, if you could send your input re ACTION-343 before the F2F, it would be best for the charter discussions
<richt> I will provide that on the list
<dom> (5pm Seoul is 8am London, FWIW)
<dom> http://timeanddate.com/worldclock/meetingtime.html?day=15&month=3&year=2011&p1=235&p2=195&p3=43&p4=137&iv=0 is a better link given daylight change in US on Sunday
<richt> yeah, dialling in from Europe is going to hurt.
<jmorris> fyi, 9am in Korea is midnight in London
fjh: might switch contacts and interop.
richt: what about device?
<dom> ACTION-300?
<trackbot> ACTION-300 -- Claes Nilsson to start working on use cases and requirements for video/audio conference à la <device> element -- due 2010-11-12 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/300
fjh: please send comments on Agenda to public list
<fjh> Logistics information: http://www.w3.org/2009/dap/wiki/SeoulF2F2011
<fjh> zakim reservation, http://lists.w3.org/Archives/Member/member-device-apis/2011Mar/0000.html
<fjh> http://www.w3c.or.kr/DAP2011/
<richt> RE: F2F. I'm concerned on the timings for dialling in from Europe but not much we can do on that. Will see how it goes.
fjh: DAP members do not need to register for workshop, others do
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0006.html
<fjh> Current charter, http://www.w3.org/2009/05/DeviceAPICharter.html
<fjh> Proposed charter, http://www.w3.org/2010/11/DeviceAPICharter.html
<fjh> Call out Sensor Specification separately from SysInfo (Dzung)
<fjh> Additional deliverables, Privacy Mechanisms, Feature Permissions
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0016.html
<fjh> Audio volume API, http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0023.html
fjh: Suggest to add sensor deliverable
... Feature permission should certainly be a group deliverable
... we need to mention a Privacy deliverable in the charter
<darobin> +1
dom: The more concrete proposal we have the easier it is to discuss it
fjh: not sure how detailed how the text wrt privacy can be at this point
dom: Need to define at least rough scope.
<fjh> ACTION: fjh to propose concrete text for privacy and feature permission for draft charter [recorded in http://www.w3.org/2011/03/09-dap-minutes.html#action01]
<trackbot> Created ACTION-344 - Propose concrete text for privacy and feature permission for draft charter [on Frederick Hirsch - due 2011-03-16].
<dom> ACTION-343?
<trackbot> ACTION-343 -- Richard Tibbett to propose better wording for System information and events api in new charter -- due 2011-03-02 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/343
fjh: Sensors are also wide reaching, need to define scope, AR might be based on sensor work
<darobin> http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0015.html
darobin: Microsoft provided some good indirect feedback on the Media Capture API
... includes some usage examples, and how to be used in code
<Zakim> richt, you wanted to ask if we should direct them to the <device> element instead of overloading the file input control (like we tried and failed to do).
richt: Two proposals (capture/device), streaming more related to device, should we point them there
darobin: It is Microsoft's input to the incubator group
richt: The concept of speech apis is very important
... we should try to avoid fragmentation
darobin: Microsoft's document was definitely feedback to DAP
<dom> note that we don't have any of the editors of the document on the call, unfortunately
<dom> ACTION: Laszlo to look at Microsoft feedback on Capture API [recorded in http://www.w3.org/2011/03/09-dap-minutes.html#action02]
<trackbot> Created ACTION-345 - Look at Microsoft feedback on Capture API [on Laszlo Gombos - due 2011-03-16].
<dom> ACTION-345: http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html#capture_api_extensions
<trackbot> ACTION-345 Look at Microsoft feedback on Capture API notes added
Laszlo: I can be an editor of Media Capture
<richt> Updates to the Contacts API (cvs_log) http://dev.w3.org/cvsweb/2009/dap/contacts/Overview.html
darobin: Two topics, updates and search filters
richt: Updated spec in line with previous discussions on calls, list
... feedback would be great.
darobin: Should try to have feedback before F2F
<darobin> ISSUE-106?
<trackbot> ISSUE-106 -- Does Contacts API having a timezone field make sense, should it be utfOffset or utcOffset and tz to better match vCard? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/106
<Zakim> dom, you wanted to ask about LC
dom: Is the Time Zone issue solved?
<dom> [re search Filter, I think we should be much more silent since search filters are meant as hints rather than as strict filters]
<fjh> should add comment to issue noting how it is resolved when closing it
richt: the current spec contains informative info about time zone, but it is a dual-purpose attibute,
fjh: Why remove search filters?
richt: filters don't add value to API, only to UI. The complexity of the search filter outweigh benefits
<dom> (I would actually favor not defining an algorithm for filtering, but not removing filters completely)
<darobin> +1 to dom
richt: search filters are hard, we can put it back later
<darobin> +1
dom: intent to keep the filter parameter for UA use, but scrap filtering algorithm
<fjh> +1 to retaining feature, not sure how well defined it has to be
richt: scrap filtering algorithm might work
<fjh> are the user interaction guidelines is entirely optional, should it be?
dom: We often provide hooks for UAs, but not ull functionality
<fjh> s/Is the user interrface/are the user interaction guidelines/
darobin: One advantage of having search filter present, then in trusted environments searches can be made more efficiently
<darobin> RESOLUTION: Keep the search filter parameter, but simplify the feature
<Zakim> fjh, you wanted to ask about what happends to 4.2
<Zakim> darobin, you wanted to talk about CfC
darobin: Wait with CfC until updates made
darobin: Fold the current discussion into charter discussion?
dom: better to keep progress on current work
darobin: Proposals?
... might want to split work into safe/simple parts and complex/extensible parts
<darobin> +1 for people coming up with concrete proposals
fjh: wasn't idea to keep sysinfo, but pull out sensors to separate generic FW api
dom: we need concrete proposals
<darobin> +1
<darobin> [let's do battery]
richt: If we expose only a tiny amount of device information we have actually succeeded
<dom> +1 to start with simple and do it well :)
<fjh> section 4 of sysinfo outlines various aspects that could be treated separately
<darobin> ACTION: Robin to propose a sweet and simple battery API [recorded in http://www.w3.org/2011/03/09-dap-minutes.html#action03]
<trackbot> Created ACTION-346 - Propose a sweet and simple battery API [on Robin Berjon - due 2011-03-16].
Laszlo: look at availability of sys info in android may be a good starting point
<darobin> ACTION: Laszlo to come up with some examples and rough ideas for simple sysinfo APIs at the f2f [recorded in http://www.w3.org/2011/03/09-dap-minutes.html#action04]
<trackbot> Created ACTION-347 - Come up with some examples and rough ideas for simple sysinfo APIs at the f2f [on Laszlo Gombos - due 2011-03-16].
darobin: Use Messaging based on URI schemes
richt: My proposal was to expose messagin though libraries, URI schemes client/server interaction etc, no specific API
... it is an API that does not need to be an API
... not convinced by the existing additions (callbacks, attachments)
darobin: But Apple's Messaging API (simple)
dom: Can't discuss it
... relying on client server will not work with SMS/MMS
richt: is there enough incentive with callbacks/attachments to have separate API
darobin: can we create dead simple API (e.g. only adding attachments)?
<darobin> [the hidden problem no one has raised is how the heck the browser gets to know the user's email configuration...]
richt: extend URIs with extra parameters for attachments
<dom> [darobin, you wouldn't need it with our current API]
<darobin> <form target="mmsto:+33681754541"><textarea>...</textarea><input type=file multiple/></form>
dom: doing attachments through URI schemes is unlikely
<darobin> [dom, how are you going to send something as robin@berjon.com without knowing my server's password? use open relays?]
<dom> [through my MUA]
<darobin> navigator.sendMessage("mailto:foo@bar.com", [blob1, blob2, blob3], errorCB)
<dom> right
<darobin> [dom, right, but I'm not sure how to communicate attachments to my MUA]
<dom> [well, using your local IPC system, I would assume]
richt: Implementor support is very important
dom: but the problem has been to get that implementor feedback
<darobin> [we want a more fleshed out proposal, then get feedback]
dom: we probably have a start to a new proposal
<darobin> +1
dom: should aim for something more "webby"
<dom> ACTION: Dom to send concrete proposal for navigator.sendMessage with URI scheme [recorded in http://www.w3.org/2011/03/09-dap-minutes.html#action05]
<trackbot> Created ACTION-348 - Send concrete proposal for navigator.sendMessage with URI scheme [on Dominique Hazaël-Massieux - due 2011-03-16].
<darobin> ACTION-341?
<trackbot> ACTION-341 -- Dominique Hazaël-Massieux to reserve zakim line for f2f -- due 2011-03-09 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/341
<darobin> ACTION-322?
<trackbot> ACTION-322 -- Frederick Hirsch to follow up on ECMA TC-39 coordination -- due 2011-01-20 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/322
<darobin> ACTION-335?
<trackbot> ACTION-335 -- Frederick Hirsch to propose charter changes related to security and privacy deliverables -- due 2011-02-23 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/335
<dom> ISSUE-81?
<trackbot> ISSUE-81 -- How to represent dates? ES has Date but with no TZ information; using strings is less than ideal; do we have to create a Web Dates specification? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/81
<dom> ACTION-297?
<trackbot> ACTION-297 -- Robin Berjon to draft up TZDate -- due 2010-11-11 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/297
richt: Would be great if javascript had a Calendar object (timezonedate)
<richt> similar to Java Calendar class
<fjh> Please review the open actions list, note any actions that should be closed and try to complete actions, preferably before the F2F if feasible
<fjh> open action list, http://www.w3.org/2009/dap/track/actions/open