[![W3C][1]][2]

# Device APIs Working Group Teleconference

## 11 Jul 2012

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Adrian_Bateman, Cathy_Chan, Claes_Nilsson, Dave_Raggett, Diana_Cheng,
Frederick_Hirsch, Giri_Mandyam, Hiroyuki_Aizu, James_Hawkins, Jean-
Claude_Dufourd, Jean_Michel_Rouger, Josh_Soref, Jun_Fujisawa, Jungkee_Song,
Kensaku_Komatsu, Laszlo_Gombos, Milan_Patel, Mounir_Lamouri, Naoyuki_Sato,
Niklas_Widell, Paul_Kinlan, Rich_Tibbett, Richard_Tibbet, Robin_Berjon,
Soonbo_Han, Steve_VanDeBogart_(vandebo), Travis_Leithead, Wonsuk_Lee,
Youenn_Fablet, jerome_giraud, GeunHyung_Kim

Regrets


Chair

    Robin_Berjon, Frederick_Hirsch

Scribe

    Josh_Soref

## Contents

  * [Topics][5]

    1. [Wecome, admin][6]

    2. [WebIntents and Local Services][7]

    3. [Networked Service Discovery and Messaging][8]

    4. [UPnP Discovery Demo][9]

    5. [Discovery short name][10]

    6. [Testing WebIntents][11]

    7. [Web Intents stuff][12]

    8. [Network Information][13]

    9. [Sensors][14]

    10. [Media Capture][15]

    11. [Agenda Bashing][16]

    12. [Issue Review][17]

    13. [Action Review][18]

    14. [Issue Review][19]

    15. [Action Review][20]

    16. [TPAC][21]

    17. [AOB][22]

  * [Summary of Action Items][23]

* * *

<trackbot> Date: 11 July 2012

### Wecome, admin

### WebIntents and Local Services

Claes: the intent of this document is to cover technologies beyond UPnP

... we've been prototyping with UPnP

... but it isn't limited to UPnP

... you could provide access to in device UPnP resources

... the idea is to discover UPnP services and dynamically register them

... the assumption is that UPnP devices are web-intents enabled

... there has been discussion on the list that this isn't a requirement

... we have started looking at web-intents enabled UPnP devices

... that doesn't mean we won't look into enabling existing UPnP devices

... there are pros and cons for both approaches

... the requirements for a UPnP device

... it must support an intents service type

... and it must have a location for the WebIntents document

<fjh> Web Intents Addendum - Local Services [http://w3c-test.org/dap/wi-
addendum-local-services/][24]

Claes: the other header is optional and it indicates which web intents are
supported

... so the UA could skip fetching the webintents document for all discovered
documents

... for the UA, it needs to support UPnP

... and discovery / advertisement / search / notify

... and for UA behavior, we have decided not to make this normative

... there is also a statement about UAs managing UPnP devices coming/going,
but that isn't normative

... then we have example scenarios

... there are a number of UCs

... the first UC is that a service page contains a video playback

... and the user can control video playback from the service page

... the other UC is more complicated

... where the UA continues to show the client page after the service is
invoked

... that requires a long lasting relation (communications channel) between the
client and service page

... we expect that to be channel messaging

... we made the assumption that we have disposition:hidden

... i know this is controversial

... we discussed that in Shenzhen

... i have an ACTION to propose this and cover it being secure

... that's a short introduction to the specification

[ fjh summarizes how the integration works ]

Claes: we try to minimize impact on UPnP devices

... the requirements for UPnP devices is the two headers, the web intents
registration document

... there are very limited changes needed to UPnP devices to support web
intents

fjh: are we ready to publish this?

richt: i have a few comments

... on the mDNS side

... what's the default search domain?

... what is it?

naoyuki: you mean how to search for it?

richt: one thing that would be powerful

... is to change the default search domain

... so i could query google.com

... and it discovers them by searching that domain

... it could be really powerful

<Zakim> fjh, you wanted to reiterate approach toward interop

[ richt will restate ]

richt: it would be nice if the mDNS part

... which is still a placeholder

... could go out to the web and discover services

... from dns records

... so i could say go and look at google.com and set up webintents through
that address

... that could be really nice

Claes: i agree

richt: it's called "Wide-Area Service Discovery through ZeroConf"

naoyuki: i have a question about richt's question

... what's the difference

richt: here the client, your browser could do a device search SD

... you could change the search domain from local to google.com

... so i could discover google.com services

... and they're automatically discovered

... and then i could use them when i go to a local page

naoyuki: i understand

<Zakim> Cathy, you wanted to ask whether we killed the discover action
yesterday or just the stale documentation of it

<dsr> One of easiest applications of Wide-Area DNS-SD is simply to add a few
records to your DNS server, to automatically advertise selected services to
clients, with zero configuration on the client side. When clients get a
response packet from the local network's DHCP server, there's a domain in that
packet, and clients running Mac OS X 10.4 (Tiger) or Bonjour for Windows
automatically query that domain for advertised services.

<dsr> see [http://www.dns-sd.org/][25]

Cathy: i think we killed the discovery action yesterday

... or did we kill the documentation

jhawkins: i think we killed the documentation

... i don't think it's used normally

... if UPnP uses it

gmandyam: i just joined the group

... i'm wondering

... on the appendix, A2

... there's a diagram

... that's supposed to show remote access in the video control scenario

... it shows low level control via XHR/WebSockets

... is the intention to designate a specific method for access?

... or could we just create a virtual UPnP device

Claes: i assume that question was to me

gmandyam: yeah

Claes: the discovery action was killed

... as mentioned by Cathy

gmandyam: your diagram in A2 has a link to the remote device via
XHR/WebSockets

... are you specifying a particular way

... or do we allow a multitude of ways?

Claes: this is just an example

... it's up to the implementation of the service page

... there are several ways to communicate

gmandyam: given the "work" of the CoreMob CG

... and given the behavior of networked web applications

... i'd comment that the approach here is suboptimal

... for cellular remote discovery/remote access

... is this document going to tailor testing/conformance requirements around a
preferred approach

... i'd say WebSockets isn't going to be efficient over cellular transport

... for things like SSDP and the like

Claes: that's outside the scope of this specification

gmandyam: it would be in scope of CoreMob

... i'd say the example here is probably suboptimal

... if the underlying access is cellular

darobin: whether something is optimal or not can be discussed/debated in the
design spec

... but it doesn't relate to CoreMob

gmandyam: i think CoreMob may have minimum performance specification

... it'd have some sort of level of implementation in mind

darobin: performance consideration for CoreMob are QoI not specification

... it isn't about feedback into specification

... i'm clarifying it's unrelated to what CoreMob is doing

Josh_Soref: The UPnP spec defines how interaction occurs. It doesn't define
what services provide or how they provide those services.

... Similarly HTTP doesn't specify whether you use GET or POST

... Someone defining a UPnP oriented Intent will choose what a service looks
like..whether it uses XHR, Web Sockets.

... That should be a decision for the services themselves.

... If they define a sub-optimal thing then market forces come in to play.
Some win and some lose. The specs are not key makers in that. The users are
the key makers.

gmandyam: there's been a lot of work on improving UPnP discovery over Wide-
Area-Networks

... for things including cellular connections

... there is Spotlight activity sponsored by W3

... on best practices for networked web applications

... i'd say it's perfectly appropriate to talk about the best way to do UPnP
discovery over Wide-Area-Networks

... i'd say there could be W3C documents that could cover this

Josh_Soref: For us to make a recommendation for a comms protocol between an
intents client and a UPnP/mDNS service we need to have intent services that
are UPnP. We need to experiement and get implementation experience.

... We need time and implementations and we don't have that yet.

... and they need to be real implementations not just siloed demos.

gmandyam: ok, i agree with that

richt: fjh, you were asking if we should publish this spec

... i did a similar exercise

... i think it's important we have feature completion

... the mDNS bit isn't done yet

... i'd like the mDNS stuff to be flushed out

... that can have knock-on effects

... i think feature completion in the first draft

jhawkins: sounds like we should hold off

richt: patent exclusion will apply to the FPWD

... if we add something later, it waits

Claes: i think someone should take an action to cover mDNS

... i can take that action

fjh: what sort of time frame given vacations?

<richt> **ACTION:** Claes to add mDNS adaption to the 'Web Intents Addendum -
Local Services' specification for feature completion and before FPWD [recorded
in [http://www.w3.org/2012/07/11-dap-minutes.html#action01][26]]

<trackbot> Created ACTION-555 - Add mDNS adaption to the 'Web Intents Addendum
- Local Services' specification for feature completion and before FPWD [on
Claes Nilsson - due 2012-07-18].

Claes: i'll return to work in August

### Networked Service Discovery and Messaging

<richt> [Draft spec][27]

richt: this work started quite a long time ago

... we have a lot of devices internally

... it's a way to connect to UPnP and ZeroConf devices

... restricted to the local network

... we agreed to publish a FPWD

... but we didn't publish because i wanted to wait for an implementation

... we're ready

... we're feature complete, with ZeroConf

... i don't think they're trying to do the same thing

... there's some subtle stuff we can do with the UI

... that you can't do with WebIntents

... WebIntents is about choosing a single service on a single device

... with this proposal, I can select multiple services/devices at the same
time

... i can say i want to use both of these things in one get...() call

... but the user can select more than one device

... if the user selects 2 services and 2 devices

... the page gets 4 service-device pairs

... this doesn't require a secondary tab

... with this, a service is CORS whitelisted ("same-origin") for the client

... allowing for XHR/WebSockets/...

... it's cool, it works very nicely

... it's different enough from WebIntents

... we're going to continue experimenting

... for me, it's a way to bootstrap WebIntents over discovery

... we have a separate UI

... which allows for multi-pick

... we hope to have an Opera Labs release

... at which point anyone can come along and play with it

... i'd like to get confirmation of publishing our document as an FPWD

<Zakim> fjh, you wanted to clarify relationship to earlier work

fjh: this is where the browser learns about devices on the network in the
background

richt: yes

... the browser does this in the background, w/o a performance hit

... available resources are then immediately available when the api to select
something is triggered

fjh: this seems to cover more of the discovery than the ui

richt: yes, but there is some placeholder for where a ui happens

... the assumption in WebIntents is that there's a service page

... in this proposal, it's more enabling PostMessage/XHR

fjh: when we publish it, how do we position these two documents

... your abstract seems to say something different

richt: the output of UPnP/ZeroConf is a URL

... this specification will give you an http url

... we have existing APIs for communicating with http

fjh: why was this updated july 3?

richt: as we were prototyping, we were tweaking it

fjh: so we're ready to go

... our roadmap doesn't talk about how things fit together

richt: let's get it out

darobin: sounds like the same discussion as last time

naoyuki: your approach is to expose raw SSDP/mDNS to js?

richt: no

... we hide that

... we just provide the service domain that the user has picked from the
chooser (discovery long since occurred)

naoyuki: but JS knows what device is available in the local network?

richt: no, the UA knows that

... it isn't exposed to pages

... there's one method

... the page requests stuff it wants

... the user chooses to give something back (or not)

naoyuki: if the page wants to load up available UPnP rendering devices?

richt: we don't expose how many devices are available

... we don't tell the caller how many are available

... we currently fail immediately if there's nothing available

... and we're considering offering a has() method

... but that has security/privacy implications

<richt> I believe the spec is detailed enough to explain these questions. If
there is any ambiguity then please let me know.

Josh_Soref: The assumption with these systems is the client understands the
protocol of services that it will speak to and that the service type honors a
specific protocol/messaging format?

richt: yes

... UPnP is well defined

... you have service types, each of those is very specific

... XML, HTTP based, with actions/methods

... very little room for deviation

... the same applies to zeroconf based services

... although there is more flexibility of the format in zeroconf

... but that's the flexibility of XHR

... the service chooses if it's WebSocket/XHR based

... that's what we're trying to maintain in this proposal

<Zakim> dsr, you wanted to ask why the editor's draft isn't linked from the wg
page?

darobin: it needs an update

... gallery is Shelved even though we just issued a FPWD

richt: sounds like a task for Chairs

dsr: UPnP/ZeroConf devices

... either you get back a specific service that's independent of this

... or you get something you already knew how to handle

... you have to load a library about how a device works

richt: the net products of both UPnP/ZeroConf is a control point

... you request a type and get back a URL

<Claes> No, it's difficult to hear Dave

richt: that you could XHR/Post/WebSocket to

... we're not putting UPnP in the browser

... if we take on the responsibility to maintain UPnP, we take on a lot of
work

... ultimately, UPnP is not ideal for the web

... a ZeroConf JSON RPC system is much more webby

... but the ability to do UPnP is useful

dsr: Claes is talking about a new class of UPnP/Zeroconf device

richt: his proposal is a bootstrap mechanism to register WebIntents

... and they're just web intents

dsr: it's not a built in UPnP declared service

richt: it's really just SSDP

... there's no UPnP at all

dsr: if we have existing Web-ignorant devices

... do you expect web page pages to be able to use those services?

richt: yes

dsr: when you discover a service

... you need to know how to use it

richt: you had to ask for it by that type

dsr: you'll have to do separate discovery for this?

richt: a clarification for Claes 's is that his document is just SSDP +
Intents

... there's no UPnP control/messaging

... our proposal is about UPnP messaging

dsr: in your case, there's potential to access existing devices

... UPnP/Zeroconf

richt: there's a huge difference

darobin: who gets the work to do the fpwd publishing?

richt: can we do it next week?

fjh: there's a publishing moratorium next week

... what are we calling this?

richt: "Networked Service Discovery"

<fjh> proposed RESOLUTION: publish Networked Service Discovery and Messaging
as FPWD

<dsr> The web developer would need to know about how to communicate with
zeroconf/UPnP based services, unlike Claes' proposal for web intents where
services are independent of mDNS/UPnP

**RESOLUTION: publish Networked Service Discovery and Messaging as FPWD**

[ break ]

<fjh> proposed RESOLUTION: use shortname of 'discovery' for "Networked Service
Discovery and Messaging"

<richt> [Proposed UI for 'Networked Service Discovery and Messaging' spec][28]

<richt> and [http://people.opera.com/richt/release/specs/discovery/tpac2011_se
rvicediscovery_ui_2.png][29]

### UPnP Discovery Demo

[ Sony ]

naoyuki: WebIntents connect Browser and Services

... we'd like to connect home devices

... this demo will follow Claes's spec

... We take a Web Browser and use SSDP to enable it to discover a TV that has
a SSDP Intent header

kensaku: simple case of demo

... iPhone showing a simple page

... TV case

... assume left side is displayed in tv

... we control the page in the browser

... in this demo, we use WebSockets

... this ui is coming from the tablet

[ kensaku holds up tablet that naoyuki was controlling ]

[ naoyuki holds up a mobile phone, which discovers the tablet ]

[ naoyuki controls tablet from phone ]

[ Applause ]

fjh: will you share your slides?

richt: is the demo public?

kensaku: i need to negotiate with my company

### Discovery short name

dsr: i was proposing to call it Rich Discovery

Josh_Soref: I proposed Reverse CORS

darobin: we could make it Discovery-API

... dsr was worried about it being a land grab on "discovery"

Josh_Soref: I was too

darobin: it should be lowercase

... "discovery-api"

... objections?

[ None ]

**RESOLUTION: use shortname of 'discovery-api' for "Networked Service
Discovery and Messaging"**

### Testing WebIntents

darobin: have you been doing testing?

jhawkins: we're writing an automation api

darobin: based on webdriver?

jhawkins: based on chrome's automation system

... you add an api for components to do high level things

... pick nth service

... close picker

... cancel picker

... It seems explicit intents are easier to test

... no need for advanced registration

... do we have precedents for tests that require multiple pages?

Josh_Soref: we have servers (for websockets), and multiple domains

jhawkins: what are the requirements

darobin: on testing, find all testable assertions

... figure out how many tests you need

... write all of them

... to get there, it probably requires tuning the specification

... to ensure testable assertions are testable assertions

<darobin> [A Method for Writing Testable Conformance Requirements][30]

richt: we have a spec on how to do that

... there are tools that create test suites for that

[ darobin mentions sections from test-methodology ]

richt: it's really nice to be able to create managable tests

jhawkins: wondering about timelines

darobin: we need a timeline for the spec itself

... nothing more painful to write 200 tests

... then change the spec and dump the tests

richt: the basic requirement is 2 implementations

... the other implementer may want to change everything

darobin: i'm not convinced we have the bandwidth/dire need for testing

... but it would be good to have a plan for how to move forward

... the spec is shaping up rather nicely

... it needs a lot of polish

... i'm guessing we'll need tests in early 2013

jhawkins: if we don't get another implementation by then, then we're not in a
nice place

fjh: do we need to get test infrastructure in place?

darobin: we have everything for publishing/controlling suites

fjh: what about ui interaction?

darobin: not really

jhawkins: we could take our testing api, and abstract it

fjh: that might accelerate things

darobin: IFF other browsers provide the same thing

richt: we use WebDriver, all browsers use it

jhawkins: not for UI stuff

... if we show that explicit intents covers most cases

... we can test automatically that way

darobin: we'll need part of the test suites to cover implicit intents

Josh_Soref: it's possible to make most of the test suite automatable

... and then have a small section that's manual

darobin: you can have metadata to mark manual v. automatic

... so the framework could run the automatic phase first

... the entire css test suite, or 95% of it requires human interaction

... and people do it

... it takes time, but

... it's a good way for beginners to become involved

dsr: and the same person doesn't have to do all the tests

<adrianba> +1 - manual testing is fine, especially where UI might vary between
implementations

darobin: the framework supports giving you tests with the fewest results

... it's geared toward crowd-sourcing

... as long as the human tests are reasonably few

... i think we're good

jhawkins: i'd like to put together the basic infrastructure

<adrianba> microsoft doesn't want to see w3c tests require a specific
automation api

dsr: we could also start using the markup for testable-assertions

richt: it's painful if the spec is still in flux

<jhawkins> adrianba: ack

<darobin> **ACTION:** Robin to set up test repository with example, docs,
manifest generation for Web Intents [recorded in [http://www.w3.org/2012/07/11
-dap-minutes.html#action02][31]]

<trackbot> Created ACTION-556 - Set up test repository with example, docs,
manifest generation for Web Intents [on Robin Berjon - due 2012-07-18].

darobin: it would be great if there were consensus about ui automation, but i
don't think that's possible

... i'm guessing testing specific intents

Josh_Soref: I would like to encourage, and I actually did in my original
requirements

... for service implementations and clients to provide testable instances

... if that means that there is a dummy test account, that means you can work
with it

fjh: yes, with the edge cases and all

<darobin> [Geolocation API Test Suite][32]

Josh_Soref: It would be good if we could have a test setup that attempts to
white-list the necessary test resources. Then tries to run the remaining tests
automatically.

fjh: how do we get a headstart on testing

richt: the spec needs to add testable assertions

... and be less prosy

fjh: that could happen now

... so, could darobin (Pick Contacts) and Jungkee (Pick Media) look and see if
they're using testable assertions

... so we wouldn't need to do new work later

richt: what's a good example of testable assertions?

darobin: widgets

... any editor should read the Widgets P&C spec

... at least once

... it's a pleasure to implement

<richt> Do view source on the spec to see how they added testable assertions:
[http://www.w3.org/TR/widgets/][33]

darobin: everything is defined

... and has an algorithm

<richt> (regardless of your opinion on the spec contents)

darobin: implementing widgets can be done in an afternoon

<richt> Example testable assertion from widgets spec: <p id="ta-dxzVDWpaWg">A
<a class="product-ua" href="#user-agent">user agent</a> <em
class="ct">must</em> treat any <a href="#file">file</a> in an <a
href="#arbitrary">arbitrary</a> <a href="#folder">folder</a> or <a href
="#locale-folder-0" title="locale folder">locale folders</a> that uses the
file name <code>config.xml</code> as an <a href="#arbitrary">arbitrary</a>
file.</p>

### Web Intents stuff

jhawkins: a lot of what needs to happen

... fjh posted to the list feedback about the spec itself

... good thorough, in depth

... we need more people to do that

fjh: it'd be good if people experimented

jhawkins: it'd be good to get people w/ contacts at other browsers to get
people talking

darobin: do you know if your implementation will be picked up by Safari

jhawkins: i don't know

richt: we have a situation where browsers aren't engaging on web intents

... not sure how to change it

fjh: we can progress a little with Mozilla

richt: there was confusion w/ RPC/RPH

... Google's proposal, hixie's

... not sure where to go

jhawkins: the last proposal hixie said on the list was that he liked the
<intent> tag

... and he wanted to see a registerIntentHandler similar to RPC/RPH

... we didn't really want to add it

... but if we have to, we will

richt: it'd be good to get hixie involved in the spec

jhawkins: it'd be good if you could go in as Opera saying what's holding you
back from implementing intents

### Network Information

<darobin> [The Network Information API][34]

dcheng3: how do you guys feel like proceeding with that spec?

... i understand your concern about the second one

... mozilla/mounir's proposal

... you register for onChange

... what's changing is bandwidth

... you have to constantly measure bandwidth

... that gives the user no control over data consumption

... and it will drain battery

... and there's an issue w/ .metered

... there's no reliable way to obtain that

... not sure the user will understand that

... you can't rely on the user for that

... i'd be happy reverting to the previous iteration and working from there

fjh: i don't understand

... i thought we agreed not to go on with the previous version

dcheng3: i wasn't in the group then

darobin: the reason we dropped it was we didn't have convincing UCs

<richt> [Opera feedback on Network Information API on the WHATWG mailing
list:][35]

<darobin> [Vodafone's Comments about Network Information API][36]

<mounir> doesn't Android 4 has a metered information in it's SDK?

<mounir> might be interesting to know how they get that info

Josh_Soref: There are bunch of problems with 'metered'. It's mostly broken and
can never really work well.

... Your average smartphone will be on cellular and wifi concurrently. Which
connection is used is unknown.

... if you're roaming it may cost less or more than any other network.

... the real question is "Will this data cost a lot more than usual?"

<mounir> Josh_Soref: I really can't unfortunately

<mounir> I will gladely discuss that in the mailing list though

dcheng3: we can't make a strong recommendation about what a UA will put into
the UI and how a user will respond

... the metered api is hard to implement in a meaningful/reliable way

Josh_Soref: everyone except Mounir thinks that metered can't be implemented
well.

... everyone else in DAP who has made comments has raised the same concerns.

darobin: and in CoreMob.

fjh: consensus in W3C does not require everyone to agree, do we have consensus
here?

darobin: if you can't do anything useful with the information reliably

dcheng3: if you can get more UCs

<adrianba> we have implemented an API in Windows 8 that provides information
about metered networks

darobin: what we've done in the past was Shelve specs

... like Gallery

<lgombos> from Android 4.1 documentation -
[http://developer.android.com/about/versions/jelly-bean.html][37]

<lgombos> ... Android 4.1 helps apps manage data usage appropriately when the
device is connected to a metered network, including tethering to a mobile
hotspot. Apps can query whether the current network is metered before
beginning a large download that might otherwise be relatively expensive to the
user. Through the API, you can now get a clear picture of which networks are
sensitive to data usage and manage your network activity accordingly.

adrianba: we do have a network information api as part of windows 8 for
applications

... i'm not suggesting it's the right api to expose through the browser

... it allows you to request a list of "network profiles"

... that allows you to see the different types of connections you have

... a "wifi connection", a "cellular connection"

... information about which networks are "metered"

... and whether they're "expensive"

... or whether they're "relatively low cost"

... we have a way of asking

... Josh_Soref is right, you don't know which network a packet is going to go
over

... but we have a way to ask which connection will be used for data that goes
over the "internet"

... it's not fair to say that no one here has implemented apis for metered

... it's probably something that may change too fast for a web application to
deal with

... a web application may not notice the network changing from wifi to mobile

... we're more interested in solving things that the UA can handle

... such as responsive images

... originally proposed in the Responsive Images CG

... and now taken up by HTML WG

... and the browser makes available a high quality image

... if you have high resolution screen + fast network

... and the browser+os do the heavy lifting

... rather than the web application dealing with

darobin: I agree

... that's something we discussed in CoreMob

... in talking w/ developers, the reason they wanted it was to Shim Responsive
Images themselves

... i think they're going to get it wrong at *LEAST* half the time

... i tend to agree that's something the UA should handle

... rather than scripting

... adrianba, you were giving us background

... in general, in terms of the group persuing this api or not

... do you have an opinion?

adrianba: it isn't something that's a high priority for us

... we discussed it internally for W8/IE10 planning

... we think there are some UCs for knowing this information

... what we chose for MS, was to focus on UA things first

... they'd have much more impact than we felt developers could make by using a
JS api

... we don't see it as a high priority right now

<darobin> ACTION-474?

<trackbot> ACTION-474 -- Travis Leithead to make a proposal for Network
Information API -- due 2011-11-11 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/474][38]

adrianba: it's something we might return to once we've done the more UA based
scenarios

darobin: if we were to leave that spec in a corner, and not touch it

adrianba: I'm not sure why that action was on travis

Josh_Soref: I think that's because adrianba wasn't targetable

darobin: i'll assign it to you with a deadline of Oct 15 (before TPAC)

adrianba: sure

darobin: thank you very much

... i'm hearing a low level of interest, nothing urgent

... we might see some movement towards the end of the year

... so we can not touch it and go to lunch

[ Lunch until 1:10 pm ]

### Sensors

fjh: anyone have anything to say about sensors?

darobin: temperature is probably an Intent

... pressure similarly

... humidity

... we already did proximity

... we had a proposal to do light as a media query

fjh: dougt had a proposal to do light as a sensor

<fjh> [http://dougturner.wordpress.com/2012/03/26/device-light-sensor/][39]

<fjh> [http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html][40]

darobin: i'm happy to talk to dougt to know if he wants to take this further

dsr: we're a standards body

Josh_Soref: light sensors should just be done by the OS/UA

... instead of making each web page try to respond and have them mess up

<darobin> **ACTION:** Robin to ping DougT about light sensor to see if there's
interest [recorded in [http://www.w3.org/2012/07/11-dap-
minutes.html#action03][41]]

<trackbot> Created ACTION-557 - Ping DougT about light sensor to see if
there's interest [on Robin Berjon - due 2012-07-18].

### Media Capture

fjh: this is a document produced in the Media Capture TF

... this isn't the TF

<fjh> Updates to MediaStream Capture Scenarios document,
[http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-
capture/scenarios.html][42]

<fjh> Media Capture and Streams WD, [http://www.w3.org/TR/2012/WD-
mediacapture-streams-20120628/][43]

darobin: there's stuff going on in the TF, which the group implicitly backs

... i believe we have multiple parties in the room who are interested in this
topic

Cathy: did travis say he'd participate in this?

<darobin> "Travis Leithead I will attend remotely as noted below Plan on
calling in for the Media Capture discussions."

<darobin> close ISSUE-121

<trackbot> ISSUE-121 Scope of sensor API and sensor discovery closed

<darobin> close ISSUE-105

<trackbot> ISSUE-105 Should the capture hint in HTML Media Capture be
specified through a MIME parameter? closed

fjh: we know that there were updates to the Scenarios document

... and to the Specification

darobin: Travis: since you've been involved w/ the TF

... could we get your feeling on where it's going?

Travis: high level, it's moving in the right direction

... albeit slowly

... the scenarios document was stalled

... until i got help from the chairs, and I believe Jim made edits

... the current document has a set of requirements in 4 categories

... Permissions, Local Media, Remote Media, Media Capture

darobin: you mentioned it moving slowly

... that's also my perception

... i remember @TPAC people said "yeah yeah, we want to wrap this up, in 2
months"

... we're 2 months before TPAC

... i'm not sure if there's anything we should do, or just leave the TF to its
own devices

Travis: what i'm looking for at this point

... is a revised way to do a recording from GetUserMedia

<darobin> [http://dev.w3.org/2011/webrtc/editor/getusermedia.html][44]

darobin: "Media Capture and Streams"

Travis: we pulled in the definition of media stream

... which is a good deal

... and pull in changes on Tracks

... the missing piece here

... is a definition for recording the stream

... there was a proposal made on the list

... which excited me

... i think it was richt, from Opera?

... i'd love to see the recorder api integrated into the api

... instead of just having an email thread

... then we could compare it against the Media Capture Requirements which are
in the Requirements Doc

... producing the Scenarios doc is one of the criteria for the TF

... i'm not sure what else it needs

... if we can get that accomplished, maybe we can wind down the TF

... and move back to doing work in DAP/WebRTC

... the TF is joint ownership, what happens when the TF is done?

darobin: once we have joint ownership, we have joint ownership for life

... TF is just a medium for coordination

richt: i'm not sure it's my name on the proposal

... i support Travis, i want to see that come to the spec

... it's the next logical step for us as well

darobin: could Stream Recorder be a separate spec?

richt: it could be

darobin: ... to avoid excessive coordination

richt: MS had a Stream API with that capability

... i don't know what they want to do

darobin: i think that's in WebApps

adrianba: yes, it's in Web Apps

... it hasn't made progress

... we haven't pushed it

darobin: that supports recording, right?

adrianba: it supports pipes

... it's an abstract stream api

richt: i'm willing to jump in as an editor

... there's interesting stuff there: Codecs and Constraints. Those aspects
complicate things considerably.

<darobin> **ACTION:** Richt to produce a proposal draft for a StreamRecorder
API [recorded in [http://www.w3.org/2012/07/11-dap-minutes.html#action04][45]]

<trackbot> Created ACTION-561 - Produce a proposal draft for a StreamRecorder
API [on Richard Tibbett - due 2012-07-27].

Travis: where did constraints end up?

... is it in an ED?

Josh_Soref: i think so

gmandyam: was there more discussion in the group beyond the Still Image
capture in the docs

... for instance still image requires higher camera quality

Travis: we could use the existing Media Capture and Stream spec

... and then start working on the Capture spec

darobin: the problem is

... if you have a stream coming from the device

... you often have to interrupt it to capture a proper still

gmandyam: that's why a preview from a device would be different for Video
Telephony and Snapshot

Travis: that was my original concern about the original api

gmandyam: so you're looking for a proposal?

Travis: yes

darobin: i'd expect StreamRecorder to be completely independent as to where
the stream comes from

... i don't understand how it'd be a view-finder stream

... and somehow tell the camera that it should stop producing a video feed and
make a proper still capture

... it seems solving that at the stream recorder level is architecturally
wrong

Travis: i haven't thought about that in detail, but that's a good question

... there hasn't been a way to make a snapshot

richt: the way to take a high quality snapshot is with HTML Media Capture

... you get a native controls view finder

<Zakim> darobin, you wanted to talk about pictures

Travis: there's some sort of signalling mechanism that could send a signal to
configure a Photo frame

darobin: that sounds scary

... maybe i should try to draft a proposal, and see if it sticks

Travis: the concept i'm remembering is a constructable object that takes a
mediastream/track

... and could let you export out a stream/bitstream or be notified the
stream/blob when it has ended

... you put in the constraints you want

... and it tries its best

darobin: it seems rather complicated

<darobin> **ACTION:** Robin to draft a proposal for stills capture for gUM
[recorded in [http://www.w3.org/2012/07/11-dap-minutes.html#action05][46]]

<trackbot> Created ACTION-558 - Draft a proposal for stills capture for gUM
[on Robin Berjon - due 2012-07-18].

Josh_Soref: ahm... do we have heavy use cases for actually switching from
video streaming to taking a picture

... that aren't cases where it makes sense to interrupt the stream and restart
it

... ?

adrianba: at the risk of sounding like a broken record

... we implemented an api like this in windows

... that allows for you to set up the video capture stream

... from the device camera

... into a preview window

... and then the ability to call a method to say

... at this point i want to capture a photo

... from that same device

... and it asynchronously goes to figure out where to get the data

... we leave it as an implementation decision

... whether it's a frame grab

... or it does something more sophisticated

... changing the decoding mode of the sensor

... the key reason we care about this

... is to support building capture applications where the ui is determined by
the application

... in the browser, or something using the web platform

... let the application control where the preview is

... and where the controls are

... rather than delegating to the UA

... avoiding click-click-click for a single action

... so you can capture multiple frames quickly

darobin: i agree

... typical UC is a realtime Instagram

... so you could show a preview

... and then also take and immediately apply the filter to the output

adrianba: we wanted to be able to wire up a preview to a canvas

... do manipulations

... frame grab/applying filters

... that doesn't account for the case where you want the higher resolution
still image

<adrianba> [http://msdn.microsoft.com/en-
us/library/windows/apps/windows.media.capture.mediacapture.aspx][47]

darobin: we have an overview of the situation

... at least one or two Action Items

... do we need anything else?

richt: do you want to talk about recording?

... two issues

... first is Codecs

... if you're going to record something, it's going to be in some codec

... second thing is constraints

... i've argued against constraints

... at initial request

... i want them at secondary usage

... recording/(p2p)streaming

... constraints have way too many moving parts

... i'd love for a way to simplify that

... i'd like for thoughts on these

Travis: we've maintained a position that the api should be codec-agnostic

... we don't want to get into that discussion

... we do want to understand that various implementations want to capture
streams in a form convenient for their platform

... it passes the buck a little bit

... if you want to do really low level work on a recorded bit

... you need to understand the underlying structure

... you'd have to dig into the underlying format

fjh: i agree w/ Travis

... if it's pluggable

... you can add new things w/o changing the spec

... i assume you're worried about interop

richt: exactly, we should have some selection ability

darobin: it isn't a problem we can solve

<fjh> agree that we cannot solve the codec problem

richt: there was feedback on the mailinglist about constraints

... which was ignored

... and i've pulled out a bit

Travis: we should reopen that for discussion

... at least to the point that there was silence on the TF

... and so that we could at least agree to disagree

darobin: it'd be nice if richt could make the point about privacy

richt: the spec says you can choose media constraints at the time you request
a media stream

... e.g. minimum width/height

... if you combine those constraints

... you exclude 80-90% of the users of the web

darobin: so you could fingerprint them

richt: privacy is another thing

... you understand who they are even before the log in

... and you know who they are later

... but most likely the form you use when developing

... will not match the devices that people have on the web

... and will thus exclude most of the web

... there are so many constraints

... and it's easy to combine them to exclude many users

... and that's why opera won't implement them

adrianba: back to the codec problem

... i think we probably all agree

... that this isn't a problem that we can solve

... as Travis said, from our perspective

... we don't want to do things from a mandatory thing

... in practice, there will be very few natively supported formats

... i think what will be important are ways to discover native capabilities of
the device

... i think there will be some way to have a selection and make it
discoverable

<richt> +1

adrianba: possibly the best thing, and possibly the preferred approach anyway

fjh: i share richt 's concern about capabilities constraints

... not sure how we'd test all the combinations

... the argument for this

... is that if you're trying to provide an application

... you're trying to ...

... 1. there's a privacy concern re: Fingerprinting

... 2. there's a complexity thing for testing which will make it hard to reach
REC

... 3. i'm concerned about the strength of he use case to support this

... i understand there's a UC but i don't know that it justifies that much
complexity

dsr: instead of constraints

... an application might provide human readable hints

... and let the user select something

richt: hints has a bad wrap

dsr: an application gives the user hints about what it's looking for

... and let the user use their own common sense

richt: i like hints a lot

... if the UA can do it, it'll work

... if not, it'll give you best effort

... at least everyone on the web can use that web page

dsr: you're advocating machine interpretable hints

richt: yes

... if you define an application that requires high-def

... you've excluded most of the world

Travis: on record, i support richt 's argument

... it seems like the API could be better served by "best effort" and
"upgrade"

... like WebSockets

... HTTP + Upgrade => WebSockets

... in this case, give me a video

... and then i try to upgrade it

... it imposes more of a requirement to the stream interaction model

... but it allows for more users to consume the api

<Zakim> adrianba, you wanted to say something that travis might get to before
me

adrianba: the good way to do this

... is start simple and add enhancements

... from an implementer perspective

... we don't need constraints

... to have useful scenarios

... it's likely something we'd have implementations without that to begin with

<fjh> +1

adrianba: we'd have to discuss whether to include it before we ship

... starting simple is a principle i think that's important

<darobin> +1, start as simple as needed for success, push rest to v.next

adrianba: in the end, it'll be down to implementations

... it might be a feature marked AT-RISK

... so when it goes to CR, it could be pulled from the spec

<Zakim> fjh, you wanted to mention that best effort may mitigate privacy
concern

fjh: i think Travis has a good point

... best effort may get around privacy concerns

... wrt TF

... my take is that some people promoting this work

... felt very strongly about it

... not sure how to deal w/ the politics

... i'm a little concerned with marking things at-risk

... it's better to try to enter CR w/ stuff you think is going to make REC

... i'm not excited about marking things AT-RISK from the beginning

... i'd rather do things like that using v.Next

... i think doing it that way is confusing for testing and resources

darobin: i tend to agree w/ fjh

... if it's a feature a lot of people/implementers think isn't useful for this
version

... if it's something implementers don't want

... it should be dropped now

richt: it isn't unanimous, which is a confusing factor. But there isn't
consensus either.

fjh: next step is to raise this issue to the TF

... to make it clear that there's an issue

... and make an explicit decision now

... we don't really vote

... we can do it, but we haven't

... i know paul knows all about this

darobin: the mechanism open to people who don't like to it is a Formal
Objection

fjh: either we formally object

... or do a poll who can live w/ it / who can't

... we have a mechanism for dealing w/ a think where people can't reach a
consensus

<Zakim> Josh_Soref, you wanted to note that the api in MC TF was headed that
way

Josh_Soref: So constraints, a background story.

... the task force is being driven by, essentially, device vendors e.g. media
conferencing solution providers.

<richt> ...their preference is for hard-coded preference styles.

Josh_Soref: browser vendors don't find these particularly great.

... we've been talking about moving contraints further down the pipeline /
switch constraints at those points.

... what happens when the input stream is a peer stream and you want to change
the quality of the peer's stream?

... this is really renegotiation which happens at the point of streaming.

... There's definitely the possibility to move constraints in to its own spec.

... there's also the caveat where implementors are allowed to opt-out of
implementation requirements.

... they have the ability to ignore implementation requirements where they
need to.

... in my opinion, they're not vocal enough and they don't exercise this
option enough.

fjh: i'd hate to ask about compliance

Josh_Soref: that came up in CoreMob

... we don't do Compliance

darobin: right, we do Interop

... there's no reason to do Red if you're only b/w

richt: we're exercising our right not to follow the spec at this point

fjh: Josh_Soref is pointing out that the spec is moving to moving to later
along the line

... it's hard to keep up

... the TF should make clear if they're moving constraints to relaxed

... and renogatiable

... Travis, does that make sense to you?

adrianba: i wasn't suggesting marking something as AT-RISK as a way not to
make a decision

... i was assuming that we'd do a LC process where we mark things AT-RISK

... but CR is a call for implementations

... if there's a consensus that it's a feature worth having

... but it isn't a clear that people will ship such a feature

... then i think it's fair to mark something at risk

fjh: that makes sense, but we should try to resolve earlier if we can

richt: that's exactly what we're saying

... we don't want to wait until that

... CR is our best intentions

... but we can't endorse something we think is patently wrong

adrianba: things don't land in the spec by accident

Travis: i'm glad things landed in the spec so we can discuss

... we have a chance to make the right changes

... i think richt has an action

... i'll bring up a concern about constraints to the TF

... i'll bring up next steps about a recording proposal

darobin: thanks

[ Break ]

<fjh> [15 min break]

### Agenda Bashing

fjh: i don't think there's anything to do tomorrow

... the agenda has Issues, action review

### Issue Review

issue-116?

<trackbot> ISSUE-116 -- HTML Media Capture doesn't make sense if accept=image
and capture=microphone -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/116][48]

<darobin> "The HTMLInputElement interface's accept attribute takes precedence
over the capture attribute. That is, if the accept attribute's value is set to
a MIME type that is not accepted in a defined capture state, the user agent
must act as if there was no capture attribute. "

<fjh> There is no reason to continue a meeting when it is finished with its
work - so we will conclude today and not meet tomorrow given that we
progressed quickly through the agenda.

<fjh> This will give time back to people for other work, travel, etc

darobin: any objection?

Josh_Soref: i agree w/ the spec and agree that the issue can be closed

issue-116: "The HTMLInputElement interface's accept attribute takes precedence
over the capture attribute. That is, if the accept attribute's value is set to
a MIME type that is not accepted in a defined capture state, the user agent
must act as if there was no capture attribute."

<trackbot> ISSUE-116 HTML Media Capture doesn't make sense if accept=image and
capture=microphone notes added

close issue-116

<trackbot> ISSUE-116 HTML Media Capture doesn't make sense if accept=image and
capture=microphone closed

<fjh> ISSUE-116: addressed this issue in the spec as noted above

<trackbot> ISSUE-116 HTML Media Capture doesn't make sense if accept=image and
capture=microphone notes added

issue-117?

<trackbot> ISSUE-117 -- Should HTML Media Capture have options for front/user
camera as in getUserMedia -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/117][49]

<richt> user/environment features is not in gUM. We would like to see that
make a reappearance.

<richt> more: Josh_Soref:

<richt> more: [http://www.brucelawson.co.uk/2012/specifying-which-camera-in-
getusermedia/][50]

close issue-117

<trackbot> ISSUE-117 Should HTML Media Capture have options for front/user
camera as in getUserMedia closed

<darobin> ISSUE-117: group agrees that this is not needed, handled by the UA

<trackbot> ISSUE-117 Should HTML Media Capture have options for front/user
camera as in getUserMedia notes added

<adrianba> a picture taking app might favour back camera, a video chat might
favour front camera

Josh_Soref: if i have a playbook using HDMI to display the video chat or
camera app

... the front and back cameras are no longer tied to the "Front/Back" of my
display

... and thus the hint is wrong/useless

... I'd rather just have UAs do sane things, including at least a frame
preview from all sources

... The user always needs to pick something (or not), so let them have a
preview from the sources, and they can window shop just like real people.

... although that's a UA QoI

darobin: we've run out of issues

### Action Review

<fjh> [http://www.w3.org/2009/dap/track/actions/open][51]

### Issue Review

<fjh> [http://www.w3.org/2009/dap/track/issues/raised][52]

darobin: We always forget about Raised issues

fjh: I've moved them to open

issue-120?

<trackbot> ISSUE-120 -- How to handle exposing single vs multiple sensors of
the same type -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/120][53]

close issue-120

<trackbot> ISSUE-120 How to handle exposing single vs multiple sensors of the
same type closed

<darobin> ISSUE-120: form an old Sensor API

<trackbot> ISSUE-120 How to handle exposing single vs multiple sensors of the
same type notes added

<fjh> ISSUE-122?

<trackbot> ISSUE-122 -- Is low level data necessary for all sensor APIs, which
ones have use cases and which not -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/122][54]

<darobin> ISSUE-122: this is already handled

<trackbot> ISSUE-122 Is low level data necessary for all sensor APIs, which
ones have use cases and which not notes added

close issue-122

<trackbot> ISSUE-122 Is low level data necessary for all sensor APIs, which
ones have use cases and which not closed

<fjh> ISSUE-123?

<trackbot> ISSUE-123 -- Low level discovery API security and privacy issues --
open

<trackbot> [http://www.w3.org/2009/dap/track/issues/123][55]

<fjh> ISSUE-123: we consider security and privacy for all specs

<trackbot> ISSUE-123 Low level discovery API security and privacy issues notes
added

close issue-123

<trackbot> ISSUE-123 Low level discovery API security and privacy issues
closed

<fjh> ISSUE-124?

<trackbot> ISSUE-124 -- Concern on exposing raw sensor data -- open

<trackbot> [http://www.w3.org/2009/dap/track/issues/124][56]

<fjh> ISSUE-124: solved by shelving

<trackbot> ISSUE-124 Concern on exposing raw sensor data notes added

close issue-124

<trackbot> ISSUE-124 Concern on exposing raw sensor data closed

issue-125: This applies to GetUserMedia Constraints

<trackbot> ISSUE-125 Capabilities API compatibility with web privacy and
security, assuming untrusted, fingerprinting risk notes added

### Action Review

ACTION-391?

<trackbot> ACTION-391 -- Dominique Hazaël-Massieux to look at overlap between
MediaFileData and HTMLVideoElement -- due 2011-04-27 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/391][57]

<fjh> [https://www.w3.org/2009/dap/track/actions/open][58]

darobin: should i email dom if he still wants to do it?

fjh: sure

ACTION-422?

<trackbot> ACTION-422 -- Robin Berjon to draft the design decision motivating
using a new input type=foo or not for a given feature -- due 2011-07-26 --
OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/422][59]

<darobin> close ACTION-422

<trackbot> ACTION-422 Draft the design decision motivating using a new input
type=foo or not for a given feature closed

ACTION-459?

<trackbot> ACTION-459 -- Sakari Poussa to draft a proposal for a threshold
parameter for Battery events -- due 2011-11-10 -- CLOSED

<trackbot> [http://www.w3.org/2009/dap/track/actions/459][60]

ACTION-439?

<trackbot> ACTION-439 -- Bryan Sullivan to draft use cases for proximity,
ambient light, and ambient sound sensors. -- due 2011-07-27 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/439][61]

close ACTION-439

<trackbot> ACTION-439 Draft use cases for proximity, ambient light, and
ambient sound sensors. closed

action-446?

<trackbot> ACTION-446 -- Frederick Hirsch to review security issue
[http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0006.html][62]
-- due 2011-08-24 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/446][63]

action-464?

<trackbot> ACTION-464 -- Robin Berjon to follow up with Alex Russell on
getting an example of sensors on Intents. -- due 2011-11-10 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/464][64]

action-464: we have examples of sensors on intents

<trackbot> ACTION-464 Follow up with Alex Russell on getting an example of
sensors on Intents. notes added

close action-464

<trackbot> ACTION-464 Follow up with Alex Russell on getting an example of
sensors on Intents. closed

action-465?

<trackbot> ACTION-465 -- Jose Manuel Cantera Fonseca to present use cases for
the Sensors API -- due 2011-11-10 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/465][65]

close action-465

<trackbot> ACTION-465 Present use cases for the Sensors API closed

<fjh> ACTION-464: thermometer / temperatture

<trackbot> ACTION-464 Follow up with Alex Russell on getting an example of
sensors on Intents. notes added

action-468?

<trackbot> ACTION-468 -- Robin Berjon to look as Mozilla Labs Sharing
experimentation re Messaging API -- due 2011-11-10 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/468][66]

darobin: it doesn't seem like even by using an intent

... there's any value beyond what uri schemes provide

... we discussed this at length w/ Jungkee

... the only thing extra you can do is attachments

... that doesn't seem to justify a Spec

close action-468

<trackbot> ACTION-468 Look as Mozilla Labs Sharing experimentation re
Messaging API closed

action-468: it's shelved

<trackbot> ACTION-468 Look as Mozilla Labs Sharing experimentation re
Messaging API notes added

action-472?

<trackbot> ACTION-472 -- Frederick Hirsch to update policy requirements for
security requirements -- due 2011-11-11 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/472][67]

close action-472

<trackbot> ACTION-472 Update policy requirements for security requirements
closed

<fjh> ACTION-472: policy requirements are gone

<trackbot> ACTION-472 Update policy requirements for security requirements
notes added

action-473?

<trackbot> ACTION-473 -- Robin Berjon to coordinate with fjh on the production
of a "General Security Principles in Web APIs Design" Note -- due 2011-11-11
-- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/473][68]

action-474?

<trackbot> ACTION-474 -- Adrian Bateman to make a proposal for Network
Information API -- due 2012-10-15 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/474][38]

fjh: darobin and i just coordinated

<darobin> [http://darobin.github.com/api-design-privacy/api-design-
privacy.html][69]

fjh: we just gave it to adrianba

action-483?

<trackbot> ACTION-483 -- Josh Soref to send proposal to list for how Contacts
will move forward -- due 2011-11-11 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/483][70]

<fjh> ACTION-483: moot, we now have Pick Intents as way forward

<trackbot> ACTION-483 Send proposal to list for how Contacts will move forward
notes added

close action-483

<trackbot> ACTION-483 Send proposal to list for how Contacts will move forward
closed

<fjh> ACTION-485?

<trackbot> ACTION-485 -- Sakari Poussa to ask Phonegap users to send feedback
on find() -- due 2011-11-11 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/485][71]

action-485?

<trackbot> ACTION-485 -- Sakari Poussa to ask Phonegap users to send feedback
on find() -- due 2011-11-11 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/485][71]

close action-485

<trackbot> ACTION-485 Ask Phonegap users to send feedback on find() closed

action-510?

<trackbot> ACTION-510 -- Claes Nilsson to create new spec how WebIntents UPnP
registration -- due 2012-03-27 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/510][72]

<fjh> ACTION-485: moot, have pick intents

<trackbot> ACTION-485 Ask Phonegap users to send feedback on find() notes
added

action-510: Claes did this

<trackbot> ACTION-510 Create new spec how WebIntents UPnP registration notes
added

close action-510

<trackbot> ACTION-510 Create new spec how WebIntents UPnP registration closed

action-511?

<trackbot> ACTION-511 -- Giuseppe Pascale to figure out how to put together a
document describing how to do Intents with existing UPnP (himself or by
finding someone who does it) -- due 2012-03-27 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/511][73]

fjh: i'll assign it to claes, he volunteered to do it today

action-512?

<trackbot> ACTION-512 -- Robin Berjon to propose linking to "Privacy by Design
in APIs" from Web Intents draft when it's ready -- due 2012-03-27 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/512][74]

action-512: jhawkins notes there's a section "privacy considerations" and a
link to "dap privacy requirements"

<trackbot> ACTION-512 Propose linking to "Privacy by Design in APIs" from Web
Intents draft when it's ready notes added

<darobin> [http://darobin.github.com/api-design-privacy/api-design-
privacy.html][69]

close action-512

<trackbot> ACTION-512 Propose linking to "Privacy by Design in APIs" from Web
Intents draft when it's ready closed

Josh_Soref: darobin has proposed linking to jhawkins (url above)

action-514?

<trackbot> ACTION-514 -- Robin Berjon to talk to the Web Schema group about
using schema.org nouns for Intents -- due 2012-03-27 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/514][75]

darobin: i have an open channel to danbri

action-516?

<trackbot> ACTION-516 -- Josh Soref to propose Security Considerations section
on SSL for Intents sepc -- due 2012-03-27 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/516][76]

<darobin> ACTION-516 due 2012-07-18

<trackbot> ACTION-516 Propose Security Considerations section on SSL for
Intents sepc due date now 2012-07-18

<fjh> the tools are cool

action-519?

<trackbot> ACTION-519 -- Claes Nilsson to add a proposal for hidden
disposition. -- due 2012-03-28 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/519][77]

action-519 due 2012-08-15

<trackbot> ACTION-519 Add a proposal for hidden disposition. due date now
2012-08-15

action-520?

<trackbot> ACTION-520 -- Frederick Hirsch to look at WS* to see what might be
relevant -- due 2012-03-28 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/520][78]

close action-520

<trackbot> ACTION-520 Look at WS* to see what might be relevant closed

<fjh> ACTION-520: overtaken by progress in WebIntents

<trackbot> ACTION-520 Look at WS* to see what might be relevant notes added

action-521?

<trackbot> ACTION-521 -- Claes Nilsson to coordinate with UPnP forum about
extensions required for Intents -- due 2012-03-28 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/521][79]

close action-521

<trackbot> ACTION-521 Coordinate with UPnP forum about extensions required for
Intents closed

<darobin> ACTION-522 due 2012-08-31

<trackbot> ACTION-522 Write tests for Battery due date now 2012-08-31

action-522?

<trackbot> ACTION-522 -- Robin Berjon to write tests for Battery -- due
2012-08-31 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/522][80]

<fjh> ACTION-521: completed ln latest Addendum, minimized need for extensions

<trackbot> ACTION-521 Coordinate with UPnP forum about extensions required for
Intents notes added

<darobin> ACTION-523 due 2012-08-31

<trackbot> ACTION-523 Work on test cases for battery and vibration due date
now 2012-08-31

darobin: i'm still doing that

action-524?

<trackbot> ACTION-524 -- Robin Berjon to prepare charter for system level APIs
-- due 2012-03-28 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/524][81]

<fjh> ACTION-524: done

<trackbot> ACTION-524 Prepare charter for system level APIs notes added

close action-524

<trackbot> ACTION-524 Prepare charter for system level APIs closed

action-528?

<trackbot> ACTION-528 -- Richard Tibbett to provide more use cases for
Networked Service Discovery -- due 2012-05-04 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/528][82]

close action-528

<trackbot> ACTION-528 Provide more use cases for Networked Service Discovery
closed

<fjh> ACTION-528: see
[http://people.opera.com/richt/release/specs/discovery/Overview.html#use-
cases-and-requirements][83]

<trackbot> ACTION-528 Provide more use cases for Networked Service Discovery
notes added

action-529?

<trackbot> ACTION-529 -- Claes Nilsson to work with greg and bryan on
investigating white list/CORS for networked services -- due 2012-03-29 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/529][84]

<fjh> ACTION-529: solved in spec in different way

<trackbot> ACTION-529 Work with greg and bryan on investigating white
list/CORS for networked services notes added

close action-529

<trackbot> ACTION-529 Work with greg and bryan on investigating white
list/CORS for networked services closed

action-532?

<trackbot> ACTION-532 -- Dave Raggett to collect use cases for qrcodes in web
context -- due 2012-03-29 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/532][85]

close action-532

<trackbot> ACTION-532 Collect use cases for qrcodes in web context closed

<fjh> ACTION-532: QR codes not in DAP

<trackbot> ACTION-532 Collect use cases for qrcodes in web context notes added

action-533?

<trackbot> ACTION-533 -- Jungkee Song to gather use cases for Gallery API --
due 2012-03-29 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/533][86]

close action-533

<trackbot> ACTION-533 Gather use cases for Gallery API closed

<fjh> ACTION-533: spec unshelved, see demo [http://www.w3.org/2009/dap/wiki/im
ages/2/2e/20120711-WebIntentsLocalServiceDemo.pdf][87]

<trackbot> ACTION-533 Gather use cases for Gallery API notes added

action-535?

<trackbot> ACTION-535 -- Robin Berjon to ask Intents TF if they want to join
our f2f -- due 2012-05-02 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/535][88]

close action-535

<trackbot> ACTION-535 Ask Intents TF if they want to join our f2f closed

close action-536

<trackbot> ACTION-536 Ask gUM TF if they want to join our f2f closed

<fjh> ACTION-535: done

<trackbot> ACTION-535 Ask Intents TF if they want to join our f2f notes added

<fjh> ACTION-536: done

<trackbot> ACTION-536 Ask gUM TF if they want to join our f2f notes added

action-535: they joined

<trackbot> ACTION-535 Ask Intents TF if they want to join our f2f notes added

action-536: they didn't join

<trackbot> ACTION-536 Ask gUM TF if they want to join our f2f notes added

<fjh> ACTION-536: done

<trackbot> ACTION-536 Ask gUM TF if they want to join our f2f notes added

action-544?

<trackbot> ACTION-544 -- Dave Raggett to widen editing privileges for editing
webIntents -- due 2012-06-27 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/544][89]

close action-544

<trackbot> ACTION-544 Widen editing privileges for editing webIntents closed

action-544: dsr did this

<trackbot> ACTION-544 Widen editing privileges for editing webIntents notes
added

<darobin> ACTION-552 product WebIntents

<darobin> ACTION-552 associated with WebIntents

<darobin> ACTION-552 is associated with WebIntents

ACTION-553: is related to ACTION-516

<trackbot> ACTION-553 Summarize issue and rationale regarding SSL for inlined
webintents content notes added

ACTION-555 due 2012-08-15

<trackbot> ACTION-555 Add mDNS adaption to the 'Web Intents Addendum - Local
Services' specification for feature completion and before FPWD due date now
2012-08-15

Josh_Soref: Team needs to force DVCS to force only one head allowed, mozilla
does this for mozilla-central

<darobin> **ACTION:** Robin to ask team if they can set up Mercurial so that
only one head is allowed [recorded in [http://www.w3.org/2012/07/11-dap-
minutes.html#action06][90]]

<trackbot> Created ACTION-559 - Ask team if they can set up Mercurial so that
only one head is allowed [on Robin Berjon - due 2012-07-18].

<adrianba> [http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_push_tha
t_would_create_multiple_heads][91]

Josh_Soref: yay!

### TPAC

<Cathy> [http://www.w3.org/2012/10/TPAC/][92]

fjh: what's the requirement for when an agenda should be published

<darobin> ACTION-555: [http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent
_a_push_that_would_create_multiple_heads][91]

<trackbot> ACTION-555 Add mDNS adaption to the 'Web Intents Addendum - Local
Services' specification for feature completion and before FPWD notes added

<darobin> ACTION-559: [http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent
_a_push_that_would_create_multiple_heads][91]

<trackbot> ACTION-559 Ask team if they can set up Mercurial so that only one
head is allowed notes added

fjh: we need to plan for joint slots

Josh_Soref: can we start w/ a plan to do a joint slot w/ WebRTC

<richt> ACTION-555: for reference previous comment was added to the wrong
action.

<trackbot> ACTION-555 Add mDNS adaption to the 'Web Intents Addendum - Local
Services' specification for feature completion and before FPWD notes added

Josh_Soref: so, we plan to do WebIntents in DAP

... the 35 pencilled in for us for TPAC seems too low

darobin: last year we were 60+

Josh_Soref: we should ask for a bigger number

darobin: we had more people than HTML

... and with webintents, we'll be big

### AOB

**RESOLUTION: We thank our hosts for the wonderful hosting**

<richt> thanks!

[ Applause ]

**RESOLUTION: We thank the scribe**

[ Applause ]

darobin: thanks to everyone on the phone

**RESOLUTION: No meeting tomorrow**

[ Adjourned ]

trackbot, end meeting

## Summary of Action Items

**[NEW]** **ACTION:** Claes to add mDNS adaption to the 'Web Intents Addendum
- Local Services' specification for feature completion and before FPWD
[recorded in [http://www.w3.org/2012/07/11-dap-minutes.html#action01][26]]

**[NEW]** **ACTION:** Richt to produce a proposal draft for a StreamRecorder
API [recorded in [http://www.w3.org/2012/07/11-dap-minutes.html#action04][45]]

**[NEW]** **ACTION:** Robin to ask team if they can set up Mercurial so that
only one head is allowed [recorded in [http://www.w3.org/2012/07/11-dap-
minutes.html#action06][90]]

**[NEW]** **ACTION:** Robin to draft a proposal for stills capture for gUM
[recorded in [http://www.w3.org/2012/07/11-dap-minutes.html#action05][46]]

**[NEW]** **ACTION:** Robin to ping DougT about light sensor to see if there's
interest [recorded in [http://www.w3.org/2012/07/11-dap-
minutes.html#action03][41]]

**[NEW]** **ACTION:** Robin to set up test repository with example, docs,
manifest generation for Web Intents [recorded in [http://www.w3.org/2012/07/11
-dap-minutes.html#action02][31]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][93] version 1.135 ([CVS
log][94])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]:
http://www.w3.org/2009/dap/wiki/F2F_Agenda_10-12_July_2012_Burlington_MA_USA

   [4]: http://www.w3.org/2012/07/11-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #item10

   [16]: #item11

   [17]: #item12

   [18]: #item13

   [19]: #item14

   [20]: #item15

   [21]: #item16

   [22]: #item17

   [23]: #ActionSummary

   [24]: http://w3c-test.org/dap/wi-addendum-local-services/

   [25]: http://www.dns-sd.org/

   [26]: http://www.w3.org/2012/07/11-dap-minutes.html#action01

   [27]: http://people.opera.com/richt/release/specs/discovery/Overview.html

   [28]: http://people.opera.com/richt/release/specs/discovery/tpac2011_servic
ediscovery_ui_1.png

   [29]: http://people.opera.com/richt/release/specs/discovery/tpac2011_servic
ediscovery_ui_2.png

   [30]: http://www.w3.org/TR/test-methodology/

   [31]: http://www.w3.org/2012/07/11-dap-minutes.html#action02

   [32]: http://dev.w3.org/geo/api/test-suite/

   [33]: http://www.w3.org/TR/widgets/

   [34]: http://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

   [35]: http://lists.whatwg.org/htdig.cgi/whatwg-
whatwg.org/2012-May/036116.html

   [36]: http://www.w3.org/mid/2E8CF18B8D02DF469D2EDBBCCA0B5D33F2BA79@VF-
MBX39.internal.vodafone.com

   [37]: http://developer.android.com/about/versions/jelly-bean.html

   [38]: http://www.w3.org/2009/dap/track/actions/474

   [39]: http://dougturner.wordpress.com/2012/03/26/device-light-sensor/

   [40]: http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html

   [41]: http://www.w3.org/2012/07/11-dap-minutes.html#action03

   [42]: http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-
capture/scenarios.html

   [43]: http://www.w3.org/TR/2012/WD-mediacapture-streams-20120628/

   [44]: http://dev.w3.org/2011/webrtc/editor/getusermedia.html

   [45]: http://www.w3.org/2012/07/11-dap-minutes.html#action04

   [46]: http://www.w3.org/2012/07/11-dap-minutes.html#action05

   [47]: http://msdn.microsoft.com/en-
us/library/windows/apps/windows.media.capture.mediacapture.aspx

   [48]: http://www.w3.org/2009/dap/track/issues/116

   [49]: http://www.w3.org/2009/dap/track/issues/117

   [50]: http://www.brucelawson.co.uk/2012/specifying-which-camera-in-
getusermedia/

   [51]: http://www.w3.org/2009/dap/track/actions/open

   [52]: http://www.w3.org/2009/dap/track/issues/raised

   [53]: http://www.w3.org/2009/dap/track/issues/120

   [54]: http://www.w3.org/2009/dap/track/issues/122

   [55]: http://www.w3.org/2009/dap/track/issues/123

   [56]: http://www.w3.org/2009/dap/track/issues/124

   [57]: http://www.w3.org/2009/dap/track/actions/391

   [58]: https://www.w3.org/2009/dap/track/actions/open

   [59]: http://www.w3.org/2009/dap/track/actions/422

   [60]: http://www.w3.org/2009/dap/track/actions/459

   [61]: http://www.w3.org/2009/dap/track/actions/439

   [62]: http://lists.w3.org/Archives/Public/public-device-
apis/2011Aug/0006.html

   [63]: http://www.w3.org/2009/dap/track/actions/446

   [64]: http://www.w3.org/2009/dap/track/actions/464

   [65]: http://www.w3.org/2009/dap/track/actions/465

   [66]: http://www.w3.org/2009/dap/track/actions/468

   [67]: http://www.w3.org/2009/dap/track/actions/472

   [68]: http://www.w3.org/2009/dap/track/actions/473

   [69]: http://darobin.github.com/api-design-privacy/api-design-privacy.html

   [70]: http://www.w3.org/2009/dap/track/actions/483

   [71]: http://www.w3.org/2009/dap/track/actions/485

   [72]: http://www.w3.org/2009/dap/track/actions/510

   [73]: http://www.w3.org/2009/dap/track/actions/511

   [74]: http://www.w3.org/2009/dap/track/actions/512

   [75]: http://www.w3.org/2009/dap/track/actions/514

   [76]: http://www.w3.org/2009/dap/track/actions/516

   [77]: http://www.w3.org/2009/dap/track/actions/519

   [78]: http://www.w3.org/2009/dap/track/actions/520

   [79]: http://www.w3.org/2009/dap/track/actions/521

   [80]: http://www.w3.org/2009/dap/track/actions/522

   [81]: http://www.w3.org/2009/dap/track/actions/524

   [82]: http://www.w3.org/2009/dap/track/actions/528

   [83]: http://people.opera.com/richt/release/specs/discovery/Overview.html
#use-cases-and-requirements

   [84]: http://www.w3.org/2009/dap/track/actions/529

   [85]: http://www.w3.org/2009/dap/track/actions/532

   [86]: http://www.w3.org/2009/dap/track/actions/533

   [87]: http://www.w3.org/2009/dap/wiki/images/2/2e/20120711-WebIntentsLocalS
erviceDemo.pdf

   [88]: http://www.w3.org/2009/dap/track/actions/535

   [89]: http://www.w3.org/2009/dap/track/actions/544

   [90]: http://www.w3.org/2012/07/11-dap-minutes.html#action06

   [91]: http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_push_that_w
ould_create_multiple_heads

   [92]: http://www.w3.org/2012/10/TPAC/

   [93]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [94]: http://dev.w3.org/cvsweb/2002/scribe/