# Device APIs and Policy Working Group Teleconference

## 15 Mar 2011

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    BJ_Kim, Bo_Chen, Bryan_Sullivan, Dominique_Hazael-Massieux, DongHyun_Kang,
Frederick_Hirsch, Gyubong_Oh, Jing_Win, JonathanJ, Jun_Liao, Kangchan_Lee,
Kyung-Tak_Lee, Laszlo_Gombos, Manyoung_Cho, Marco_Marengo, Minkyo_Im,
Robin_Berjon, Soonbo_Han, Soonho_Lee, Sung-Ok_You, Suresh_Chitturi,
Wonsuk_Lee, Yan_Liang

Regrets


Chair

    Robin_Berjon, Frederick_Hirsch

Scribe

    Marco Marengo

## Contents

  * [Topics][5]

    1. [Introductions, Minutes Approval, Agenda Review, Logistics][6]

    2. [DAP Charter review][7]

    3. [Webinos Introduction][8]

    4. [HTML Media Capture and Media Capture API][9]

    5. [Media Capture API][10]

    6. [RTC web][11]

    7. [Web Introducer][12]

    8. [Issue Review][13]

    9. [Recess][14]

  * [Summary of Action Items][15]

* * *

<trackbot> Date: 15 March 2011

<Suresh> I don't hear you!

<marengo> Scribe: Marco Marengo

<marengo> scribenick: marengo

fjh: we'll start with introductions

### Introductions, Minutes Approval, Agenda Review, Logistics

<Suresh> Note: the line is poor (echo, noise) , and i'll try to use chat as
much as possible

fjh: reviews the agenda for this meeting

<lgombos> dom: lgombos joined

**RESOLUTION: minutes from last meeting (March 9) are approved**

### DAP Charter review

<dom> RESOLUTION: Happy birthday Robin

<dom> [http://www.w3.org/2011/Talks/dhm-dap-recharter/][16]

dom: presents a set of slides about the rechartering process

... draft sent to the ML on Feb 2

... the final draft must be ready for early May

... will highlight the main changes

... 1) removal of policy framework

<fjh> current charter -> [http://www.w3.org/2009/05/DeviceAPICharter][17]

dom: 2) tightening of the scope of the APIs

... 3) clarification on security model

<dom> [http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2009%
2F05%2FDeviceAPICharter&doc2=http%3A%2F%2Fwww.w3.org%2F2010%2F11%2FDeviceAPICh
arter.html][18]

dom: policy framework: there's been a lot of misunderstanding about this
topic, there's been rough consensus on removing it (concerns about it have
been expressed by DT, AT&T)

fjh: we still need to address security and privacy

dom: there's a draft of permission identifiers for APIs (eg. accessing
geolocation, address book) as well-known strings

<Suresh> The question is can we separate the policy framework from the APIs? -
to me/us the APIs can be usable both within browser and widgets and policy
framework is a separate layer that can be implemented along side the APIs

dom: do we intend to continue working on it? if so it should be stated in the
charter

<Suresh> i would not tie the policy framework exclusively to widgets

dom: my personal inclination would be to include this in the charter

<lgombos> dom: +1 to include it in the charter

dom: that would probably address the privacy and security issues

... security model. a few companies complained that it was too closely linked
to "browser-model"

<fjh> proposed charter [http://www.w3.org/2010/11/DeviceAPICharter.html][19]

bryan: are we coming out with specific criteria about what facilitates open
web environment security?

... our criteria for what's in or out is a bit too foggy (untechnical)

dom: it's not a matter of taste, it's a matter of consensus.

darobin: it's not easy to define a set of criteria, fuzzyness does not help
building consensus.

... there's room for a note about the security model

fjh: we should discuss it during the F2F (tomorrow or on friday)

dom: concern about messaging apis is about usefulness (to grant access to your
mailbox to an external website)

<Suresh> It is no different from accessing your contacts or calendar?

<Suresh> i was comments on the succes criteria

<Suresh> we expect the APIs to be implemented on the browser and widgets

<fjh> s/suresh, you need to type. we get 1/2 sentence then silence etc//

darobin: example of good design. contacts.find() in the open web prompts the
user. in widgets it should return the results immediately

<Suresh> The current wording seems to say that only browser implementation
would be used to judge the usefulness of the API

<dom> "APIs that cannot be demonstrated to be implementable securely within
the default browser context will not be released."

<Suresh> @robin: if we expect a prompt in the browser we should expect the
same or simialr behavior in widgets as well?

dom: privacy. it has been fixed in the new charter. proposal for best
practises (how to use the apis in a privacy-sensitive way)

<dom> [Privacy workshop, April 28-29][20]

darobin: we could bring the new charter as input to the privacy workshop (end
of april) and get feedback on it

<darobin> **ACTION:** Dom to figure out what are the secrets and evil plans
from Thomas on privacy follow-up [recorded in [http://www.w3.org/2011/03/15
-dap-minutes.html#action01][21]]

<trackbot> Created ACTION-349 - Figure out what are the secrets and evil plans
from Thomas on privacy follow-up [on Dominique Hazaël-Massieux - due
2011-03-22].

fjh: we should add a privacy best practices deliverable to the charter

dom: existing APIs. a couple of APIs could be removed from the new charter:
communication log & gallery

<fjh> agreed next steps for draft charter - add explicit deliverables for
privacy best practices NOTE deliverable, add security permissions REC
deliverable, add privacy REC deliverable with note that this might be taken
over by another group, add privacy use cases and requirements NOTE deliverable

<fjh> not clear whether a working group will come out of do not track
workshop, and whether it is scoped broadly enough to address privacy relevant
to DAP

<fjh> Timing of this may be off for DAP rechartering, given that DAP
rechartering draft needs to be finished in April and has to happen in May

PROPOSED RESOLUTION: remove communication log from the new charter

bryan_sullivan: wrt menus. does html5 provide a way to to this?

darobin: there's hook that works for context menus

-> [http://paulrouget.com/e/nativecontrols][22]

<dom> [http://paulrouget.com/e/nativecontrols][22]

darobin: 1: exposing context menus 2: site specific menus

... 2 is styled in a way which makes clear it's not provided by the UA

<dom> split API for menus, vibrations, menus

<dom> clarify re menus that it is about "promoting HTML5 menu to the chrome"

dom: there's some overlap with Web Notifications WG, but this is more specific

meeting will resume at 11.15

<dom> [we're breaking for 20 minutes]

dom: reshaping of current APIs

... moving app launcher to "intent-based" approach

... (inspired by Android OS Intent mechanism)

... Web Introducer and Web Intent try to reproduce this mechanism in the web
environment

<bryan_sullivan> Comments made in the F2F meeting re rechartering, for the
minutes are in email at thread: [http://lists.w3.org/Archives/Public/public-
device-apis/2011Mar/0085.html][23]

<darobin> **ACTION:** Robin to find a better wording for intents-based
application launcher [recorded in [http://www.w3.org/2011/03/15-dap-
minutes.html#action02][24]]

<trackbot> Created ACTION-350 - Find a better wording for intents-based
application launcher [on Robin Berjon - due 2011-03-22].

bryan_sullivan: how does this relate to 1) content handler registration and 2)
web messaging

dom: it will complement content handler registration with additional features.
web messaging is more fine grained protocol for inter webapps communication.
we're talking about 1-time event communication. they're related but the
overlap is not huge

[http://webintents.appspot.com/][25]

<dom> [WebIntents][25]

<Suresh> can you please join the bridge from F2F?

<Suresh> We cannot hear you on the bridge...are you on?

bryan_sullivan: isn't this more suitable for WebApps instead of DAP

<dom> [Web Introducer][26]

darobin: rechartering webApps is not an option, it's easier to keep it in DAP

bryan_sullivan: as a user, I want to be able to open a specific version of an
external client (Eg. acrobat reader)

darobin: what might be in scope is a way for a widget to register itself as an
handler

<dom> [WebIntents][25]

<dom> [Web Introducer][26]

darobin: the browser can support intents even if the os doesn't. for the basic
things emulation is possible

<bryan_sullivan> My comment re Applaucher API and the WebIntents work: If this
supports the use case of being able to choose a native handler for content
types or URI schemes (given that the registration of native handlers is out of
scope), e.g. open Acrobat for PDFs instead of the browser-default (which may
be an internal PDF viewer), then we would support this as a replacement of the
specific Applauncher API.

dom: another big piece of work is SysInfo. two approaches: 1) focusing on
specific sensors (eg. network, bt, NFC)

darobin: if someone supports BT and/or NFC, it would be useful to exactly
state what will/should be implemented

dom: call for use cases?

<Suresh> if we limit the scope to just discovery that might be ok, but beyond
that it is not clear how specific we want to be with the scope

<fjh2> we should ask for use cases and requirements and not hearing any not
include in draft charter, so that we can move forward (bluetooth, nfc)

Kangchan: SysInfo vs device description

<fjh2> concerned about the potential broadness of the nfc topic, both from IPR
and work perspectives

<Suresh> use of NFC is just becoming popular and until we have good
penetration it might be premature to include it in the charter

dom: device description is more server-side, sysInfo is client side. The
overlap might be on the vocabulary used to describe properties. we're
reconsidering using the vocabulary approach

bryan_sullivan: device description only provides "static" info about the
device model

... SysInfo delivers dynamic info

eg. MNC-MCC

dom: generic sensor API. do we want it and what should it look like?

... new APIs have been suggested: home media connectivity

[http://www.w3.org/2010/11/web-and-tv/][27]

<bryan_sullivan> Comments re SysInfo overlap with DDWG Core Vocabulary and DDR
Simple API: the deployment model for device info supported by the DDR Simple
API (a network service that provides access to network-stored device
information) is valuable and was supported by AT&T. However there are several
aspects that require the additional features that were in scope for SysInfo,
e.g. (a) Instance-specific info (e.g. mobile phone Operator) vs device-generic
info (e.g.

<bryan_sullivan> capabilities based upon evidence e.g. user-agent header); (b)
Dynamic info (e.g. free memory) vs static info; (c) Device-local/offline info
access vs online info access via a network-based API (DDR Simple API)

darobin: DLNA spec is not freely available, and is a very wide spec

... BBC universal control protocol extracts from such protocols

... in terms of discovery: mDNS

<Suresh> It might be better to wait until the scope of the web and tv group
settles down

<Suresh> I would prefer to stay away from specific items that we are not clear
about...we need to deliver what we promise so keeping the scope limited will
help us

dom: another proposal is "audio volume read"

<Suresh> can this be part of sys info?

bryan_sullivan: could it be accessed via SysInfo

darobin: it's a discrete API

dom: <device> element

... success criteria for the group

... we need to include the widget environment and tv

<Suresh> How about "web runtime enviroment (e.g. Browser, widgets)"?

<darobin> [no, "web runtime environment" means "widgets" to most people]

<Suresh> one option would be to remove this statment totally

<Suresh> Just to be clear: i am trying to draw a distinction between the
desktop and mobile, but drawing a distinction browser and a widget is the
problem

<Suresh> We would like to see widgets and browser to use the APIs the same way
and desgined in a similar way

<Suresh> the problem we noticed in the past discussion is that "browser model"
has been used to as way to limit the API design and this is problematic

<darobin> [I don't think that removing this statement is a good solution, it's
a very important goal]

<Suresh> It seems there is a confusion or mis-understanding that widgets = web
environmrnt+policy framework? we don't see it that way and thereofore the
proposed rephrasing "APIs that can be demonstrated without the need of a
specialized policy framework will be released

<dom> Reconvening at 14:15 local time

<Suresh> "APIs that can be demonstrated without the need of a specialized
policy framework will be released

<Suresh> APIs that can be demonstrated without the need of a specialized
policy framework will be released

<Suresh> oops

<Suresh> APIs that can be demonstrated without the need of a specialized
policy framework will be released

<Suresh> replacing the current statement with "APIs that can be demonstrated
without the need of a specialized policy framework will be released" is a good
alternative to indicate that the APIs will be demonstrated using the web
runtime only and not with the assumption of an underlying policy framewrok
which appeared to be the main concern from browser vendors

### Webinos Introduction

<darobin> Dom shows a presentation about webinos

<darobin> slides will be sent to the list later

<darobin> fjh: what's citizen-2-government?

<darobin> dom: e.g. reporting issues, like Open311

<fjh> [http://open311.org/][28]

<darobin> robin: are there any concrete APIs for discovery? long list

<darobin> dom: we're still in the planning stages, so nothing yet

<fjh> [http://webinos.org/about-webinos][29]

<fjh> dom notes first implementations may be on android and windows phone

<fjh> slide compares WAC and webinos

<darobin> dom: webinos will submit its APIs to W3C where applicable

<darobin> robin: wait until they're done or more iterative approach?

<darobin> dom: would hope for more iterative, but we all know how hard it is
to sync across organisations

<fjh> dom: webinos will also be open source project

<fjh> dom: priority round device discovery

<Zakim> fjh, you wanted to ask about level of detail of privacy work

<darobin> fjh: what's the level of detail of work on privacy?

<darobin> dom: right now the focus has been more on requirements than on
solutions

<darobin> dom: there are discussions about whether a BONDI-like policy
framework or not

<darobin> dom: I'm hoping that webinos might be able to propose something for
device discovery

<darobin> dom: unless DAP is faster and it goes the other way

<fjh> dom: BONDI was part of webinos, but WAC is not a member

<inserted> ScribeNick: dom

[http://www.w3c.or.kr/DAP2011/][30]

### HTML Media Capture and Media Capture API

-> [http://dev.w3.org/2009/dap/camera/][31] HTML Media Capture Editors draft

Robin: simple additional parameter on <input type=file>, with additional API
to get metadata

... main question is about using media type parameter

... not the cleanest approach

... Android 3.0 has already shipped with this

ACTION-317?

<trackbot> ACTION-317 -- Robin Berjon to ping Andrei about using @role instead
of mime parameters -- due 2010-12-22 -- OPEN

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

ISSUE-105?

<trackbot> ISSUE-105 -- Should the capture hint in HTML Media Capture be
specified through a MIME parameter? -- open

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

<darobin> <input type='file' accept='image/*;capture=camera'/>

<darobin> <input type='file' accept='image/*' role='capture-camera'/>

<fjh> robin notes 2nd might be cleaner

<fjh> robin notes this matches android

<fjh> ScribeNick: fjh

<scribe> Scribenick: dom

<fjh> scribenick: robin

<dom> scribenick: dom

Robin: pros and cons:

... using media type parameter is a bit ugly, since it's not a valid parameter

... someone could define capture=camera as a valid parameter for one of the
covered media types

... also requires to modify HTML5 allowed syntax

... a separate attribute would be cleaner

... also attribute is stylable with CSS; harder to do with media type
parameter

[robin notes that input[accept=~'capture=camera'] might do for CSS, but has
its limitaitons

<darobin> CSS matching input[accept=~'capture=camera']

robin: with role attribute, you can do input[accept|='capture-camera'] would
work with specific boundaries

<fjh> rssagent, generate minutes

robin: also, role attribute offers transition path

<fjh> zakim who is here?

<scribe> **ACTION:** Dom to draft HTML Media Capture with role attribute
[recorded in [http://www.w3.org/2011/03/15-dap-minutes.html#action03][34]]

<trackbot> Created ACTION-351 - Draft HTML Media Capture with role attribute
[on Dominique Hazaël-Massieux - due 2011-03-22].

ACTION-318?

<trackbot> ACTION-318 -- Robin Berjon to ping WAI about using @role for
capture -- due 2010-12-22 -- OPEN

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

-> [http://dev.w3.org/2009/dap/camera/Overview-API.html][36] Media Capture API

### Media Capture API

-> [http://public.wholesaleappcommunity.com/redmine/embedded/wac2pubrev/device
apis/camera.html][37] WAC Camera API

Robin: unclear if there is much traction for media capture API

... sits between <device> and HTML Media Capture

Dom: the API could probably be built upon <device>, but would need double-
checking (e.g. in terms of user experience)

Robin: I'll ask the mailing list to see what interest there is in continuing
work on a snapshot-based approach

... vs stream-based as <device> would provide

-> [http://www.whatwg.org/specs/web-apps/current-work/multipage/index.html
#auto-toc-9][38] WhatWG HTML and <device> element

### RTC web

<darobin> [RTC draft][39]

-> [http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html
#video-conferencing-and-peer-to-peer-communication][40] <device> element in
Latest HTML WhatWG version

Robin: around real time communications in the browser, two sides: IETF and W3C

... rough agreement is that IETF does protocol, and W3C matching APIs

... cross-organization coordination can be painful, but good working
relationship between IETF and W3C

... it's good that the split been agreed from the beginning

... IETF-side, goal is to re-use existing protocols as much as possible

... IETF requirements has use cases, e.g. for direct p2p Facebook chat

... one thing the be aware: the eternal video codec issue

... will hit the same issues as what happened with HTML5 and SVG video

... group is hoping to find mandatory codec, although not sure how realistic
that is

dom: requirement for direct interop more important here since doesn't involve
servers, only users

robin: ietf document has also a rough proposal for the API

... based on a <session> element under a <video> element

... similar to <device>, but more specific

... Anybody planning to participate in Web RTC?

Frederick: Nokia will probably participate

Robin: end of AC review is this Friday

Kangchan: goal is to re-use existing protocols as much as possible

... might there be problems with protocols optimization?

<darobin> **ACTION:** Robin to find out where <device> went [recorded in
[http://www.w3.org/2011/03/15-dap-minutes.html#action04][41]]

<trackbot> Created ACTION-352 - Find out where <device> went [on Robin Berjon
- due 2011-03-22].

-> [http://html5.org/tools/web-apps-tracker?from=5944&to=5945][42] <device>
element removed from WhatWG HTML

<fjh> speech api

<darobin> [HTML Speech API][43]

"Completely revamp how peer-to-peer networking works (and some minor typo
fixes in other parts of the spec). This is only a second draft, and therefore
this feature will likely evolve a lot over the coming months. Detailed
responses to feedback on the topic will be sent out soon."

### Web Introducer

-> [http://web-send.org/introducer/][26] Web Introducer proposal

<scribe> **ACTION:** Dom to check with Claes re Web introducer contributors
and bringing it to DAP [recorded in [http://www.w3.org/2011/03/15-dap-
minutes.html#action05][44]]

<trackbot> Created ACTION-353 - Check with Claes re Web introducer
contributors and bringing it to DAP [on Dominique Hazaël-Massieux - due
2011-03-22].

<fjh> Web Introducer style needs to be changed to not be misleading about
status

-> [http://customer.web-send.org/][45] Web Introducer prototype

close ACTION-313

<trackbot> ACTION-313 Send feedback on media gallery use cases closed

ACTION-314?

<trackbot> ACTION-314 -- Anssi Kostiainen to react on media gallery use cases
-- due 2010-12-15 -- OPEN

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

### Issue Review

<fjh> ISSUE-2?

<trackbot> ISSUE-2 -- Error handling style -- open

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

<fjh> ISSUE-2: good javascript coding

<trackbot> ISSUE-2 Error handling style notes added

<fjh> ISSUE-2 closed

<trackbot> ISSUE-2 Error handling style closed

<fjh> ISSUE-18?

<trackbot> ISSUE-18 -- Determine security policy starting points for review
and comparison -- open

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

<fjh> ISSUE-18: closed

<trackbot> ISSUE-18 Determine security policy starting points for review and
comparison notes added

<fjh> ISSUE-21?

<trackbot> ISSUE-21 -- Is policy/access control on both features and device
capabilities needed, do all submissions include both of these -- open

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

close ISSUE-18

<trackbot> ISSUE-18 Determine security policy starting points for review and
comparison closed

close ISSUE-2

<trackbot> ISSUE-2 Error handling style closed

<fjh> ISSUE-21: closed

<trackbot> ISSUE-21 Is policy/access control on both features and device
capabilities needed, do all submissions include both of these notes added

close ISSUE-21

<trackbot> ISSUE-21 Is policy/access control on both features and device
capabilities needed, do all submissions include both of these closed

<fjh> ISSUE-23?

<trackbot> ISSUE-23 -- Should policy framework support notion of default
policy? -- open

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

<fjh> ISSUE-23 closed

<trackbot> ISSUE-23 Should policy framework support notion of default policy?
closed

close ISSUE-23

<trackbot> ISSUE-23 Should policy framework support notion of default policy?
closed

<fjh> ISSUE-23?

<trackbot> ISSUE-23 -- Should policy framework support notion of default
policy? -- closed

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

<fjh> ISSUE-25?

<trackbot> ISSUE-25 -- Cross-module dependency and impact on policy -- open

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

<fjh> ISSUE-33?

<trackbot> ISSUE-33 -- Persisting state of user decisions -- open

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

<fjh> ISSUE-25: cross api dependence and policy

<trackbot> ISSUE-25 Cross-module dependency and impact on policy notes added

<fjh> close ISSUE-25

<trackbot> ISSUE-25 Cross-module dependency and impact on policy closed

<fjh> ISSUE-33: UI issue, added note to API draft

<trackbot> ISSUE-33 Persisting state of user decisions notes added

[http://www.w3.org/2009/dap/wiki/ApiCheckList#Privacy_.26_Security_Considerati
ons][53]

<darobin> [][54]

<fjh> Note: see privacy note in [http://dev.w3.org/2009/dap/system-info
/#privacy-considerations-for-implementors-of-the-system-info-api][54]

ISSUE-33: added requirement of revokation capaibilites to API Checklist [http:
//www.w3.org/2009/dap/wiki/ApiCheckList#Privacy_.26_Security_Considerations][5
3]

<trackbot> ISSUE-33 Persisting state of user decisions notes added

<fjh> close ISSUE-33

<trackbot> ISSUE-33 Persisting state of user decisions closed

<fjh> ISSUE-34?

<trackbot> ISSUE-34 -- Protecting data versus protecting apis -- open

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

<fjh> ISSUE-34: focus now is privacy by design, not policy framework

<trackbot> ISSUE-34 Protecting data versus protecting apis notes added

ISSUE-34: WTF??

<trackbot> ISSUE-34 Protecting data versus protecting apis notes added

close ISSUE-34

<trackbot> ISSUE-34 Protecting data versus protecting apis closed

<fjh> ISSUE-35?

<trackbot> ISSUE-35 -- How to handle malformed policies, policy validity and
intentional abuse of policy? How is policy deadlock handled? e.g. Only dial
+39 numbers + Never dial +39 numbers -- open

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

close ISSUE-35

<trackbot> ISSUE-35 How to handle malformed policies, policy validity and
intentional abuse of policy? How is policy deadlock handled? e.g. Only dial
+39 numbers + Never dial +39 numbers closed

<fjh> ISSUE-58: fjh did this

<trackbot> ISSUE-58 Provide link to section of document producing text that
includes section title and section number notes added

<scribe> **ACTION:** Dom to look for a new place for hosting ReSpec Issues
[recorded in [http://www.w3.org/2011/03/15-dap-minutes.html#action06][57]]

<trackbot> Created ACTION-354 - Look for a new place for hosting ReSpec Issues
[on Dominique Hazaël-Massieux - due 2011-03-22].

<fjh> close ISSUE-58

<trackbot> ISSUE-58 Provide link to section of document producing text that
includes section title and section number closed

<darobin> close ISSUE-68

<trackbot> ISSUE-68 confusing indentation of WebIDL blocks in ReSpec closed

<fjh> ISSUE-78?

<trackbot> ISSUE-78 -- Capture has a minimisation problem with EXIF data (e.g.
it could be Geotagged) -- open

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

<fjh> ACTION-251?

<trackbot> ACTION-251 -- John Morris to review privacy text related to
ISSUE-78 for capture -- due 2010-10-20 -- OPEN

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

<darobin> close ISSUE-75

<trackbot> ISSUE-75 ReSpec should support non-RecTrack override closed

<fjh> 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][60]

<fjh> 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][61]

<fjh> ISSUE-82?

<trackbot> ISSUE-82 -- Should Communication Logs be part of the messaging API
or part of a telephony API? -- open

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

ISSUE-82: we're dropping work on commlog api in new charter

<trackbot> ISSUE-82 Should Communication Logs be part of the messaging API or
part of a telephony API? notes added

<fjh> ISSUE-82: part chartering discussionat this f2f

<trackbot> ISSUE-82 Should Communication Logs be part of the messaging API or
part of a telephony API? notes added

<fjh> ISSUE-82 closed

<trackbot> ISSUE-82 Should Communication Logs be part of the messaging API or
part of a telephony API? closed

<fjh> ISSUE-87?

<trackbot> ISSUE-87 -- Degree of ruleset transmission with API calls, how
often, which -- open

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

<fjh> ruleset issues stay open

<fjh> ISSUE-90?

<trackbot> ISSUE-90 -- Create privacy best practices document for web site
developer -- open

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

<scribe> **ACTION:** Frederick to make first draft of privacy best practices
[recorded in [http://www.w3.org/2011/03/15-dap-minutes.html#action07][65]]

<trackbot> Created ACTION-355 - Make first draft of privacy best practices [on
Frederick Hirsch - due 2011-03-22].

<fjh> ISSUE-90: need action, not issue

<trackbot> ISSUE-90 Create privacy best practices document for web site
developer notes added

<fjh> ISSUE-90 closed

<trackbot> ISSUE-90 Create privacy best practices document for web site
developer closed

ISSUE-90: not an issue, see ACTION-355

<trackbot> ISSUE-90 Create privacy best practices document for web site
developer notes added

ISSUE-91?

<trackbot> ISSUE-91 -- Be clear to distinguish site (service) privacy policy
versus included location provider policy etc -- open

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

<fjh> **ACTION:** fjh to create initial editors draft for privacy best
practices, ISSUE-90 [recorded in [http://www.w3.org/2011/03/15-dap-
minutes.html#action08][67]]

<trackbot> Created ACTION-356 - Create initial editors draft for privacy best
practices, ISSUE-90 [on Frederick Hirsch - due 2011-03-22].

close ACTION-356

<trackbot> ACTION-356 Create initial editors draft for privacy best practices,
ISSUE-90 closed

ACTION-356: dup of ACTION-355

<trackbot> ACTION-356 Create initial editors draft for privacy best practices,
ISSUE-90 notes added

<fjh> ISSUE-92?

<trackbot> ISSUE-92 -- Sysinfo, permissions for get vs monitor; -- open

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

ISSUE-91: might be relevant to Web introducer? otherwise probably not relevant
to DAP

<trackbot> ISSUE-91 Be clear to distinguish site (service) privacy policy
versus included location provider policy etc notes added

<fjh> ACTION-248?

<trackbot> ACTION-248 -- John Morris to provide a proposal relevant to
ISSUE-92, sysinfo privacy prompts for operators get vs watch -- due 2010-08-11
-- CLOSED

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

<fjh> ISSUE-91 closed

<trackbot> ISSUE-91 Be clear to distinguish site (service) privacy policy
versus included location provider policy etc closed

<darobin> issue-94?

<trackbot> ISSUE-94 -- How do Powerbox and Policy interact and integrate --
open

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

<fjh> ISSUE-94?

<trackbot> ISSUE-94 -- How do Powerbox and Policy interact and integrate --
open

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

<fjh> ISSUE-94 closed

<trackbot> ISSUE-94 How do Powerbox and Policy interact and integrate closed

<fjh> ISSUE-95?

<trackbot> ISSUE-95 -- Different regulatory environments and relationship to
privacy and rulesets -- open

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

ISSUE-92: added note on get vs watch in API checklist [http://www.w3.org/2009/
dap/wiki/ApiCheckList#Privacy_.26_Security_Considerations][53]

<trackbot> ISSUE-92 Sysinfo, permissions for get vs monitor; notes added

<fjh> ISSUE-96?

<trackbot> ISSUE-96 -- Some properties of sysinfo are static so monitor might
not make sense -- open

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

<fjh> ISSUE-101?

<trackbot> ISSUE-101 -- Should we define a default audio (video?) codec for
capture? if so, which? -- open

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

ISSUE-96: probably going to be moot if we reshape sysinfo; to be revisited

<trackbot> ISSUE-96 Some properties of sysinfo are static so monitor might not
make sense notes added

<fjh> ISSUE-101: hopefully codec will be defined by rtw

<trackbot> ISSUE-101 Should we define a default audio (video?) codec for
capture? if so, which? notes added

<fjh> ISSUE-104 closed

<trackbot> ISSUE-104 Find a better name for "trusted environments" closed

ISSUE-101: rtw = Web RTC

<trackbot> ISSUE-101 Should we define a default audio (video?) codec for
capture? if so, which? notes added

<fjh> ISSUE-105?

<trackbot> ISSUE-105 -- Should the capture hint in HTML Media Capture be
specified through a MIME parameter? -- open

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

<fjh> ACTION-317?

<trackbot> ACTION-317 -- Robin Berjon to ping Andrei about using @role instead
of mime parameters -- due 2010-12-22 -- OPEN

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

<fjh> ACTION-381?

<trackbot> ACTION-381 does not exist

<fjh> ACTION-351?

<trackbot> ACTION-351 -- Dominique Hazaël-Massieux to draft HTML Media Capture
with role attribute -- due 2011-03-22 -- OPEN

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

<fjh> 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][75]

<fjh> ISSUE-106: proposal from Rich

<trackbot> ISSUE-106 Does Contacts API having a timezone field make sense,
should it be utfOffset or utcOffset and tz to better match vCard? notes added

ISSUE-106: Resolved as implemented in [http://dev.w3.org/2009/dap/contacts
/#widl-Contact-timezone][76]

<trackbot> ISSUE-106 Does Contacts API having a timezone field make sense,
should it be utfOffset or utcOffset and tz to better match vCard? notes added

<fjh> close 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? closed

<fjh> ISSUE-107?

<trackbot> ISSUE-107 -- How to better integrate URIs schemes in Messaging API
-- open

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

<fjh> ACTION-348?

<trackbot> ACTION-348 -- Dominique Hazaël-Massieux to send concrete proposal
for navigator.sendMessage with URI scheme -- due 2011-03-16 -- PENDINGREVIEW

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

ISSUE-107: new proposal on the table need review from Messaging API editors

<trackbot> ISSUE-107 How to better integrate URIs schemes in Messaging API
notes added

<fjh> Now 14 issues open

<fjh> 6 Respec, leaving 8 open issues

ISSUE-106: resolution is that timezone attribute takes Timezone identifier,
can take utf offset but not recommended

<trackbot> ISSUE-106 Does Contacts API having a timezone field make sense,
should it be utfOffset or utcOffset and tz to better match vCard? notes added

### Recess

## Summary of Action Items

**[NEW]** **ACTION:** Dom to check with Claes re Web introducer contributors
and bringing it to DAP [recorded in [http://www.w3.org/2011/03/15-dap-
minutes.html#action05][44]]

**[NEW]** **ACTION:** Dom to draft HTML Media Capture with role attribute
[recorded in [http://www.w3.org/2011/03/15-dap-minutes.html#action03][34]]

**[NEW]** **ACTION:** Dom to figure out what are the secrets and evil plans
from Thomas on privacy follow-up [recorded in [http://www.w3.org/2011/03/15
-dap-minutes.html#action01][21]]

**[NEW]** **ACTION:** Dom to look for a new place for hosting ReSpec Issues
[recorded in [http://www.w3.org/2011/03/15-dap-minutes.html#action06][57]]

**[NEW]** **ACTION:** fjh to create initial editors draft for privacy best
practices, ISSUE-90 [recorded in [http://www.w3.org/2011/03/15-dap-
minutes.html#action08][67]]

**[NEW]** **ACTION:** Frederick to make first draft of privacy best practices
[recorded in [http://www.w3.org/2011/03/15-dap-minutes.html#action07][65]]

**[NEW]** **ACTION:** Robin to find a better wording for intents-based
application launcher [recorded in [http://www.w3.org/2011/03/15-dap-
minutes.html#action02][24]]

**[NEW]** **ACTION:** Robin to find out where <device> went [recorded in
[http://www.w3.org/2011/03/15-dap-minutes.html#action04][41]]


[End of minutes]

* * *

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

$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/2009/dap/wiki/F2F_Agenda_15,_16,_18_March_2011,_Seoul

   [4]: http://www.w3.org/2011/03/15-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #ActionSummary

   [16]: http://www.w3.org/2011/Talks/dhm-dap-recharter/

   [17]: http://www.w3.org/2009/05/DeviceAPICharter

   [18]: http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F200
9%2F05%2FDeviceAPICharter&doc2=http%3A%2F%2Fwww.w3.org%2F2010%2F11%2FDeviceAPI
Charter.html

   [19]: http://www.w3.org/2010/11/DeviceAPICharter.html

   [20]: http://www.w3.org/2011/track-privacy/

   [21]: http://www.w3.org/2011/03/15-dap-minutes.html#action01

   [22]: http://paulrouget.com/e/nativecontrols

   [23]: http://lists.w3.org/Archives/Public/public-device-
apis/2011Mar/0085.html

   [24]: http://www.w3.org/2011/03/15-dap-minutes.html#action02

   [25]: http://webintents.appspot.com/

   [26]: http://web-send.org/introducer/

   [27]: http://www.w3.org/2010/11/web-and-tv/

   [28]: http://open311.org/

   [29]: http://webinos.org/about-webinos

   [30]: http://www.w3c.or.kr/DAP2011/

   [31]: http://dev.w3.org/2009/dap/camera/

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

   [33]: http://www.w3.org/2009/dap/track/issues/105

   [34]: http://www.w3.org/2011/03/15-dap-minutes.html#action03

   [35]: http://www.w3.org/2009/dap/track/actions/318

   [36]: http://dev.w3.org/2009/dap/camera/Overview-API.html

   [37]: http://public.wholesaleappcommunity.com/redmine/embedded/wac2pubrev/d
eviceapis/camera.html

   [38]: http://www.whatwg.org/specs/web-apps/current-
work/multipage/index.html#auto-toc-9

   [39]: http://tools.ietf.org/html/draft-jennings-rtcweb-api-00

   [40]: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html
#video-conferencing-and-peer-to-peer-communication

   [41]: http://www.w3.org/2011/03/15-dap-minutes.html#action04

   [42]: http://html5.org/tools/web-apps-tracker?from=5944&to=5945

   [43]: http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001
/microsoft-api-draft-final.html#capture_api_extensions

   [44]: http://www.w3.org/2011/03/15-dap-minutes.html#action05

   [45]: http://customer.web-send.org/

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

   [47]: http://www.w3.org/2009/dap/track/issues/2

   [48]: http://www.w3.org/2009/dap/track/issues/18

   [49]: http://www.w3.org/2009/dap/track/issues/21

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

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

   [52]: http://www.w3.org/2009/dap/track/issues/33

   [53]: http://www.w3.org/2009/dap/wiki/ApiCheckList#Privacy_.26_Security_Con
siderations

   [54]: http://dev.w3.org/2009/dap/system-info/#privacy-considerations-for-
implementors-of-the-system-info-api

   [55]: http://www.w3.org/2009/dap/track/issues/34

   [56]: http://www.w3.org/2009/dap/track/issues/35

   [57]: http://www.w3.org/2011/03/15-dap-minutes.html#action06

   [58]: http://www.w3.org/2009/dap/track/issues/78

   [59]: http://www.w3.org/2009/dap/track/actions/251

   [60]: http://www.w3.org/2009/dap/track/issues/81

   [61]: http://www.w3.org/2009/dap/track/actions/297

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

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

   [64]: http://www.w3.org/2009/dap/track/issues/90

   [65]: http://www.w3.org/2011/03/15-dap-minutes.html#action07

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

   [67]: http://www.w3.org/2011/03/15-dap-minutes.html#action08

   [68]: http://www.w3.org/2009/dap/track/issues/92

   [69]: http://www.w3.org/2009/dap/track/actions/248

   [70]: http://www.w3.org/2009/dap/track/issues/94

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

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

   [73]: http://www.w3.org/2009/dap/track/issues/101

   [74]: http://www.w3.org/2009/dap/track/actions/351

   [75]: http://www.w3.org/2009/dap/track/issues/106

   [76]: http://dev.w3.org/2009/dap/contacts/#widl-Contact-timezone

   [77]: http://www.w3.org/2009/dap/track/issues/107

   [78]: http://www.w3.org/2009/dap/track/actions/348

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

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