<trackbot> Date: 27 March 2014

Welcome, agenda review, announcements

<scribe> ScribeNick: dom

Welcome, agenda review, scribe selection, announcements

<fjh> Vibration API related to WebApps gamepad API, discussion http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0016.html

Frederick: we might want to think about that at some point, but it's probably OK to leave the current API as is
... I'll just notify them when we go to CR

<anssik> that sounds good to me

Minutes approval

<fjh> Approve minutes from 20 March 2014

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/att-0014/minutes-2014-03-20.html

RESOLUTION: http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/att-0014/minutes-2014-03-20.html are approved as minutes of March 20 call

Netinfo API

Frederick: we've agreed to shelve it; I'm having trouble reaching Mounir
... I'm thinking to just go ahead and do it myself (update, Mounir replied on chat with update)

Dom: sounds good to me

Testing update

Cordova priorities

<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0022.html

Frederick: we discuss the usefulness of priotirizing work from a Cordova perspective

<fjh> In CR, two implementations (Blink/webkit), testing progressing (despite pull request not accepted yet), relatively straightforward spec

Frederick: we have tests, implementations
... for HTML Media Capture
... next put Battery, then Light

<Zakim> dom, you wanted to comment on light vs vibration

<fjh> dom: clarify, prioritization of alignment and contributing to tests

<fjh> dom: ambient light has less traction than vibration which is implemented in firefox and chrome

<anssik> ambient light implementation is happening in Chromium/Blink

Frederick: I'm conflating alignment and testing

<fjh> dom: do we know if cordova will contribute to testing

<anssik> our QA ppl are working on completing Vibration, Battery, HTML Media Capture test suites

<fjh> dom: cordova is not using webIDL

Frederick: [summarizing] there is quite a bit of work for them to align with our specs
... their implementations is not matching our specs at this time, but getting that alignment is separate from our Rec-track goals

dom: yeah, reducing fragmentation in the HTML5-apps ecosystem (incl hybrid) is a good goal, but separate from proving implementation at the CR level

<fjh> fjh: attempting to summarize what dom said - one goal is to achieve adoption and uniform APIs which hasn't happened yet and can be quite a bit of work with code, docs etc. Another goal is to move to REC which requires W3C Process but different activity, possibly differen players

<fjh> fjh: achieving Cordova compatibilty is a useful direction but may not contribute directly to getting to rec in the short term

HTML Media Capture testing

Frederick: I've been looking at the pull requests

-> http://www.w3.org/mid/F5C5CDD5-6255-4027-8B9A-B222F1A5C7DC@nokia.com Frederick on HTML Media Capture testing

scribe: still waiting for review
... a comment thread in github about testability for privacy and security considerations which has normative statements
... questioning whether that's appropriate
... Cathy mentioned geolocation as an example
... which has normative requirements in privacy / security
... and they have related tests as well
... e.g. checking for permission denied
... my conclusion is that we don't have to gut the security and privacy considerations
... and that we should go ahead with what we have

<Zakim> dom, you wanted to comment on geo as example and to comment on normative considerations, testing of shoulds

<fjh> dom: not sure geolocation is the best model, despite my involvement

<anssik> our QA person who wrote the test suite is waiting for +1s from reviewers or feedback on how to improve the suite if there are issues -- please let him know if there's something he can help with still

<fjh> dom: need to consider two items: security,privacy be normative and whether to create test cases for should cases

<fjh> dom: want to avoid security privacy considerations related to UI implementation

<fjh> dom: would personally prefer non-normative, if we keep them normative then should ask about testing, prefer not to test them due to UI considerations, requiring manual testing

<fjh> dom: processing should requirements is an issue

Frederick: I'm concerned about taking privacy seriously without having normative text on it
... if privacy matters, we need to make sure it is actually taken into account in implementations
... agree that testing privacy doesn't fit as cleanly

<fjh> dom: normative requirements are for interoperability hence not approriate for privacy/security, and implementers will do what they want in this space

<fjh> dom: important to document but not as normative requirements, can be informative

<fjh> dom: key is to be clear on risks and way to mitigate them, cannot force implementation, misguided

<fjh> dom: geolocation requires URL to be displayed in prompts and that requirement is not followed by any implementations, for good reasons

<fjh> dom: be careful not to say it is not meaningful if not normative, e.g. if browser ignores threats and then exploited

<fjh> fjh: you are making competitive implementation argument

<scribe> ACTION: dom to react on testing html media capture privacy & security considerations [recorded in http://www.w3.org/2014/03/27-dap-minutes.html#action01]

<trackbot> Created ACTION-686 - React on testing html media capture privacy & security considerations [on Dominique Hazaël-Massieux - due 2014-04-03].

Network Service Discovery

Frederick: would like to do 3 things:
... * go through the issues and see whether and how to resolve them
... * process around editing
... * how to move forward in general
... Rich, could you maybe start by describing where you think we are?
... and then I could get into our editing process

Rich: sounds good; let's tackle high priority items first

Frederick: in general, does this teleconference time work for you on regular basis, rich?

Rich: yes:

Frederick: so, summary of current status and news?

Rich: in terms of the spec, the last major change was adding CORS a while ago
... I've made some comments on the technical discussions; they can be picked up again
... The main update is around intents to implement
... there was one intent in Chromium/Blink which started some of the changes we brought to the spec
... not clear where we stand in terms of getting implementors buy in
... Getting feedback from implementors is key in making progress, more than finetuning what we already have

Frederick: my viewpoint on how the WG works: the way I see it is that WG makes decisions, and the editor brings them in in the spec
... getting WG agreement before getting stuff in the spec is important
... the decision lies within the WG consensus
... contributions can be made as issues, or specific text proposal, which in some cases can find their way directly in the spec
... of course, we need some implementors buy-in
... but I don't think there is a harm to think things through even if we don't have implementors buy-in yet
... I don't think implementors should decide everything; not sure how that would work with our own timelines and goals
... I'm not sure how to move forward if we don't have implementors buy-in

<Zakim> dom, you wanted to discuss meaningful privacy and to

Frederick: we have people interested in this spec from the TV space
... but they got pushed back from Adam?, and went into using something else

Rich: Yeah, I've seen this
... I would have preferred these discussions to happen in W3C
... there are alternatives that are emerging which may be put NSD into a difficult position
... e.g. Chrome is now looking at the Presentation API
... In terms of next steps, we need to get feedback / buy-in from implementors

Frederick: I looked at the Presentation API — it seemed complementary rather than in competition

Rich: it's not a replacement API, but it does solve some use cases that NSD also solve
... e.g. what chromecast enables

<anssik> the group where the Presentation API is being worked on: http://www.w3.org/community/webscreens/

Rich: display sharing is only a subset, but maybe that's the most useful subset

<anssik> we have Google, Mozilla, and Apple in the group

Frederick: another worm will be how testable the spec would be given how complex it is

Rich: at the network level, I have some ideas
... the UI stuff is more complicated for automated testing
... when it comes to service messaging, that's beyond what we would need to check
... but no testing plan since no implementation plan

Frederick: so you would do this by sniffing the network

Rich: possibly; but that only becomes a problem once we have implementation plans
... You also mentioned that the spec has lots of moving parts, and that's true
... the API started from a very ambitious approach
... maybe we can simply it, e.g. getting inspiration from the sockets idea
... the current stage is a bit frustrating, but I don't think we can move forward without implementations

<Zakim> dom, you wanted to propose that next steps is to get people that want NSD to work with us on trying to get implementors' attention

<fjh> dom: seems right to wait for implementers feedback and interest

<fjh> dom: need to get right level of abstraction

<fjh> dom: next step should be to get more feedback from implementers, could ask Web & TV interest group for help

<fjh> dom: could specifically contact implementers we know to get feedback, if fundamental concerns with overall approach

<jcdufourd> I already asked multiple times for web&tv ig help, to no avail

<fjh> dom: yes

<fjh> ACTION: fjh to make request to Web and TV interest group re network service discovery [recorded in http://www.w3.org/2014/03/27-dap-minutes.html#action02]

<trackbot> Created ACTION-687 - Make request to web and tv interest group re network service discovery [on Frederick Hirsch - due 2014-04-03].

<fjh> ACTION: fjh to contact implementers re network service discovery directly [recorded in http://www.w3.org/2014/03/27-dap-minutes.html#action03]

<trackbot> Created ACTION-688 - Contact implementers re network service discovery directly [on Frederick Hirsch - due 2014-04-03].

Frederick: so, should we look at issues in the meantime of getting implementors feedback?

Rich: I think it is difficult to focus on issues without implementors interest

<jcdufourd> we are looking into implementing NSD as a Chrome extension

Rich: I agree with dom we should be proactive on contacting implementors
... I've also been thinking about Web pages as advertising themselves on the network, which was supposed to be the 2nd stage after discovery
... but it could be a good thing to explore
... might also raise interest on discovery

Frederick: could you share more about that?

Rich: I've been doing some brainstorming around that
... you can create channels among some-origin pages
... but there isn't a generic cross-origin channel
... enabling this would open very interesting use cases
... we could look at this either from an NSD perspective (relying on UPNP etc)
... or using a different sockets approach
... I have some early design thoughts

Frederick: we would want to be careful in light of NSD
... I would certainly support the simple approach

Rich: as a reminder, Opera originally implemented NSD
... but we switched browser engine in the meantime

Frederick: can we coordinate on contacts with implementors?

Rich: probably best if it comes from you as chair

Frederick: OK, based on this, I think we'll stay off issues for now; Rich, might want to look at some of the minor editorial ones

Action items review

<fjh> ACTION-684?

<trackbot> ACTION-684 -- Dominique Hazaël-Massieux to Help close pull request #376 on batter, duplicate so does not need to be incorporate -- due 2014-03-27 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/684

<fjh> ACTION-682?

<trackbot> ACTION-682 -- Frederick Hirsch to Follow up on how to approve pull requests and to identify correct reviewers, remove inappropriate critics etc -- due 2014-03-06 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/682

ACTION-684: see https://github.com/w3c/web-platform-tests/pull/376#issuecomment-38816061

<trackbot> Notes added to ACTION-684 Help close pull request #376 on batter, duplicate so does not need to be incorporate.

trackbot, close ACTION-684

<trackbot> Closed ACTION-684.

<fjh> action-684?

<trackbot> action-684 -- Dominique Hazaël-Massieux to Help close pull request #376 on batter, duplicate so does not need to be incorporate -- due 2014-03-27 -- CLOSED

<trackbot> http://www.w3.org/2009/dap/track/actions/684

<fjh> ACTION-684?

<trackbot> ACTION-684 -- Dominique Hazaël-Massieux to Help close pull request #376 on battery, duplicate so does not need to be incorporate -- due 2014-03-27 -- CLOSED

<trackbot> http://www.w3.org/2009/dap/track/actions/684

<fjh> s/Topic: Testing Update//

Other Business

<fjh> fjh: next meeting 10 april, see schedule for upcoming dates, http://www.w3.org/2009/dap/minutes.html#upcoming-teleconferences

Adjourn

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/myself/myself (update, Mounir replied on chat with update)/
FAILED: s/Topic: Testing Update//
Succeeded: s/MEdia/Media/
Succeeded: s/this time/this teleconference time/
Found ScribeNick: dom
Inferring Scribes: dom
Default Present: fjh, dom, mats, richt, Cathy, gmandyam, anssik, richt_
Present: Cathy Cathy_Chan Frederick_Hirsch Mats_Wichmann Rich_Tibbett anssik dom fjh gmandyam mats richt richt_ Anssi_Kostiainen(IRC) Dominique_Hazael-Massieux Giri_Mandyam(IRC) JeanClaude_Dufourd(IRC)
Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/0021.html
Found Date: 27 Mar 2014
Guessing minutes URL: http://www.w3.org/2014/03/27-dap-minutes.html
People with action items: dom fjh