See also: IRC log
<trackbot> Date: 11 July 2012
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/
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/
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]
<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
<richt> Draft spec
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
<richt> and http://people.opera.com/richt/release/specs/discovery/tpac2011_servicediscovery_ui_2.png
[ 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
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"
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
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]
<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
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/
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>
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
<darobin> The Network Information API
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:
<darobin> Vodafone's Comments about Network Information API
<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
<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
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 ]
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/
<fjh> http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html
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]
<trackbot> Created ACTION-557 - Ping DougT about light sensor to see if there's interest [on Robin Berjon - due 2012-07-18].
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
<fjh> Media Capture and Streams WD, http://www.w3.org/TR/2012/WD-mediacapture-streams-20120628/
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
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]
<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]
<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
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]
fjh: i don't think there's anything to do tomorrow
... the agenda has Issues, action 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
<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
<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/
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
<fjh> http://www.w3.org/2009/dap/track/actions/open
<fjh> http://www.w3.org/2009/dap/track/issues/raised
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
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
<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
<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
<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-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
<fjh> https://www.w3.org/2009/dap/track/actions/open
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
<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
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
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 -- due 2011-08-24 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/446
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
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
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
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
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
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
fjh: darobin and i just coordinated
<darobin> http://darobin.github.com/api-design-privacy/api-design-privacy.html
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
<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
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
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
<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
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
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
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
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
<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
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
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
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
<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
<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
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
<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
<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
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
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/images/2/2e/20120711-WebIntentsLocalServiceDemo.pdf
<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
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
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]
<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_that_would_create_multiple_heads
Josh_Soref: yay!
<Cathy> http://www.w3.org/2012/10/TPAC/
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
<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
<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
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
