See also: IRC log
<trackbot> Date: 05 December 2012
<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
<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
<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
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
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?
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