Device APIs Working Group Teleconference

05 Dec 2012


See also: IRC log


Anssi_Kostiainen, Bryan_Sullivan, Clarke, Colin_Courtney, Dzung_Tran, Frederick_Hirsch, Giri_Mandyam, Josh_Soref, Jungkee_Song, Laszlo_Gombos, Milan_Patel, Niklas_Widell, Tatsuya_Igarashi, naoyuki_sato
Dominique_Hazael-Massieux, richt


<trackbot> Date: 05 December 2012

Welcome, agenda review, scribe selection, announcements

<scribe> scribe: Josh_Soref

<fjh> Network Information API updated draft published: http://www.w3.org/News/2012#entry-9640

<fjh> Proximity API Last Call publication planned for tomorrow.

<fjh> Please complete F2F questionnaire for date of next F2F: https://www.w3.org/2002/09/wbs/43696/f2fQ12013/

<fjh> Reminder - no teleconference 19 December, 26 December, 2 January.

<fjh> thanks Mounir for last minute updates to get the Network Information API published

gmandyam: I sent an issue for the network information

fjh: i'll add an agenda item for it at the end
... Network Information API

Minutes Approval

<fjh> 17 October - http://lists.w3.org/Archives/Public/public-device-apis/2012Oct/att-0042/minutes-2012-10-17.html

RESOLUTION: Minutes from 17 October are approved

<fjh> F2F 1-2 November 2012

<fjh> http://www.w3.org/2009/dap/materials/minutes-2012-11-01.html

<fjh> http://www.w3.org/2009/dap/materials/minutes-2012-11-02.html

RESOLUTION: Minutes from F2F 1-2 November are approved

fjh: Josh_Soref just sent the minutes from last week

<fjh> 28 November 2012 http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/att-0005/minutes-2012-11-28.html

<fjh> let's approve these next week

HTML Media Capture

<fjh> Proposal with boolean - http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0097.html

<fjh> I sent some comments http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0003.html

<fjh> fjh: thanks very much for a good proposal Anssi, it is an improvement, thanks for making an unofficial version and redline, that was very helpful. I have some comments related to material from the old version that probably should be fixed in the revision

<fjh> anssi would you like to say anything about the update?

fjh: AnssiK, thanks for the new proposal
... i think that was very helpful
... i think your approach of making an unofficial draft was helpful
... I sent some comments, I think they're editorial
... AnssiK, is there anything you want to add?

AnssiK: i'm looking for people to review the proposal
... and +1 it
... we should very quickly pick the approach we want to push

fjh: one comment i had
... most were editorial
... i think we can get rid of the note
... and make it clear there's no precedence issue
... and there was something about clarifying file v. media capture
... i think the new examples are great
... i think it might be helpful to make it clear that it's a camera and not a generic file upload

AnssiK: are you referring to get getUserMedia?

fjh: I didn't see the <input> element with the accept= and capture= attributes

AnssiK: they're basically continued
... i'll make it clearer

fjh: i suspected that, but...

AnssiK: in order to not repeat stuff, i split it into a couple of example blocks

fjh: in each example, you should say which other previous blocks are relevant

AnssiK: the highlighter doesn't XXX

fjh: examples build on each other, and you don't want to replicate everything
... but i think you should include some text indicating which things you're continuing

AnssiK: the reason i split scripts out of the html was
... YYY

fjh: i didn't understand how you'd do a scanner with this approach

<AnssiK> the reason for splitting examples: highlighter does not work if you have both HTML and JavaScript in the same example block

AnssiK: you just specify the mime type you want in the accept type

Josh_Soref: like image/tiff

AnssiK: and then have the capture= attribute

gmandyam: question for AnssiK
... when we talk about precedence
... accept over capture
... how will that be done in practice?

<fjh> I have proposal in my email for dealing with this

gmandyam: if there's capture=true
... and accept=image/png

<fjh> ignore capture if not possible

gmandyam: and there's no camera attached

AnssiK: probably we should remove that text all together
... i forgot about that text
... i'll remove it
... i think fjh 's review covered that

fjh: yeah, i had a proposal for that
... it's no longer precedence
... it's "if the device doesn't have a means for capturing that mime type"
... then it's effectively as if you don't have the boolean

gmandyam: that's fine
... and we're ok with a web site being able to fingerprint with that?
... it could detect the absence of capture devices?

AnssiK: actually, you can't
... it's just an attribute
... it won't increase the fingerprinting surface

<fjh> in new version fingerprinting surface seems less, only a boolean

AnssiK: i don't see how this could be worse than the previous proposal
... this is an improvement

fjh: i'd argue using a boolean gives much less information

<bryan> wouldn't the user need to interact with the input to enable any fingerprinting data collection?

fjh: i'm not sure how you could figure it out
... you don't have the specificity
... we'll have to review all this stuff for privacy
... but we have to get a draft in place first
... i think the next step

<bryan> any fingerprinting that depends upon user interaction would likely not scale

fjh: what i'd like to do is agree to make the unofficial draft the new editor's draft
... we need to decide to adopt this new approach
... and make a decision to publish a new WD
... next week
... because there's still edits to be done
... i'd like to decide to go forward with this approach
... too bad dom isn't on the call

<bryan> +1 to the new approach

fjh: does anyone object to adopt the approach of using the boolean?

<AnssiK> +1 to go forward with the new proposal

Josh_Soref: +1 to the new approach

RESOLUTION: WG agrees to adopt the approach taken in the new proposal of using the boolean for HTML Media Capture

fjh: please update the draft and make it the editor's draft
... and then on next week's call, let's make a decision to publish a new WD

AnssiK: can we decide on the Publication Date?

fjh: let me check my calendar

<gmandyam> In terms of fingerprinting, I don't think Anssi's proposal makes thing worse than the previous version of HTML Media Capture. However, I don't see how it improves upon fingerprinting either.

fjh: but you may need to update the ED if you get feedback
... we're running close to the Pub deadline
... i'd suggest we try to publish on the 18th

<gmandyam> I think it achieves what was the primary intention (based on my understanding) - resolving any conflicts between the accept and the old version of the capture attributes.

AnssiK: please action me to give me the deadline in tracker

<fjh> ACTION: anssiK to update editors draft for HTML Media Capture using proposal and incorporating changes based on comments [recorded in http://www.w3.org/2012/12/05-dap-minutes.html#action01]

<trackbot> Created ACTION-600 - Update editors draft for HTML Media Capture using proposal and incorporating changes based on comments [on Anssi Kostiainen - due 2012-12-12].

<fjh> ACTION: anssik to prepare updated WD of HTML Media Capture in preparation for publication on 18 December (assuming WG agreement 12 Dec) [recorded in http://www.w3.org/2012/12/05-dap-minutes.html#action02]

<trackbot> Created ACTION-601 - Prepare updated WD of HTML Media Capture in preparation for publication on 18 December (assuming WG agreement 12 Dec) [on Anssi Kostiainen - due 2012-12-12].

fjh: thanks everyone, this is a major step forward
... thanks AnssiK
... does anyone have anything more on HTML Media Capture?
... and AnssiK, please send out a message to the list that you've updated this

Network Service Discovery

fjh: there was discussion on the list

<fjh> service name resolution? http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0098.html

fjh: my take on it is that that has been resolved

Josh_Soref: I think cathy did resolve it

fjh: we might have a fingerprinting issue to review
... there's an assumption that cathy made that reduces the risk of fingerprinting
... but we should review that at some point

<fjh> Naoyuki Review comments - http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0101.html

fjh: we'll take this to the list

<fjh> We need to review these comments and discuss on list, seeking comment from Cathy and Rich

Ambient Light

fjh: we had a CfC
... but i had trouble getting in touch w/ dougt
... but i wanted to include him
... is anyone in touch with him?
... is mounir on the call?

Network Information

fjh: we published an updated draft
... gmandyam, is this a new issue?

Josh_Soref: this is the issue that we had discussed before
... but which hadn't been raised into tracker

gmandyam: this is bandwidth estimation

<fjh> ISSUE-128?

<trackbot> ISSUE-128 -- Need more description on how bandwidth should be estimated -- raised

<trackbot> http://www.w3.org/2009/dap/track/issues/128

[ fjh has issues with the issue tracker's raised status ]

fjh: i heard that it was highly implementation dependent

gmandyam: my suggestion is to just remove it
... i don't think you can get it
... my guess is one of two things will happen
... there will be so much variability in how it is implemented
... that developers won't rely on it

<fjh> spec has note on metered, not bandwidth, http://www.w3.org/TR/2012/WD-netinfo-api-20121129/

gmandyam: or developers can try to calculate it their own way
... Navigation Timing has its own api

fjh: if implementations can figure it out, they can provide it,
... if not, they provide infinity

gmandyam: i don't see the point in standardizing something
... that useragents claim they can provide, but which won't be accurate
... he has a couple of notes

fjh: there's no note on bandwidth, because you can provide it, or give infinity

gmandyam: it isn't good enough to provide it if it's bad
... or every browser has its own algorithm which yields different results
... i'm confident that browsers won't provide consistent/reasonable values
... how would you file a bug against browsers?

<fjh> ok, concern is noted in section 1.2 outstanding issues

bryan: the accuracy of values can be tested

<fjh> ISSUE-128: note in spec about issue is in section 1.2 Outstanding issues : "One concern is that bandwidth may be hard to implement, can be quite power-consuming to keep up-to-date and its value might be unrelated to the actual connection quality that could be affected by the server.

<trackbot> ISSUE-128 Need more description on how bandwidth should be estimated notes added

<fjh> A solution to fix this would be to return non absolute values that couldn't be easily abused and would be more simple to produce for the user agent. For example, having a set of values like very-slow, slow, fast and very-fast. Another solution would be to have only values like very-slow, slow and the empty string."

gmandyam: if it's done in the UA, i don't think it's going to be accurate no matter what
... if there's value, we can see how they do / how it's used

<fjh> ISSUE-128: see http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html#outstanding-issues

<trackbot> ISSUE-128 Need more description on how bandwidth should be estimated notes added

bryan: as wireless technologies get better
... i think you'll find much more stability (in LTE, LTE Advanced)
... variability will become less of an issue

gmandyam: mobility always screws up bandwidth estimation
... you could go to wider bandwidth or narrower bandwidth systems
... i think the way bandwidth is estimated should be discussed in the spec
... if you say that, we have something to test against

fjh: there's an issue in the spec in 1.2
... it is noted in the spec

gmandyam: the issue i raised is to specify how it's estimated
... i don't think it should be left up to implementations alone

<bryan> i would just suggest that we subject the implementations to testing, and if we have too much variability in the estimates, or bandwidth variability (over a short time) is determined to be a major limitation, we could drop it from the final spec.

fjh: adrianba made it clear

<bryan> in the meantime I agree with adding some guidelines on estimation to the spec

fjh: If you're relying on the underlying platforms

gmandyam: what Qualcomm provides today
... isn't always making its way to the high level OS
... I don't think the HO OS takes advantage of what the modem provides
... I think his point is valid to an extent
... but I think it forces the UA to do its own estimation

fjh: would this problem be resolved if you treated the number as an estimated value
... and an estimated error-precision
... it seems what you're getting at is that we don't know what the precision is
... a single number isn't good enough

gmandyam: having a single number isn't good enough
... you have to understand how it's estimated
... you're saying how it's estimated affects the number returned
... maybe providing a software indicator of confidence

<fjh> possible proposal - provide bandwidth + accuracy/precision estimate

gmandyam: my feeling is the way the spec is written
... it allows for a lot of variability
... and developers won't rely on it
... and they'll go to Navigation Timing

nwidell: at TPAC we discussed this
... bandwidth may not be addressing the right problem
... what developers want to know is how good the connection is behaving
... so they can adapt their content
... that was mentioned by adrianba
... many developers need some value they can handle

<fjh> I thought Adrian suggested we need more thought on this

nwidell: something that's useful
... i spoke to people inside Ericsson
... maybe this is something we should ask "developers" what kind of information would be useful to have
... before we try to define something
... potentially, what was raised by a colleague of mine
... is maybe not bandwidth
... but estimated bandwidth on the last leg
... maybe that's something the native platform can handle efficiently

fjh: i assume you're assuming the last leg is the problem

nwidell: i'm assuming the bottleneck and that is why it is interesting, otherwise not sure I understand why is often the last leg

<fjh> do we need to clarify the use case?

nwidell: there was a Web Performance workshop
... there may be stuff coming there that may be useful

lgombos: the browser isn't always on the same OS
... the modem may not be easily accessible to the browser

fjh: it seems we need to define it in a way that isn't defined
... either we don't provide bandwidth at all
... we provide a standard way to categorize it
... or provide a way to express error range
... you shouldn't have to make assumptions about what's underneath

gmandyam: or recommend in the spec how the UA should estimate bandwidth
... so we'd have something to test
... right now we don't know when a browser is compliant or not

<Zakim> Josh_Soref, you wanted to say I'd like people to use Navigation Timing

fjh: we need to test this, so need to think ahead how this might be done

Josh_Soref: at home using cell phone with uplink and wifi hotspot, laptop talks to phone to the internet, a common use case
... last leg is wrong leg to test
... assumption that there is a last leg that is useful is wrong
... should use Navigation Timing
... should see actual use cases, discussed and learned media streaming already has way to do this

<fjh> +1 to need of clear use cases

Josh_Soref: most use cases be solved by Navigation Timing
... video frame underflow and overflow
... could have API asking if site is made available offline
... ie. provide user an alternative to bandwidth estimation, by providing direct means to addressing use case

fjh: if bandwidth isn't good enough
... you probably want a way to address the overall problem
... we should look at navigation timing
... and we need UCs
... i think we should take this discussion to the list
... i'll kick it off

<fjh> ACTION: fjh to send summary and query to the list to start Network Information discussion [recorded in http://www.w3.org/2012/12/05-dap-minutes.html#action03]

<trackbot> Created ACTION-602 - Send summary and query to the list to start Network Information discussion [on Frederick Hirsch - due 2012-12-12].


<AnssiK> http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/LC.html

<AnssiK> are we on track to publish LC tomorrow?

fjh: yes we're all set

<fjh> close ACTION-584

<trackbot> ACTION-584 Update F2F agenda for sensor next steps, network information, and to make invitations for mozilla participation closed

fjh: i've done the submission
... it's all set to go
... i think we're done
... we'll meet again next week

<fjh> close ACTION-585

<trackbot> ACTION-585 Review Battery test and contribute more tests closed

fjh: when hopefully we'll agree to publish an update to HTML Media Capture
... and we'll publish the update to Ambient Light
... thanks all

<fjh> close ACTION-589

<trackbot> ACTION-589 Send CfC for Last Call of Ambient Light Events closed

<fjh> close ACTION-593

<trackbot> ACTION-593 Build a survey for finding a week for DAP meeting March/April closed

<fjh> close ACTION-594

<trackbot> ACTION-594 Arrange publication of updated WD of Network Information API closed

<fjh> close ACTION-597

<trackbot> ACTION-597 Announce plans for LC publication to webapps, sys apps, ping closed

<fjh> Call scheduled for next week, 12 December 2012

trackbot, end meeting

Summary of Action Items

[NEW] ACTION: anssik to prepare updated WD of HTML Media Capture in preparation for publication on 18 December (assuming WG agreement 12 Dec) [recorded in http://www.w3.org/2012/12/05-dap-minutes.html#action02]
[NEW] ACTION: anssiK to update editors draft for HTML Media Capture using proposal and incorporating changes based on comments [recorded in http://www.w3.org/2012/12/05-dap-minutes.html#action01]
[NEW] ACTION: fjh to send summary and query to the list to start Network Information discussion [recorded in http://www.w3.org/2012/12/05-dap-minutes.html#action03]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2012-09-20 20:19:01 $