See also: IRC log
<trackbot> Date: 14 March 2011
<Suresh> I don't hear you!
<marengo> Scribe: Marco Marengo
<marengo> scribenick: marengo
fjh: we'll start with introductions
<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
<dom> RESOLUTION: Happy birthday Robin
<dom> http://www.w3.org/2011/Talks/dhm-dap-recharter/
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
dom: 2) tightening of the scope of the APIs
... 3) clarification on security model
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
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
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]
<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
<dom> http://paulrouget.com/e/nativecontrols
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
<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]
<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/
<dom> WebIntents
<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
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
<dom> Web Introducer
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/
<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
<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/
<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
<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://dev.w3.org/2009/dap/camera/ 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
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
<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]
<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
-> http://dev.w3.org/2009/dap/camera/Overview-API.html Media Capture API
-> http://public.wholesaleappcommunity.com/redmine/embedded/wac2pubrev/deviceapis/camera.html 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 WhatWG HTML and <device> element
<darobin> RTC draft
-> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication <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]
<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 <device> element removed from WhatWG HTML
<fjh> speech api
<darobin> HTML Speech API
"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."
-> http://web-send.org/introducer/ 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]
<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/ 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
<fjh> ISSUE-2?
<trackbot> ISSUE-2 -- Error handling style -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/2
<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
<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
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
<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
<fjh> ISSUE-25?
<trackbot> ISSUE-25 -- Cross-module dependency and impact on policy -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/25
<fjh> ISSUE-33?
<trackbot> ISSUE-33 -- Persisting state of user decisions -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/33
<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_Considerations
<fjh> Note: see privacy note in http://dev.w3.org/2009/dap/system-info/#privacy-considerations-for-implementors-of-the-system-info-api
ISSUE-33: added requirement of revokation capaibilites to API Checklist http://www.w3.org/2009/dap/wiki/ApiCheckList#Privacy_.26_Security_Considerations
<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
<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
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]
<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
<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
<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
<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
<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
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
<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
<scribe> ACTION: Frederick to make first draft of privacy best practices [recorded in http://www.w3.org/2011/03/15-dap-minutes.html#action07]
<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
<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]
<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
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
<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
<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
<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
ISSUE-92: added note on get vs watch in API checklist http://www.w3.org/2009/dap/wiki/ApiCheckList#Privacy_.26_Security_Considerations
<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
<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
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
<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
<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
<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
<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
<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
<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
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