See also: IRC log
<trackbot> Date: 19 January 2011
<hta> (visitor)
<darobin> Zakim: ??P13 is me
<fjh> ScribeNick: jmorris
<fjh> Seoul F2F logistics, http://lists.w3.org/Archives/Member/member-device-apis/2011Jan/0002.html (Kangchan)
<fjh> 2b) "Device API Access Control Use Cases and Requirements" update published, http://www.w3.org/TR/2011/WD-dap-policy-reqs-20110118/
<dom> ACTION: Dom to create a registration form for Seoul F2F [recorded in http://www.w3.org/2011/01/19-dap-minutes.html#action01]
<trackbot> Created ACTION-326 - Create a registration form for Seoul F2F [on Dominique Hazaël-Massieux - due 2011-01-26].
<fjh> HTML5 logo, http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0062.html
<darobin> http://www.w3.org/html/logo/#the-technology
<Suresh> It's a bit confusing...the logo says HTML5 but faqs say the family of technologies SVG, CSS
<AnssiK> http://www.w3.org/html/logo/badge/html5-badge-h-device.png
<fjh> Approve 12 January minutes
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/att-0035/minutes-2011-01-12.html
RESOLUTION: Minutes from 12 January 2011 approved
<fjh> ISSUE-100?
<trackbot> ISSUE-100 -- Subscring to new messages should be done with filters and data minimization -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/100
fjh: let's talk about ISSUE-100
<darobin> ISSUE-100?
<trackbot> ISSUE-100 -- Subscring to new messages should be done with filters and data minimization -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/100
<dom> MEssaging API Editors draft
fjh: thinks we can close this issue
dom: we should perhaps postpone issues because we are not addressing subscription
<darobin> ISSUE-103?
<trackbot> ISSUE-103 -- Does the messaging API fit outside of contained environments? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/103
RESOLUTION: postpone ISSUE-100
<fjh> ISSUE-103?
<trackbot> ISSUE-103 -- Does the messaging API fit outside of contained environments? -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/103
darobin: should we also close ISSUE-103?
... it was opened during F2F
... about whether messaging would work outside of "contained environments"
RESOLUTION: close ISSUE-103
<darobin> close ISSUE-103
<trackbot> ISSUE-103 Does the messaging API fit outside of contained environments? closed
fjh: are we publishing update or last call, assuming update?
dom: let's go with update
darobin: more comfortable with review rather than last call
<darobin> PROPOSED RESOLUTION: publish a heartbeat WD of Messaging
RESOLUTION: publish a heartbeat of Messaging API draft
<darobin> ACTION: Robin to prepare Messaging for publication [recorded in http://www.w3.org/2011/01/19-dap-minutes.html#action02]
<trackbot> Created ACTION-327 - Prepare Messaging for publication [on Robin Berjon - due 2011-01-26].
darobin: anything to report on call?
fjh: we should do Anssi's suggestion on referencing vcard3 and noting vcard4
Suresh: trying to understand what we take out of discussion
... not seen anything from Richard
... summarize what I have been saying on list
... discussion about writeback ? API
... two ways to do it, two ways, download and save, also direct API
... download and save option - no objection to it
... it is not the best solution - a midlevel solution
<AnssiK> latest update to Contacts API was made on Fri Jan 14: http://dev.w3.org/cvsweb/2009/dap/contacts/Overview.html
Suresh: latest proposal from Richard is to take up contactWriter
... need to continue work on Writer API
<dom> (I think we should move section 8 "adding and updating contacts" as an informative appendix, and move ahead with an update to the contacts api)
Suresh: I do not have problem with download and save, but it is not the only option
<dom> (I think the Abstract shouldn't go into that level of details anyway)
<fjh> anssi re references, http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0059.html
Suresh: state that this is an alternate option to save back into address book
fjh: do we need a volunteer on this?
Suresh: Richard is editor
... he prefers a direct API
fjh: we are at a standstill on list on this
... wondering about writer, and how it will be done
Suresh: the write option came back into draft
... I would make writer API normative and include this option as an additional option
... we could include download and save in a writer API
darobin: steps forward?
... I wonder if softening the language in the abstract might help?
... rather than saying "normative guideline" soften it
<Zakim> dom, you wanted to suggest edits
dom: will propose a sentence for abstract to revise phrase about negating the need
<darobin> +1
dom: think that appendix is best way to present writer
... I will make the changes
<Suresh> +1
<fjh> +1
<darobin> ACTION: Dom to edit the contacts to address concerns with the way writing is described , moving writing to appendix and updating abstract [recorded in http://www.w3.org/2011/01/19-dap-minutes.html#action03]
<trackbot> Created ACTION-328 - Edit the contacts to address concerns with the way writing is described, moving writing to informative appendix and updating abstract [on Dominique Hazaël-Massieux - due 2011-01-26].
brian_sullivan: current draft does not contain programatic saving
... it can do a "save as" after which the user can import
... it might directly trigger import
... no devices on market would allow this approach
... thinks programatic approach is still needed
... okay with appendix approach, but not real solution
darobin: you might not need a file system
... there is a media type attached to content
... browser might prompt you to download or open in application
Suresh: this may not work across 100%
... but still not as clean as programatic API
<dom> I've brought the proposed changes in ACTION-328 to http://dev.w3.org/2009/dap/contacts/
darobin: this functionality exists already
<dom> ACTION-328: http://dev.w3.org/cvsweb/2009/dap/contacts/Overview.html.diff?r1=1.104&r2=1.108&f=h
<trackbot> ACTION-328 Edit the contacts to address concerns with the way writing is described notes added
bryan_sullivan: we don't want user to have to go through extra hoops
... to get data into contacts application
darobin: there is text that allows this in the document
... in section 8
<darobin> ISSUE-86?
<trackbot> ISSUE-86 -- Privacy issue about sharing other users contact information from own address book -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/86
darobin: I propose we go ahead with dom's edits
<fjh> for ISSUE-86, I suggest following sentence be added as new paragraph at end of section 3.1:
<fjh> "Note that even if a user gives permission to share their contact information this can have privacy implications for those parties whose contacts are shared, as they may not wish such sharing to occur. This should be considered by web services when requesting and using such information."
<AnssiK> http://dev.w3.org/html5/spec/timers.html#dom-navigator-registercontenthandler
Suresh and anssi discussing vcard support
<AnssiK> http://microformats.org/wiki/vcard-implementations
Suresh: no sure which platforms support which version of vcard
darobin: if everyone supports vcard?
... it is hard to implement
<dom> +1 on "supported contact formats" to be impossible (or least very difficult) to support
<AnssiK> Suresh: did you mean you need a get conterpart for navigator.registerContentHandler()?
darobin: this requires user agent to know what applications are installed - this is very hard to support
Suresh, though API, method to query underlying formats
scribe: not application that is registered for it
<darobin> +1 to dom
<fjh> I think the crux of this argument from Suresh is that a programmatic API can be format agnostic thus obviating concern about which formats are supported
<Zakim> dom, you wanted to say this relates to Application Launcher discussions, suggest moving to list
<dom> (I think the convenience method could be tackled by a Javascript library)
<AnssiK> +1 to dom, I sent some pointers to the list regarding this one
<darobin> (yes, and better than a browser ever could do it)
AnssiK: trying to determine if Suresh wants a get
dom: done edits to contacts, and moving to appendix
<darobin> +1 to dom
dom: more generally, if anyone wants to propose specific prohibitions, better on mailing list
<darobin> ISSUE-86?
<trackbot> ISSUE-86 -- Privacy issue about sharing other users contact information from own address book -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/86
<darobin> "Note that even if a user gives permission to share their contact information this can have privacy implications for those parties whose contacts are shared, as they may not wish such sharing to occur. This should be considered by web services when requesting and using such information."
fjh: put in list:
"Note that even if a user gives permission to share their contact information this can have privacy implications for those parties whose contacts are shared, as they may not wish such sharing to occur. This should be considered by web services when requesting and using such information."
<fjh> put "serious" in front of "privacy implications"
jmorris: strengthen language
fjh: can't prohibit it and best is to warn about it
darobin: no need for resolution
<darobin> close ISSUE-86
<trackbot> ISSUE-86 Privacy issue about sharing other users contact information from own address book closed
<dom> ISSUE-86: we added some informative text in that regard to the document
<trackbot> ISSUE-86 Privacy issue about sharing other users contact information from own address book notes added
<darobin> ISSUE-99?
<trackbot> ISSUE-99 -- Integration of Contacts API in the DOM (e.g. through <input type=contacts>) -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/99
darobin: ISSUE-99 may not be solved now
... perhaps leave it open
fjh: this is a new feature
<darobin> postpone ISSUE-99
dom: mark it as postponed
RESOLUTION: postpone ISSUE-99
dom: another issue - remark about time zone
... offset to GMT
<dom> "The value contains the time zone of this Contact as an offset from UTC.
<dom> The value must be specified as a positive or negative difference from the UTC in units of hours and minutes (i.e. +hh:mm). Example, by specifying +05:30 indicates the Contact is associated with a current time zone of GMT+05:30. "
<dom> http://dev.w3.org/2009/dap/contacts/#widl-Contact-timezone
darobin: we discussed a solution?
dom: did not converge on solution
... no one proposed concrete solution
<Suresh> Dom, i looked at your updates to Contacts API quickly - in the appendix (non-normative section) we are still using normative language like SHOULD, and not sure if this right. Perhaps lower casing it is better
darobin: we should have an ISSUE about this
... presumably this is a mapping from vcard?
<dom> Issue about timezone encoding in Contacts API
Suresh: not sure this is a vcard mapping
<hta> hm. if timezone is represented internally as a real timezone, and exposed here as a fixed UTC offset, reading it and storing it back will lose info.
darobin: vcard says this an offset from UTC
... not sure we can fix it if it is wrong in vcard
<dom> UTC-OFFSET field in vCard
dom: perhaps we should rename "timezone" to "UTC offset"
... to be consistent with vcard
darobin: Any objections to renaming this?
<darobin> PROPOSED RESOLUTION: rename the timezone field to utcOffset to match vCard better
<hta> section 3.4.1 of RFC 2426 has a timezone.
<hta> (TZ)
<hta> sorry, pushed the wrong button.
fjh: harold, what is question?
hta: RFC has two fields
... but one field undefined
Discussion of whether utcOffset would be stored someone?
fjh: sounds like we are not ready to go to last call
... if we are fixing this on the fly
Suresh: ID is read only
darobin: open issue and discuss on list
... investigate having two fields:
... utcOffset and tz
... will open issue
<darobin> ISSUE: Does having a timezone field make sense, should it be utfOffset or utcOffset and tz to better match vCard
<trackbot> Created ISSUE-106 - Does having a timezone field make sense, should it be utfOffset or utcOffset and tz to better match vCard ; please complete additional details at http://www.w3.org/2009/dap/track/issues/106/edit .
darobin: we cannot move ahead with contacts but making progress
<AnssiK> vCard 4.0 draft proposes some changes to TZ, e.g. TZ property now has text / uri value: http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev
darobin: solve ISSUE-106 and them move to last call
<darobin> http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0057.html -> HTML+Speech feedback
darobin: Context - a coordination call last friday with hypertext WG
... there is interest in interacting with audio streams
... they want to know where we are going with media caption API
... how this relates to device functionality
... not sure how to tackle this e-mail
... perhaps we need an ACTION to respond to this e-mail
... e-mail is way to start conversation with group
<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
dom: does ACTION-300 relate?
darobin: do we ask Claes to do this?
dom: chairs should have own action for coordination
<fjh> ACTION-300: may relate to http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0057.html HTML+Speech feedback as well
<trackbot> ACTION-300 Start working on use cases and requirements for video/audio conference à la <device> element notes added
fjh: will add note to 300
<darobin> ACTION: Robin to maintain coordination with HTML+Speech on http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0057.html; include Claes in the discussion [recorded in http://www.w3.org/2011/01/19-dap-minutes.html#action04]
<trackbot> Created ACTION-329 - Maintain coordination with HTML+Speech on http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0057.html; include Claes in the discussion [on Robin Berjon - due 2011-01-26].
darobin: do you know when real time web WG will start?
dom: not sure it will, but if it does, early march
<darobin> http://www.w3.org/mid/AANLkTimokqOO_54OTij4ysdO6Dh-JmBJWLgQjYmnsZKH@mail.gmail.com -> Bryan's message
bryan_sullivan: I was catching up on sysinfo
... 2 or 3 e-mails with extensive comments
... I made a stab at issues, but some I don't know what to do on
... issues have not come to head on list
<hta> have to drop off now, thanks for letting me listen in. leaving chat open.
<dom> Note that we're thinking of removing Network from sysinfo, per ACTION-294
bryan_sullivan: I sent long e-mail to list
... I can break into separate threads
... working on easy things first, and break complicated issues into separate discussions
<fjh> ISSUE-102?
<trackbot> ISSUE-102 -- Sysinfo asynchronous calls needs to be expressed in terms of events loop -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/102
<fjh> ISSUE-102: plan to handle with core device specification
<trackbot> ISSUE-102 Sysinfo asynchronous calls needs to be expressed in terms of events loop notes added
<dom> [see also how Contacts API refers to this http://dev.w3.org/2009/dap/contacts/#terminology ]
bryan_sullivan: on power issues, did not see resolution
... on list
<fjh> ISSUE-102 closed
<trackbot> ISSUE-102 Sysinfo asynchronous calls needs to be expressed in terms of events loop closed
bryan_sullivan: I will respond on power e-mail
<fjh> ISSUE-64?
<trackbot> ISSUE-64 -- "Generic" sensors may permit discovering sensitive information -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/64
fjh: we may need to do more on ISSUE-64
jmorris: will look at sysinfo privacy language
<fjh> ACTION: jmorris to review SysInfo privacy considerations section, and ISSUE-64 on "generic" [recorded in http://www.w3.org/2011/01/19-dap-minutes.html#action05]
<trackbot> Created ACTION-330 - Review SysInfo privacy considerations section, and ISSUE-64 on "generic" [on John Morris - due 2011-01-26].
<dom> (I think the goal of "generic sensors" is extensibility)
<dom> "Generic sensors, e.g., discovery of nearby wireless networks, MAC addresses of access points, etc may permit localizing the device (and its user). Access control policies for such sensors need to be aligned with access to the more sensitive information that can be inferred."
jmorris: I will look at spec
<fjh> ACTION: fjh to review ISSUE-64 [recorded in http://www.w3.org/2011/01/19-dap-minutes.html#action06]
<trackbot> Created ACTION-331 - Review ISSUE-64 [on Frederick Hirsch - due 2011-01-26].
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0067.html
<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 - both are concerns - both protecting API and data
<dom> I don't think this is an issue; i.e. it is not a question one can give an answer
dom: current issue is not really phrased in term of a question to be resolved
fjh: in issue title, "versus" is wrong word
... want to see what action we can take to address the concern
... do we need to mention access control, and if so where?
... can we publish ruleset proposal as draft
... should we get broader feedback on issue
<Suresh> it might be a good idea to reference the permissions and access control drafts from the API specs?
dom: question on scope
fjh: concerned that we are pushing privacy issue aside
... perhaps take offline
leaving ISSUE-34 open for now
Suresh: have we considered referencing documents from API specs?
... we don't reference our own documents
fjh: [discussing permissions]
... how does this relate to permission,
<dom> Dom: I think the Permissions document is supposed to reference APIs, not the other way around
<fjh> suresh asks if permissions doc should be referenced from API specs
<dom> Dom: the Permission draft would be referenced from a policy framework document, or from the Permissions APIs (for which we don't have an active editor atm)
<fjh> frederick suggests that this would make sense if they are integrated in a solution
<fjh> dom reminds us that permissions could be used from either a policy framework, or from a checkPermissions draft that needs to be written
<dom> ACTION-293?
<trackbot> ACTION-293 -- Robin Berjon to invite John Gregg to edit Feature Permissions API document in DAP -- due 2010-11-11 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/293
fjh: need to figure out how permissions document fits into whole structure
<lgombos> fjh: Feature Permissions API
Suresh: we do talk about permissions in API documents
lgombos: notification spec used to have this in it, but then broken up
fjh: do you need help on getting draft pulled together
... need to have on homepage
<dom> ACTION: lazlo to provide an editors draft of permissions API [recorded in http://www.w3.org/2011/01/19-dap-minutes.html#action07]
<trackbot> Sorry, couldn't find user - lazlo
fjh: dom may be right, but we need to understand issue
<dom> ACTION: laszlo to provide an editors draft of permissions API [recorded in http://www.w3.org/2011/01/19-dap-minutes.html#action08]
<trackbot> Created ACTION-332 - Provide an editors draft of permissions API [on Laszlo Gombos - due 2011-01-26].
<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: ISSUE-78 concern about exit data
<fjh> propose the HTML Media Capture have a note added similar to that in Media Capture
fjh: proposed to copy note over to HTML media capture
... who is editing HTML media capture?
<dom> both documents have a note on EXIF and minimization
<fjh> media capture api, http://dev.w3.org/2009/dap/camera/Overview-API.html section 2
fjh: media capture API has language in section 2
... note on EXIF data
<dom> "implementors should take care of additional leakage of privacy-sensitive data from captured media. For instance, embedding the user’s location in a captured media metadata (e.g. EXIF) might transmit more private data than the user might be expecting."
<fjh> HTML media capture, http://dev.w3.org/2009/dap/camera/#security, parenthetical in section 3
fjh: but in HTML Media Capture does not have similar language in section 3
... it does not have the same language
... for consistency, we should handle with same language
... Media Capture language is better
<fjh> suggest note in media capture to html media capture
fjh: proposing to handle same issue the same in both documents
<fjh> ISSUE-86?
<trackbot> ISSUE-86 -- Privacy issue about sharing other users contact information from own address book -- closed
<trackbot> http://www.w3.org/2009/dap/track/issues/86
<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: we need to figure this out sometime, how seriously we address privacy
<fjh> ISSUE-88?
<trackbot> ISSUE-88 -- User interaction for ruleset confirmation when multiple APIs are used to provide functionality, usability etc -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/88
Suresh: we have some text in Contacts API
fjh: yes, ISSUE-86 is resolved
bryan_sullivan: we will have further contributions on privacy soon
... based on WAC effort based on POWDER
... question is how to do this in websites
... bringing this to table will help move discussion
... hope to do this in February
... 2.0 version of WAC will come out soon
fjh: issue-88 suggestion is to do ruleset interaction
... we will hold this set of issues for later discussion
