See also: IRC log
<trackbot> Date: 06 March 2013
<scribe> Scribe: Josh_Soref
<fjh> Please use this link to update phone number mapping for zakim https://www.w3.org/1998/12/bridge/info/name.php3
<fjh> Note: Next meeting is regular ET time; this makes it an hour earlier in Europe due to different in daylight savings time, see https://lists.w3.org/Archives/Member/member-device-apis/2013Mar/0001.html
Josh_Soref: i'm unlikely to call in on the 27th (Passover)
<fjh> Approve minutes from 27 February 2013
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/att-0093/minutes-2013-02-27.html
<fjh> Approve (revised) minutes from 20 February 2013
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/att-0098/minutes-2013-02-20.html
<fjh> proposed RESOLUTION: Minutes from 20 Feb (revised) and 27 February 2013 are approved
RESOLUTION: Minutes from 20 Feb (revised) and 27 February 2013 are approved
<fjh> Questionnaire completes 12 March, https://www.w3.org/2002/09/wbs/43696/2013-06-f2f/
<fjh> https://www.w3.org/2002/09/wbs/43696/2013-06-f2f/results
dcheng3: i still have both reserved
<fjh> Deadline for deciding on TPAC 2013? ( Nov 18-22 in Shenzhen - http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0095.html )
fjh: i think we need to know way in advance to decide, because of Visas
dom: usually WGs are asked in March/April if they want to participate in TPAC
fjh: the June F2F was questionable, i think we can lock that down
... if we don't progress on Web Intents, we might not need TPAC
dom: i don't know that there's a schedule on this question
... but it would probably be asked in April
... intending to meet isn't necessarily a strong commitment
... we could cancel later
fjh: i mentioned that the Intents/Activity people were supposed to discuss shortly
... i'd assume we'll know by the first week of April if we'd want to meet
... i'm assuming Dusseldorf will work out well
<fjh> Status on updates and publication of WD?
<fjh> additional discussion:
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0097.html
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0003.html
richt: i'm traveling until Friday
... back Monday
... i have a backlog of changes
Cathy: re: Guisseppi comments earlier
... discovering UPnP device types v. Service types
... w/ device types, controllers typically are more interested in devices as opposed to services
... but that would be a significant change to the UPnP mechanism in the spec
... we need to consider implications
richt: i agree
... Cathy, based on your experience, it might be a good idea for you to edit that in
Cathy: i'll work with you on that
richt: it'd be cool to get you involved in editing
fjh: the change offers simplifications/solves problems
... Cathy, there's no need for you to get extra permissions, since we're using git
richt: we're using overview-src.
fjh: Cathy, do you need an action?
Cathy: no
richt: i'd prefer discussing on list before we make changes?
Cathy: sure
<fjh> +1 to proposal on list before editing document, thanks Cathy for volunteering
fjh: Cathy will make progress on device-types/service-types
<richt> I think you captured it well, Josh_Soref.
fjh: and richt will work on the backlog
<fjh> Sys Apps draft - http://www.w3.org/2012/sysapps/drafts/contacts-manager-api/
<fjh> Pick Contacts Implementation status, original DAP Contacts implementation status?
fjh: marcos asked about implementation
dom: afaik it was never implemented by anyone
Josh_Soref: it's implemented in the original form by Cordova
<dom> http://www.w3.org/2009/dap/wiki/ImplementationStatus#Contacts_API
fjh: we don't have any record of this
dom: we do, thanks to AnssiK
<fjh> ok, thanks Dom for the pointer, and AnssiK for the wiki work
richt: which are we talking about?
... we have a mozilla implementation
dom: but that was an addon
[ Josh_Soref summarizes concerns about SysApps doc ]
Josh_Soref: thanks fjh for getting them to rename their spec
fjh: i'm not sure if we can give feedback
Josh_Soref: some WGs will be asked to give feedback
... but all WGs can give unsolicited feedback
<fjh> resolving LC comments, http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0002.html
fjh: i gave shepazu a 2 week time window this time, i should have done that last time
dom: yes, that's good
AnssiK: thanks fjh for pushing Tracker
... i'll update the draft after we close shepazu's issues
... i'll add a status section about Exit criteria
... i'll give shepazu a couple of days
<mounir> Josh_Soref: actually, if the user must have to use a capture device, that could work too (i guess) but a common behaviour would be better. I'm not sure what is the specification wording regarding this.
<mounir> Regarding the HTML Media Capture, there is a problem regarding the ability for the user to opt-out from the capture device and use its stored pictures instead. I believe that should be allowed but I'm not sure how much we should make this a requirement for specifications.
Josh_Soref: mounir: i thought that we designed the spec to specifically allow for that!
fjh: i think we made a mistake in our publications in not including Exit Criteria/At Risk in our documents
... i don't think we need to update the status retroactively
... we won't go back to CR, we'll just go to PR
AnssiK: you gave Mar 18 as the deadline to shepazu
... i won't touch it before then
fjh: dom, can go to PR w/o having that section in the document, as it's documented elsewhere
dom: that shouldn't be a problem
... you're mixing Battery and Vibration
... but AnssiK is talking about HTML Media Capture
fjh: when we do transitions
... we need to include status/at risk
... we need to guess when we're done w/ LC comments
... we need to add Exit Criteria to the Status section
... and then having seen that, we publish as CR w/ transition request
... i just wanted to confirm w/ dom that we don't need to republish
... going forward, every doc should have status when we go to CR
dom: that's correct
... do we have any visibility on who is going to implement the spec?
... i know chrome has an impl based on the old spec
... i'm unclear about BlackBerry
... i know Firefox does accept attribute as well
AnssiK: we have discussion in the html bug tracker
... mounir doesn't say they will implement
... but says that the spec is simple and efficient and they like it
... Josh_Soref could comment on BlackBerry
Josh_Soref: need to check with our implementers
dom: anyone know about Chromium/Opera ?
AnssiK: i think Tizen implements
fjh: i thought I saw that as well
<AnssiK> http://www.w3.org/2009/dap/wiki/ImplementationStatus#HTML_Media_Capture
fjh: AnssiK, how hard would it be to indicate if it's an implementation
... or just a note
AnssiK: yeah yeah
... when i notice someone is mentioning it, i try to include
... perhaps this should be more like caniuse.com
fjh: when i look at the list, i don't know if we're good to go
... maybe you can add text to the wiki
AnssiK: i haven't always looked at the source code
... and without the product in my hand, it's hard to know what is the level
... i'll try to dig deeper
fjh: just trying to understand what the wiki is saying
AnssiK: the wiki is pointers to implementations that claim to support these specs
... but levels and spec version is missing
fjh: so this isn't a list of vetted implementations
... it's a list where somewhere someone mentioned they might
<AnssiK> "Implementations cited in this document may or may not implement the latest version of the related specification."
fjh: when you have more details, it'd be helpful if you add them to the wiki
AnssiK: Josh_Soref, what is the status of BlackBerry on Media Capture
... I received a BB10 device
<Zakim> dom, you wanted to ask about testing
Josh_Soref: i'm hoping to talk to devrel guys tomorrow
dom: for that spec, we probably want to do some testing
... has anyone done any work on testing?
... are there existing testcases?
AnssiK: i'm going to use the BlackBerry Dev Alpha device to see if it has anything
... i have the Vibration test suite to do
... dom, do you have ideas for the interactive tests?
... how to craft interactive tests for these specs
... there are implementation details that you're unable to test
dom: i see two kinds of tests
... IDL level
... parsing/handling
... interaction between Accept and Capture
... and then there's an interactive part
... i'd simply say in the test itself
... when you press the button, you should be offered to get a picture from your camera
... and then maybe testing the file type
AnssiK: thanks, that matches what i was thinking about
... the idl is simple, so idlharness or manual tests
... and for interactive, something like you described
dom: i think separate actions for separate test suites is more actionable
<fjh> ACTION: anssik to create test cases for battery and vibration [recorded in http://www.w3.org/2013/03/06-dap-minutes.html#action01]
<trackbot> Created ACTION-620 - Create test cases for battery and vibration [on Anssi Kostiainen - due 2013-03-13].
AnssiK: let's do another action
<fjh> close ACTION-620
<trackbot> Closed ACTION-620 Create test cases for battery and vibration.
<AnssiK> ACTION: AnssiK to create test cases for HTML Media Capture [recorded in http://www.w3.org/2013/03/06-dap-minutes.html#action02]
<trackbot> Created ACTION-621 - Create test cases for HTML Media Capture [on Anssi Kostiainen - due 2013-03-13].
dom: the HTML WG is making a change to their test suite
... giving up the submitted/approved structure
... have we discussed migrating this group's tests?
fjh: i was thinking of wait-and-see
dom: i think it's working reasonably well for them
Josh_Soref: vibration is stuck because it's submitted but not accepted
<fjh> would like to see focus on actual work rather than logistics unless it is low effort to make the changes
Josh_Soref: AnssiK now has a bb10 with it
AnssiK: i'm testing it, but it seems to indeed be implemented
... it is buzzing
... good work guys
<fjh> ACTION-613?
<trackbot> ACTION-613 -- Frederick Hirsch to draft proposed OMA liaison response -- due 2013-02-13 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/613
fjh: dom reminded me that it might be appropriate to respond formally
... i'll draft a response
<fjh> PING feedback : http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0095.html
<fjh> Possible updates to Proximity and Ambient Light Event specs
fjh: i believe this message captures their feedback accurately
... specs aren't used in isolation
... npdoty offered to help
... The ability to fingerprint based on timing might not be the easiest way
Josh_Soref: there is another advantage re privacy timings
... if an application is written to a single implementation
... it could break if another implementation has different timings
... if the spec encouraged a single timing behavior
... then an application could be less likely to break when it interacts with a different implementation
fjh: in GeoLocation there's an idea of lying
... that might also apply to these other apis
Josh_Soref: it should apply to these apis as well
... capture being an example
... -- letting the user select an already available object
fjh: the other concept from GeoLocation is Fuzzing
... giving a less accurate value
... we did that with ambient light
<fjh> in HTML Media Capture you could opt out by defaulting to file picker instead of using camera device
<AnssiK> "When the capture attribute is specified, the user agent SHOULD invoke a file picker of the specific capture control type."
Josh_Soref: note that it's a "File Picker" of a "Capture Type"
... certainly BlackBerry systems where the file picker gives access to both Gallery and Camera/Mic does this :)
fjh: we received Feedback from PING about Proximity/Ambient light
... with specific approaches we should take
... should we try to take a pass through the spec to see if we can incorporate that before moving forward?
<fjh> "there should be an indication to the user when the sensors are used"
Josh_Soref: Ambient could have been designed as a Media Query
... but you can certainly detect Media Query states
<fjh> "disable sharing proximity information"
Josh_Soref: browsers have spent 20 years trying to design the lock icon
... and some low level specs have UI requirements which were *never* implemented
dom: we generally avoid putting normative text in about UI
fjh: but we put in consideration sections?
dom: do we put an indication in to suggest to the user that it's in use?
... we claim that these are generally QoI
Josh_Soref: we could point to implementations which have done something for indications
<fjh> I suggest we should take the PING input and see what changes we should make to the specs, such as the privacy considerations
Josh_Soref: e.g. the current Chrome (Canary) shows you what's allowed/has been used if you click the Lock Icon
<fjh> also need to follow up with nick on general considerations
<fjh> ACTION: fjh to follow up on concrete actions based on PING input [recorded in http://www.w3.org/2013/03/06-dap-minutes.html#action03]
<trackbot> Created ACTION-622 - Follow up on concrete actions based on PING input [on Frederick Hirsch - due 2013-03-13].
<dom> Chrome permissions
AnssiK: i think we should be concrete
fjh: i'd appreciate if people could respond to the message on the list
<fjh> ACTION-617: https://www.w3.org/2002/09/wbs/43696/2013-06-f2f/
<trackbot> Notes added to ACTION-617 Set up f2f questionnaire.
<fjh> close ACTION-617
<trackbot> Closed ACTION-617 Set up f2f questionnaire.
<fjh> ACTION-618: http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0001.html
<trackbot> Notes added to ACTION-618 Provide sotd text for battery, vibration status updates.
<fjh> close ACTION-618
<trackbot> Closed ACTION-618 Provide sotd text for battery, vibration status updates.
<fjh> ACTION-619: http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0002.html
<trackbot> Notes added to ACTION-619 Follow up with Doug re closing HTML Media Capture LC Comments.
<fjh> close ACTION-619
<trackbot> Closed ACTION-619 Follow up with Doug re closing HTML Media Capture LC Comments.
<fjh> none
trackbot, end meeting
