Device APIs Working Group F2F -- 02 Nov 2012

<dom> trackbot, start meeting

<trackbot> Date: 02 November 2012

<giuseppe> Scribe: giuseppe

<scribe> Scribenick: giuseppe

Privacy

<christine> Hi. Christine Runnegar (Internet Society and co-chair of the Privacy Interest Group (PING)).

<gmandyam> Giri Mandyam from Qualcomm Innovation Center (QuIC)

<bryan> i'll help, giuseppe

Jungkee: I'll start with the demo
... not the full demo like yesterday but I'll show the demo and the spec and we can discuss potential problems

<bryan> Jungkee Song, Samsung

Jungkee: pick contant and pick media intents
... they use web intents

fjh: should we explain what are we doing at high level first?

Jungkee: we want to retrieve contacts on local devices but also on remote services

<AnssiK> Pick Contacts Intent spec: http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html

Jungkee: (explains the demo)
... the code used for the demo is similar to the example code in the spec
... we use a pick action
... "ACTION: http://intents.w3.org/pick"
... type: "http://intents.w3c.org/type/contact"
... so we use pick intent and contact type
... after creating this intent the client call startActivity with this intent object
... when the user has selected a service and is in the service page
... then the callback is called on the client side
... let me show the Service part
... I'll show pick media since I didn't have time to add this to the pick contact spec
... but pick media is versy similar
... the service side call postResult with the result that wants to send back to the client

<npdoty> sees at least 4 different relevant parties: the user, the user agent, the client, the implementer of the service

Jungkee: after postResult is called, the callback is invoked in the client

<rigo> can someone post the URI of the Draft?

<richt> Contact Picker Intent draft

Jungkee: (goes through the attributes of the contact class)

<kensaku> Pick Media Intent draft

<npdoty> is this really a hint? the draft says "MUST NOT return defined fields on the contact objects that it provides other than those present in this list"

<AnssiK> Pick Contacts Intent Editor's Draft

<npdoty> although `search` is explicitly a hint, this seems like a hard requirement

<dom> +1 on npdoty

<AnssiK> [I think there are substantial changes from the published WD?]

dom: I think what is a hint is the search parameter, not the list of fields
... you can always limit which fields are returned
... if the service allows it the user can also select other fields

fjh: the question is what else can we do for privacy

rigo: I have questions
... afaiu you can use this for personal contact
... you can get contact from your devices but also use a directory service

Jungkee: yes

rigo: the distrinction you should made in your spec
... is that the attack model is different if you are using local contact or directory services
... we don't need to be prescriptive but we can provide guidelines, best practices

Josh_Soref: I don't think this is a really issue, a directory service should be really broken if it gives you back more than the user asked you
... so I don't think this is an issue in reality

<Zakim> Josh_Soref, you wanted to say i'm willing to give up removing the search bit as long as we rename the field to include `hint`

<Zakim> bryan, you wanted to suggest that we address overall service design guidelines outside the spec as needed

Josh_Soref: we cannot fix broken services

bryan: I think is good if we develop best practices

<fjh> http://www.w3.org/TR/2012/NOTE-app-privacy-bp-20120703/

bryan: we cannot prevent poorly designed services
... but the API is user driven, intended to optimize user experience

<dom> (in practice, any query-able directory service has already a way to prevent this kind of problem)

<npdoty> I agree that the Web Application Privacy Best Practices doc may be good to point to

rigo: ok, I get this, but still for web developers is important to understand the difference between accessing contacts from the device and contacts from the web

<npdoty> ... though perhaps it could be more specific for intent service implementers

rigo: in the second case, you have to deal with all sort of issues like why are they accessing these data, how long they want to keep them, what they want to do with them etc

<dom> [we need compatibility with vcard]

rigo: we should look into what ??? have done, they have a schema for contacts

<richt> The Web API Design Cookbook may be useful in this discussion also (based on our experiences designing these APIs) -> http://www.w3.org/TR/2012/NOTE-api-design-20121002/

Josh_Soref: we need to have compatibility with vcard format

<Zakim> npdoty, you wanted to ask are you sure it's required?

npdoty: I have few comments
... first of all the limit fields is an excellent practice

<rigo> is there use of https? I think that's the first thing the data protection authorities will ask for

npdoty: I think DAP has done some work for some API to be user initiatied
... we where talking about web intents in web apps early this week
... if they could be user initiated

<bryan> rigo, were you suggesting in your comments that we include intended uses (expressed by the app) and allowed/agreed uses (expressed by the user through the service provider) as parameters of the interface?

<rigo> bryan, only as a hint that you could do so using RDFa, not proscribing anything

npdoty: so question is: is always the app that starts the intent or is the user that initiates it?

<bryan> ok

GregBillock: yes now the spec says it needs to be user initiated

Josh_Soref: yes we need user initiated, but is not a MUST
... is user agent best practices, we cannot mandate what the user agent does
... the input field data model already have events, doesn't matter from where this content come from and should not be exposed to the web page

npdoty: I think there are 4 relevant parties, the user, the user agent, the client and the implementing service
... the privacy consideration section put different considerations on different parties
... but I'm not use if we address each one and if we address them in the same way

fjh: we don't have requirements for clients and user agents, we only have best practices because we decided that this is implementation dependent
... we are not making normative requirements on privacy, that of course limit how much you can enforice if ppl decide to ignore the best practices

npdoty: ok so the spec probably has some bugs since some section are marked as normative and some other seems to use a normative wording
... I've done an investigation on sites using geolocation and I've noticed that most of them don't use the best practices given by the geolocation spec
... maybe because they don't read the spec

Josh_Soref: I want to point out that there is a difference between the contact spec and the general web intents spec
... there's distinction between Contacts Intent spec and Intents general spec; a UA implementing Intents can and likely will not implement any random spec, and thus wouldn't know about any MUST/SHOULDs in that Intent, and wouldn't be involved unless it was one of the direct parties (e.g. <input type=tel> as a pick/contact intent magic source for
... Contacts)

npdoty: the last thing is a general design consideration, we have seen problems with the UI, i.e. is not always clear to the user the communication flow. in firefox OS or activities in android everything is modal so is a bit easier to understand
... but it may not be obvious when you have this model when you open a new tab
... and this get more complicated if you have multiple intents and then multiple tabs

fjh: I want to add that web intents has explicit intents
... that means you can compose multiple services and use them all in one app

<npdoty> my point is that it might help users to feel more comfortable using this sort of service if they have a clear understanding of where the data is going to go back to, which is harder when it's just several tabs

fjh: so for the user it looks like one app
... and there could be security issues there

<rigo> to fjh, we have to get the borders right. Privacy is only if it goes over the border to another controller

fjh: and privacy concerns, and may be different from the normal intents
... we may want to go back to that later

<npdoty> mounir: Sys Apps is also developing a Contacts API and we should make sure we coordinate with them

richt: I think is very unfortunate that we have replace the contact API with the pick intent based appraoch
... any chance we can bring it back?

dom: should be in cvs, we should be able to bring it back

<npdoty> are we talking about making sure it's the same data format? or replacing one API with another?

<rigo> s/proivacy/privacy/

richt: nothing bad with the old one, we did a lot of work

<fjh> In addition to using webintents to support user mediated selection of services, webintents supports the creation of composed apps that are created from a variety of services without user interaction - we may also wish to discuss privacy considerations of this

christine: is there any thinking that this pick contact intents can be used with services that are actually using other services to retrieve data

<fjh> takeaways - clarify privacy sections regarding what appear to be normative statements in an informative section, clarity regarding statements about various actors

christine: my question was to follow on on what you said on explicit intents

fjh: but they are actually more a client/app issue rather then service issue

christine: how you protect the data during your transaction

Josh_Soref: I have an open action item to decide if to mandate ssl or not
... but is difficult we can mandate it
... and we always receive push back when we try to enforce
... we cannot useful enforce it, so the answer is no
... the UA promise that the delivery is done in a trusted manner
... between the servive page and the client page

<fjh> rigo suggested rate limitation on service offering data

Josh_Soref: and is impossible to validate

rigo: I understand that iun some cases you don't want to use https, but I can assure you that you have problem with the autoirities if you transmit data over the wire without any guarntee of protection

<npdoty> it could be confusing that if I load a site over https and then I start using services and some of them aren't implemented over https, I might be upset that I thought I was accessing the web securely but really wasn't

rigo: so at least we need some recommendation on what to use in some cases

Josh_Soref: this probably needs to go in a best practice

<fjh> rigo asks if data can be transferred confidentiality - data protection requirement for transfer of data outside user sphere - need to provide hint or recommendation

<fjh> rigo - need a should to address concern

rigo: no, this is a conformance issue, if you have a SHOUL then if you have a good reason for not using SSL than is ok, but if you don't have a good reason for doing it then you are not conformant and the autirity can question you conformance with the spec

bryan: you cannot know what the service provider is doing with the data
... the UA has no way to track data

<Zakim> rigo, you wanted to suggest a hint for a presentation before sending, see demo again

dom: on the service provider side we should say what you are expected to do if you transmit confidential data

<fjh> rigo notes legal system can enforce it

richt: you can use a should and then we can forget about it because it's not technically enforceable and 'SHOULD' requirements are generally not useful.

<fjh> christine - groups are sensitive information as well

christine: my understanding is that the server is able to remember what the user does, which information was selected on which day
... (we are talking only about contact intents, not intents in general)
... a service can only know what is given to a user, not what other services are giving to the user, right?

Several_People: yes

Josh_Soref: unless the server is incestuous with those other providers

fjh: do we need to document this in the spec?

<Zakim> bryan, you wanted to ask why npdoty thinks that such information would benefit users, and not confuse them

<fjh> rigo - should have statement in spec to clarify that service providers do not have visibility into other data requested (need to clarify this)

rigo: if you write it as a normative statement into the spec everybody will have to implement it that way (about the same origin constraints)

bryan: yesterday we had a discussion about multiple tabs and it was clear that we need to do more work on the user exprience
... we cannot give too much info to the user on what's going on otherwise it could be even more confusin

npdoty: of course is not that more information is better, I agree.

<npdoty> npdoty: just that there is a privacy implication to that usability concern, that the user doesn't know where the data is going may make them lose data or make them hesitant to use intents if they don't know where the data is going back

fjh: we have been straggling on how to make privacy by design but we dont have anormative way to enforce it.
... maybe we need a normative way to document this

<Zakim> Josh_Soref, you wanted to note there's a risk of conflating Intents in general and Contacts Intent

<npdoty> we could help them -- pick and choose from these relevant privacy sections as are applicable to the data type that you are considering

rigo: personal information is the new money, so transmitting information is like transmitting money

<npdoty> Josh_Soref: if we had to have the same privacy text for every one of thousands of intents specs, that's not good as surely some of them will forget

rigo: so we need to be careful, so if you are working on a contact information you need to make sure to enforce a certain level of privacy enforced

Josh_Soref: I want to write it in the intents spec, not in each spec using intents

rigo: no way

fjh: maybe we should take this discussion offline

<npdoty> I think it might be overstating things to say that no one will ever bring a spec to w3c if we have a privacy discussion about it, but I agree that where we can make useful privacy considerations for all intents, that would be efficient

GregBillock: I think what the intents spec is missing is indication on how to guarantee privacy when you transmitts data from a service to a client

<timeless> s|s/priovacy/privacy/||

fjh: I think what you are saying is that the spec is pretty generic and we cannot anticipate what is going to happen
... so the user agent must be the trustee in the transaction

<fjh> greg notes that privacy restrictions would be an issue for debugging capability in production system to enable implementations

GregBillock: we cannot prohibit the UA to make available data to 3rd , because it can be useful for example to implement debuggin tools

<npdoty> do we have to ask the service to honor the data minimization? I thought the user agent could actually prohibit too much data

rigo: these are different issues, if you collect data for debugging that is fine, as far as you discard them later
... the concern is that several services can accomulate data from an individual over time

<npdoty> GregBillock, can't the user agent prohibit extra fields from flowing through this Intent?

Josh_Soref: we envision pass through validation intents

dcheng: is not useful to put normative text that we cannot test, since it will be useless -as was the case in GeoLocation where we mandated an explanation of how data was going to be used, and no one did anything for it

<rigo> made all my points, you have to get the terms for the actors right that participate in the contact intent scenario, give them consistent names and this will allow you to have a much clearer understanding of what's happening

<Zakim> npdoty, you wanted to ask about CSP

fjh: we may still need normative text for legal reasons even if we cannot test it

+1 to avoiding unverifiable requirements

Josh_Soref: we also envision Intent reputation services

npdoty: do we think that the contact security policy should give sites limitation on where the data are injected

Josh_Soref: data comes via a callback and the user has decided to approve that transaction
... is a client decision if he wants to trust intent service provided data
... to tag the data with the origin that it came from might itself be an additional privacy concern

fjh: there is a concern in the group that in the attempt to enforce privacy we put too many restriction or untestable requirements
... but there are also a regulatory requirements
... so we may want to discuss a bit more to find the right balance

<npdoty> I think Josh_Soref's response is probably right here, I was just throwing the origins/CSP idea out there

fjh: the second issue , if you look at the dap page, we have a list of specs that may or may not raise privacy concerns
... maybe we can talk with the privacy groups and review with them these specs
... we did some work on privacy and there are documents listed from the home page
... we don't need to repeat that work
... maybe we should consider to let the Ping WG to discuss this so we don't take time from this group

christine: sounds good but we want at least few experts from this group to help

<Zakim> fjh, you wanted to ask about other specs

<npdoty> fjh and Bryan volunteer to help

<Zakim> rigo, you wanted to discuss the demo thing

fjh: I can help

<scribe> scribe: I can help

<fjh> I suggest we continue privacy conversation in PING by looking at some of the other DAP specs to see which issues and suggestions might apply

<giuseppe> rigo: in your demo you pushed a button and got the data

<christine> Excellent idea to continue these privacy discussions in PING. Thank you Frederick. We very much appreciate the work DAP has already done on privacy and your offer to continue working on this with us.

<giuseppe> ... the user wants to know here these data are going

<fjh> I note that the WG has raised legitimate concerns about testability and ability to enforce normative privacy requirements that go beyond minimization - should discuss in PING how to suggest WGs add requirements on actors outside the implementers scope and do this in clear and usable manner.

<giuseppe> ... in general is a good idea to make clear who does what, who controls what and where the information flow

<npdoty> I want to ask about normative requirements and testing, but per dom I'll talk with people over coffee rather than add myself to the q

<fjh> q/?

<giuseppe> ... so the user can understand when to pay attention

<fjh> close queue

<giuseppe> Josh_Soref: note that producer doesn't know who is the consumer and the consumer doesn't know who is the producer

<giuseppe> ... and this is to guarantee privacy

<npdoty> PING has calls Thursdays once a month at 10am PT

<giuseppe> fjh: let me know who is intersted in joining the PING calls

<giuseppe> christine: we could have a call once a months, or more if you want

Josh_Soref: i could probably dial in

<christine> Everyone. Thank you for this very useful discussion.

<npdoty> if it were useful, we might be able to have dedicated PING calls if a group wants a particular privacy review of a document

<christine> Good idea Nick

<npdoty> +1, thanks to dap for talking with us, this was

<giuseppe> fjh: now break

<giuseppe> ... back in 30 minutes

<giuseppe> ... until 11

WebIntents Addendum - Local Services

<timeless> scribe: timeless

fjh: after lunch, Network Service Discovery
... then Search
... then Signage

Claes: how many of you were not at the break out session on Web Intents yesterday?

[ perhaps a dozen hands ]

Claes: i want to show this to you
... so you can see what we're doing
... the idea is to allow web apps to find a new service, situated anyway
... not just the cloud
... but also devices in the local network
... we experimented w/ extending Web Intents to find local services

[ Web Intents for local network services ]

<dom> WebIntents/SonyMobile - Local Network Service Discovery

[ Dynamic Service Registration 1]

<dom> slides Claes presented during the TPAC breakout

Claes: user presses `remote` button

[ Dynamic Service Registration 2]

[ Service Execution 1]

[ Service Execution 2]

Claes: service page implements low level communication stuff
... for communicating w/ TV/whatever

[ UPnP: SSDP Packet -> Notify ]

Claes: we added Web Intents ServiceType

[ UPnP: SSDP Packet -> Search ]

Claes: here's our experimental web page with the chromium implementation
... we select view
... here's the service picker
... we select that the tv
... the service page is displayed
... we control it in the service page
... and it plays back on the TV
... Another way is to receive the service page from the TV, and execute it in the background
... keeping control available to the Client
... here's an example
... i get a service page
... we used a JS shim
... now i'm able to control it from the client page
... it's doing work from the background

Josh_Soref: i like that implementation

sato: Pick image

[ Pic image ]

sato: Pick image from DSC (Digital Still Camera) to web service

<GregBillock> scribe has joined #dap

[ sato reads slide ]

[ Sony Cyber-Shot ]

[ My Memories Online ]

sato: you get a ui page from the DSC

dom: based on mDNS discovery?

sato: with some glue

fjh: how did you get to the web page w/ the camera?

sato: web intents service registration
... with Claes's impl
... local discovery protocol supports mDNS/SSDP
... the registration page returns url
... so browser knows the UI page to load

npdoty: the device is using a broadcast protocol to tell the browser
... and your camera is running a web server?

sato: yes yes
... but with a bit of fake

[ Demo ]

<npdoty> thx for the clarification

kensaku: Kensatu, QQQQ
... demo is just for existing devices

<Yoshiharu> s/QQQQ/from NTT communication

kensaku: this demonstration isn't for Addendum
... i have to leave after lunch
... demo with YouTube video and TV

[ Browser to TV demo ]

kensaku: this page is now controlling tv
... first you click service discovery
... find tv with upnp
... select devices and
... [loading...]

[ Diagram for the demo ]

kensaku: YouTube -> view activity video/mp4
... obtain server uri via explicit intent
... implemented background process
... connected with XHR2
... the background service uses a reverse proxy w/ DLNA to talk to TV via socket APIs
... but DLNA isn't enough
... but current devices have a restriction to talk to local services
... so i needed to use a reverse proxy to connect YouTube
... but flexibility to implement this would be great for future services
... so it's important to consider a sockets api
... perhaps a sysapps api for sockets
... thanks

richt: the TV was playing the demo

[ There's a TV in the center of the room

s/room/room ]/

[ the screen projecting the computer is at the far end of the room ]

[ some people foolishly had eyes only on the projected computer screen and speaker ]

[ and missed the TV showing the demo showing YouTube content ]

fjh: wanted to understand what you were saying w/ sysapps

richt: he was saying that this was something we'd look at there as well
... extra requirements for a reverse proxy
... not sure about here/just sysapps
... but sysapps will work on that

kensaku: current implementation uses (needs?) a socket api
... sysapps wg will be discussing a raw socket api

fjh: isn't there an api in webapps?

dom: that's WebSockets

richt: chrome has a Raw sockets api for chrome extensions

fjh: raw sockets in sysapps, websockets in webapps, intents in dap

<bryan> Josh_Soref: their TV needed to get the data, but only speaks HTTP

<bryan> ... so they needed a proxy to answer the HTTP GET and provide the data back from youtube

dom: so they built a web server in their browser?

Josh_Soref: yes

Claes: our demo shows how we can use WebIntents, but it requires WebIntents enabled devices
... even though those changes are quite minor
... [their demo allows for no changes to existing deployed DLNA TVs]
... there could be many choices if you use web intents
... you could use cloud service, or device on local network
... or whatever
... that's why we based our solution on web intents
... flexible choice about how to execute the service

<fjh> open queue

Claes: trying to hear WG's oppion

richt: i like this mechanism
... it's a bootstrap into web intents
... right now you have <intent> and discover by browsing
... this is another way to add other service providers
... it sits in this web intents model
... i can connect to this thing, but this device needs to speak web intents
... one thing w/ web intents, especially w/ Share
... is you have to open service page to share the video
... the web developer loses control over the direction of their UX
... they hand off control
... we [Opera] do differently
... is background with XHR
... but your bootstrap and control change is because it's WebIntents
... it isn't necessarily bad
... but it isn't UPnP/mDNS as we know it too

Claes: yes, with a visible page from the tv
... the web developer has less control over the tv
... but that may be an advantage
... the tv may have more options for the user
... the other alternative is a hidden service page
... which is our proposal
... which would leave control to the web developer

fjh: what are we trying to do in this session?
... seems like we decided we'll have more than one way to do

richt: no need to have competition
... don't want to debate one way or another

fjh: if we've learned things, we want to share
... if we have nothing to learn, we should end early
... what are you looking for?

Claes: i'd like feedback on the basic ideas
... looking for feedback on the spec

<richt> s/don't want to debate one way or another/don't want to debate one way or another. They address the use cases in different ways and can both be valid./

gmandyam: presumably there would be a socket spec
... we don't think there's a need
... it shouldn't be assumed there'd be a need for a new sockets api

fjh: you're saying sysapps may not provide a sockets api

gmandyam: we may not need Web Intents in sysapps

richt: raw sockets is building anything on top of TCP/UDP

dom: outside of scope for this group

<Zakim> nwidell, you wanted to request clarification on whether decision on "long-life intents" impacts on these proposals

nwidell: what's the impact of removing long lived intents
... will this still work?

Claes: in the second UC
... w/ the hidden service page
... control buttons in client starting page
... we have long lived connection between client and service
... we use Channel Messaging to send commands
... we use simple commands like "Play" "Pause"
... GregBillock, you said you weren't aware of an application using it
... we were using it for our demo

[ After invoke the service - hidden page will be provided by Service. ]

Claes: left is Browser w/ controls using channel messaging
... hidden page which talks to the tv

<bryan> overall, I think the UX will benefit from keeping control in the app page (and not a service page, just for a remote control function)

dom: does the new direction of web intents with a restriction on single shot exchanges problematic?

Claes: for having a UC where UI stays in client page, we need longer lasting relation with service page
... that's why we propose hidden

GregBillock: i wanted to talk about a couple of things
... FIFO/LIFO...

<bryan> if the use case is a remote control, and you need for example an indication of the video timeline, single shot exchanges will not work

[ laughter ]

GregBillock: relationship to network discovery mentioned by richt/Claes
... similar to relationship between getUserMedia and Media Capture
... in getUserMedia, client retains control
... in Media Capture, the client says "get back to me when you're done"

<richt> good analogy from GregBillock

GregBillock: i think the same division of UCs is present here
... second part to talk about
... long lived connections are right now because we pass structured clones through web intents
... the spec specifically supports transferables
... we mentioned UI issues for coordinating long lasting connections between tabs
... more difficult to address in UX of browser
... Web Intents spec may need to change
... to address these communications
... there's a legitimate reason to not allow that because we don't know how to do it in the UI
... this is a good example where it comes into play
... not exactly sure what the outcome will be of that thinking
... a profitable direction to explore
... is to think about casting Web Intent style interactions as Navigation style interactions
... window.open() which use url endpoints
... if you do long lived interaction, maybe you do url discovery and set that up w/ webMessaging
... we could build the kinds of UCs out of the ingredients that already exist
... not a concrete proposal
... it's a potential solution to problems we're facing
... leaves Request/Response stuff that we initially envisioned
... and fits nicely w/ this concept of delegation
... the generic UIs fit in request/response
... and don't lend themselves to long lived
... it's not a concrete proposal

fjh: action?

GregBillock: we spoke about this yesterday
... we'll hash this out
... what we'll do w/ web intents
... talk w/ web activities
... trying to address these in a way that's more concrete
... perhaps let's not exchange structured clones

Claes: we don't know where we'll end up w/ Web Intents
... but you understand the need for long lived connections

<npdoty> naively, it does seem like removing long-lived connections makes it easier to harmonize acitivities/intents proposals and to address the usability issues we've come across

Claes: but you don't think we'll have structured clones in web intents?

Josh_Soref: i think structured clones may drop from intents
... but you may get a url from web intnts
... and be able to use web messaging w/ that url

marcin_hanclik: we have a spec called CHTML

<Yoshiharu> s/intnts/intents/

marcin_hanclik: one of the most important aspects to discuss
... is the security

<jcdufourd> s/CHTML/CE-HTML/

<richt> marcin_hanclik, we're not allowing the web site to browse the whole network. There will be user opt-in at a per service level in both current proposals.

<richt> ...just to clarify that.

<richt> the UA will do the discover and broker the service provision to web pages.

bryan: i think it's better to keep UI in app rather than in service page if possible
... apps use a lot of external data + helpers
... using XHR, websockets, SSE
... apps like background bits
... i don't know users will like/understand modality

<npdoty> yay lunch!

<amy> great

<amy> please ping me if you need anything else

s/please ping me if you need anything else//

s|s/please ping me if you need anything else//||

Network Service Discovery

<richt> Latest published draft: http://www.w3.org/TR/2012/WD-discovery-api-20121004/

<richt> s/published draft:/published draft ->/

<richt> Network Service Discovery (NSD) API in Opera -> http://dev.opera.com/articles/view/network-service-discovery-api-support-in-opera/

<fjh> Chair: Frederick_Hirsch

s/Latest published draft //

<fjh> s/Chair: fjh/Chair: Frederick_Hirsch/

s|04/|04/ Latest published draft|

richt: the UA does the discovery
... using common available protocols from the network
... UPnP and ZeroConf
... ZeroConf is DNS SDP
... this draft abstracts away the underlying discovery protocol

s/Network Service Discovery (NSD) API in Opera //

s|a/|a/ Network Service Discovery (NSD) API in Opera|

scribe: the way the communication works it's URL based
... we've taken that as the underlying principle of this
... we're sharing URLs to be able to control services on the network
... when we have a URL, we can reuse the entire toolchain in browsers
... we can send messages w/ XHR
... you could use WebSockets
... you could do webMessaging
... it's a flexible thing
... we get a lot for free w/ URLs
... a lot of things we get for free are semantics
... we can hook into Status codes
... we want services using this to be able to hook into it with that level
... the url we get can be used in many different ways
... the spec today only allows XHR
... we need XHR because UPnP requires HTTP headers
... there's a special SOAP header
... don't blame me, not my design
... we need that ability, which is why we use XHR
... UPnP is sending messages w/ HTTP, it could work 10 times and fail on the 11th
... HTTP lets us catch that failed 11th w/ a timeout
... it's prescriptive about what's allowed
... it's not restrictive on what's allowed
... it allows exposing a control point URL
... you're aware of how you can use it
... based on the service type that exposed it
... one could be a WebSocket based service
... i setup a websocket service
... you could do UPnP over ZeroConf
... there's AirPlay, iTunes advertise over ZeroConf
... choose your messaging format, JSON, KeyValue pairs, whatever
... based on the URL system
... we can push URLs wherever
... there's a mechanism to whitelist the URLs
... there's only one API
... called getNetworkServices
... that's the entire API, it's one method
... it's important to minimize the impact on the DOM
... you get back a DOM object
... with lots of things
... between calling this and getting a response
... it goes through the UA/UI
... the UA makes the user opt in
... before anything returns

GregBillock: going beyond mDNS and UPnP
... we were thinking of other network service discovery
... could reuse this spec
... i didn't see rules for URL construction
... you have examples for UPnP/ZeroConf
... is there's a schema for others?

richt: it's extensible
... UPnP / ZeroConf aren't hard coded in
... you could have your own discovery protocols
... commonality is you get back a network service object
... how messaging works, you're requesting a specific service type

gmandyam: but how does a UA know which SDP is being used?

richt: if you want to communicate from a web page to a resource, you must use an HTTP url
... anything else will not work
... XHR won't work
... UDP resources wouldn't work
... there's a lose binding between what you're requesting and the messaging
... there's no rules beyond that
... either HTTP or not

gmandyam: Caching discovery results?
... do you have rules on freshness?
... or is that up to UAs?
... spec talks about not Caching
... we've had feedback about allowing preferences for services user has previously selected
... we hope to add that
... similar to GeoLoc

s/... spec/richt: spec/

gmandyam: for cellular, control point could be chatty
... some companies clearly violate specs in enumerating remote directories

richt: there's a lot of stuff out of scope
... this is a bootstrap
... we prototyped this
... we implemented it
... we published a version of Opera with this
... you have to switch it on in prefs, there's no ui
... a few restrictions
... only UPnP
... two No UI
... on via opera:config
... UPnP was the delivery for our TV team
... i see this as more for ZeroConf
... "btw, you can use UPnP on the side"
... both get abstracted to the same object
... ZeroConf is interesting because it's lightweight
... ZeroConf you can have JSON
... I can show a live demo

Opera Demo

richt: i've got a media server and xmbc on my mac
... before, kensaku did a demo
... now i'm browsing that media server
... that should work
... maybe not

gmandyam: there are implementations that query all the way down that directory tree
... even though the user didn't select thaat

s/thaat/

scribe: now the demo is playing
... i can control it in the app
... this is similar to getUserMedia
... you're responsible for more
... you have more control
... Intents is more the Media Capture

fjh: is this demo on your site?

[ richt plays music silently ]

<richt> Network Service Discovery (NSD) API in Opera -> http://dev.opera.com/articles/view/network-service-discovery-api-support-in-opera/

richt: there are some restrictions here, it isn't perfect
... we're investigating how much we can do w/ this model
... the api itself may change
... we have lots of feedback online, offline
... we may change how the api's look/respond
... we're trying to keep the underlying principles
... this is a proposal in that direction

Questions

<Zakim> Josh_Soref, you wanted to ask about lifetime for URLs

Josh_Soref: a problem HTML/MC/WebRTC/DAP had for URLs
... was lifetime
... ensuring the underlying resource could be GCd

richt: URLs have ways to say they expired
... we can do a 404
... at the point they're provided, they're live

Josh_Soref: i'm more worried about recycling of urls

richt: each message is separate
... you aren't creating a dialog across multiple request/responses
... i'm doing an action
... if the resource changes/moves
... and i hit a different resource
... i'm performing an action on the new one
... there's no concept of a session in this UPnP stuff

[ Concept of delete ]

richt: these services are meant to be interactive, but not with write support/delete
... they might have update and create new things
... you can't do that at the basic network level

GregBillock: cool richt
... i like using URLs as the interaction primitives
... couple of q's looking through the spec
... all relate to permission models
... when user is connecting up client to services
... how long lived is ...
... what are the semantics
... few ways this could work
... one is that when i get a network service
... i get permission to interact anything satisfying that query
... or only one for that selected one
... or i get back a geolocation style permission
... what's the permissions model?

richt: beyond what we want to do in W3C spec
... we don't want to restrict UI
... there's a clear approach we have in mind
... I request service type
... UA searches "network"
... finds devices with that service type
... user is presented w/ that list
... we don't authorize a service
... we authorize to a device
... "Google set top"
... "PS3"
... what page gets back is a specific binding for a service on a device
... if i request
... i can request a media renderer and an AV transport controller
... (the api allows 2 requests at a time)
... the user can select the PS3 which fulfills both
... spec requires user opt in

GregBillock: does permission persist across page sessions?

richt: right now, no

GregBillock: so, right now i want to control PS3 now
... and next time maybe something else?

richt: there might be a remember my preference option
... we'd auto-fulfill the request the next time
... we know if the service is online, offline
... you could get back 3 offline objects
... if there are devices still available

GregBillock: there's an overlap with the kind of service connection for web intents
... the selection process is the same hook me up together with my stuff
... my apps, tv tuner, router, whatever
... we may want to
... pick a division of labor between
... who's responsible for maintaining state of connections
... "where does the scan for wifi connection appear"
... network services have updates
... but if you want other services
... they'd hit "show more networks"
... in the client page?
... is it a long lived permission across loads
... or per task
... unlike geoloc permission

richt: it's about specific devices
... there's no normative restrictions on how you do this
... it's a UA design choice
... remembering services only
... it's a design choice

GregBillock: if the model is a persistent connection
... it might make sense to expose network services object directly to page
... the way it's written, it might not need that

jcdufourd: 4 questions
... you have top in navigator
... is object live?
... what about successive calls?
... our indexes kept/do they change?
... offline about exposing services?

richt: object is immutable
... once given, it doesn't change
... helps for more requests

<scribe> ... new requests give new objects

jcdufourd: successive network services objects
... if i have 3 objects
... and a fourth appears
... are the index id's the same or not?

richt: each object has an id
... it's unique enough to identify it within the session
... network services is an array like object

jcdufourd: why in navigator?

richt: don't care about where it goes
... parallel to getUserMedia
... similar signature
... same structure
... we didn't put it on window!
... but it's arbitrary, really
... this seems like a logical fit

fjh: we did this discussion before

richt: to death, think we have a note on it
... exposing services
... not getting too far ahead of ourselves
... we want to allow web pages to advertise itself on the network
... don't know if we'll do it
... navigator.registerNetworkService
... give it an identifier, receive incoming requests
... push requests
... it'll be ZeroConf only
... if you want to do UPnP service, there's a significant startup cost
... entire structure in an xml file
... we'll do DNS SD only
... reuse HTTP/urls
... we have a loopback address
... if you only want to advertise to your address
... i could use that
... i could use my network ip
... we've got public ip address as well
... not just about web pages
... i could advertise it to native apps too

jcdufourd: disagree about can't be done w/ UPnP
... but i'll work on that

fjh: what about confidentiality?

richt: i haven't seen UPnP services doing https
... but we can argue it's a url

youenn: we're very interested in this api
... first question
... seems very tied to local network
... is it related to local network
... or is it related to privacy?
... is it to avoid home-work network crossing?

richt: we have a Cross-Origin Resource Sharing
... if that service opts in w/ HTTP headers
... if a server allows it, we'll let sites do it
... this spec allows Reverse CORS
... user opts a site in
... spec goes in to how we whitelist the url
... for that user opted in service
... and subresources
... it's part of the proposal

youenn: if you get an error, it can point to anything
... in the spec, if you don't do upnp/zeroconf, you can get an error

richt: anything to be done will be done by UA
... it's all local network
... using loopback is local device
... DNS SD does wide area discovery
... my browser can look at dns when i go to google
... or mozilla
... and say there are services there too
... it's part of what we're saying

youenn: we did experiments
... enabling web as services
... it's very useful
... please continue this work

richt: please play w/ it, please give feedback
... don't think this is all it is

<GregBillock> I was going to ask, will you regret the name "NetworkServices" do you think? With the last couple questions?

richt: UPnP is a sideeffect

s/I was/GregBillock: I was/

Web Based Signage

hatano: Futomi Hatano, Newphoria Corporation
... we're new to W3C
... could the signage guys please join me
... i'd like to describe our requirements
... we're discussing Requirements for Web Based Signage
... we collected many requirements
... one relates to this WG
... i'd like to describe our requirements

[ Requirement R5 ]

<fjh> http://www.w3.org/community/websignage/

[ UC 1 ]

hatano: view same document shown on signage terminal at office
... small display, big room

<dom> Web-Based Signage use cases and requirements, R.5 service discovery

hatano: colleagues find displays in the room
... which can then display the app

<richt> s/UPnP is a sideeffect/UPnP is only one aspect of this API. I believe that Zeroconf is a much more flexible discovery protocol and will spur a lot of innovation. but, btw, you can also do UPnP./

[ UC 2 ]

hatano: viewer can't reach the displays showing display

<Shinji> Thanks! dom

hatano: viewer pulls out phone
... phone finds Signs nearby

<fjh> open queue

hatano: lets viewer see what's displayed on Sign

[ Motivation ]

<fjh> s/open queue//

[ Gap analysis ]

hatano: we found Web Intents and Network Service Discovery
... we'd like to know if they satisfy our requirements

richt: um
... i was talking about wide area service discovery

fjh: could you discover these signs with a web application?

<bryan> it will be difficult on a typical WAN to access signs that are inside a CDN service domain

bryan: typically there's a firewall

richt: isn't this kensaku's demo?

bryan: typically there's a service provider network

dom: that's the case currently
... but if there's a value to exposing them

bryan: so it's more than exposing devices

dom: i'm in this mall
... using WiFi network that's being provided for free

<richt> GregBillock, we may come to regret the naming 'NetworkServices'. Didn't want to use 'Services' though so...

dom: i'm in a position to discover nearby screens
... i see things nearby
... i can discover screen
... get information related to what the screen shows

shiyo: yes

bryan: i think it is

<Yoshiharu> s/shiyo/shigeo/

bryan: if you're at a meeting room of a conference on a lan

dom: some of this is beyond scope
... network topology
... but we can assume some topologies where you want to discover devies

s/devies/devices/

scribe: an interesting exercise would be to see how much of the UCs offered can be enabled by the apis

richt: a service that allows me to discover it
... maybe there's a queue
... or a way to give auth to project
... enable users in room to connect to service
... i think this is absolutely in scope
... this requires server side innovation

fjh: maybe for some portion of it
... in some cases, this may work straightforwardly
... in some cases external changes may be needed
... in some cases w/ Local network, it might just work w/o much effort
... in some cases, there may be some constraints

hatano: thank you for your time

[ Signage guys leave ]

<scribe> agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_1-2_November_TPAC_Lyon_France

Agenda Review

fjh: Pick Contact
... Pick Media
... Break
... CoreMob update
... Media Capture / Streams
... Calendar
... Issues + Action Review
... Sensors

s/CoreMob/Testing + CoreMob/

hta: I have an item
... i'm leaving @ 3:15pm

Media Capture / Streams

fjh: great work, thanks

[ Update from Media Capture Task Force ]

Travis: Travis Leithead
... just a brief update
... i'll send a link to the slides to the DAP ML later
... not going to talk about HTML MC
... not going to talk about WebRTC document
... (sorry about the blue text)
... MC TF is looking at 4 documents since last year's TPAC
... 1. Media Stream Captures Scenarios
... 2. getUserMedia "Media Capture and Streams"
... 3. Track Enhancements and snap photos
... 4. XXQ

MediaStream Capture Scenarios

Travis: it describes 6 scenarios
... photo + audio capture
... video + audio together
... streamed
... retrieve modify camera capabilities / switch cameras
... pause resume capture
... peer to peer streaming
... - Issues
... we'll remove "design considerations"
... by converting them into Requirements/enhancing Scenarios
... many things in there are addressed by TF

Media Capture and Streams (getUserMedia)

Travis: we now have a complex first parameter (constraints)
... getUserMedia(constraints, successCallback, failureCallback)
... constraints have ordered optional constaints
... and mandatory constraints
... UA will evaluate constraints and decide what you could be given
... MediaStream object is defined in spec
... used for RealTime Streaming and Local capture
... separate audio/video tracks
... concept of generic track
... - Issues
... slightly underspecified
... directly assigned to video elements or view URL.createObjectURL()

<richt> s/DNS SDP/DNS-SD/

Travis: -- lifetime issues

Settings API (proposal)

Travis: puts control at Track level
... instead of stream
... we split tracks into distinct kinds
... video, audio, camera, microphone
... settings/capabilities live on tracks
... drops Local Media Stream
... defines Take Picture API
... provides a device list
... - Issues
... Applying settings via an interesting api path
... may want to move closer to constraints model
... Privacy/Fingerprinting implications of device list
... making it into reality is tricky

Recording API (proposal)

UNKNOWN_SPEAKER: g

s/g/get data at end/

scribe: get data incrementally
... - Issues
... track level v. Stream
... Audio/Video together?
... Group would like them together
... complications involving MediaStreams and recording
... state machine
... adding/removing tracks to/from a Stream
... or dynamic setting changes (resolution)
... Container format constraints

fjh: refactoring Tracks looks good
... for Privacy/Fingerprinting discussion
... should we involve PING?
... if someone from TF could join a PING call
... it might help resolve it

Travis: +1
... someone from TF should set that up

<richt> s/how does a UA know which SDP/how does a UA know which control protocol/

hta: chairs will take it under advisement
... we attended XXE
... some people say if you can run JS, it's game over
... not everyone has given up yet

fjh: PING is the privacy people

Travis: talking to them, seeking their advice may not be entirely wasted

fjh: anything DAP needs to do?

<dom> [I think the risk with listing devices is not only a fingerprinting issue http://lists.w3.org/Archives/Public/public-media-capture/2012Oct/0047.html ]

Travis: i think we're ok

fjh: join Media Cap TF/ML

dom: at session on Wednesday
... there was a discussion

Travis: very interesting discussions
... my presentation didn't capture the latest thinking

<dom> s/Wednesday/Tuesday afternoon

hta: we found cases where we couldn't wait for response from users

<dom> s/a discussion/a discussion that might lead to fairly important changes to getUserMedia

Pick Contacts

fjh: did the CfC for removing search

PROPOSED RESOLUTION: Keep search

Jungkee: i think we reached a consensus

<Jungkee> contact search option: http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html#idl-def-ContactIntentExtras

<Jungkee> media search option: http://dvcs.w3.org/hg/dap/raw-file/tip/gallery/Overview.html#idl-def-MediaIntentExtras

Josh_Soref: i want to change the property to be searchHint

nwidell: we moved extras from Intents
... where's the replacement?

Jungkee: i think we add the attributes in the Intent

GregBillock: you put it in the Intent object
... but extras disappeared
... i'd put the metadata in the type itself

s/type/data schema/

<dom> data field in Intent object

<GregBillock> So new Intent({ ACTION: x, type: y, data: { query_info: { fields: ["displayName", ...], query: "query_hint" } } })

<GregBillock> so that means dictionary Contact { ... ContactIntentExtras? query_hints }

<Jungkee> new Intent({ ACTION: "http://intents.w3.org/pick", type: "http://intents.w3.org/type/contact", data: { fields: ["displayName", "emails"] }});

<GregBillock> LGTM

PROPOSED RESOLUTION: field and searchhint move to data

<fjh> propose RESOLUTION: retain search in Pick Contacts using a dictionary in the data for this information

PROPOSED RESOLUTION: Pick Contacts using dictionary in for searchhint and field restrictions

nwidell: search or filter?

Jungkee: two capabilities
... 1. who they're looking for (roughly)
... 2. what they want to know about that entity

<dom> +1 to proposed resolution

PROPOSED RESOLUTION: Pick Contacts and Pick Media using dictionary in for searchhint and field restrictions

PROPOSED RESOLUTION: Pick Contacts and Pick Media using dictionary for searchhint and field restrictions

PROPOSED RESOLUTION: Pick Contacts and Pick Media using dictionary for searchhint and field restrictions (field on media if applicable)

RESOLUTION: Pick Contacts and Pick Media using dictionary for searchhint and field restrictions (field on media if applicable)

[ Break ]

HTML Media Capture

<fjh> I checked with the W3C team - we can publish a LC even during an exclusion period, no problem.

Pick Media Intent

<Jungkee> metadata: http://dvcs.w3.org/hg/dap/raw-file/tip/gallery/Overview.html#metadata-properties

<bryan> scribenick: bryan

Jungkee: would like to get feedback on the list on this link, after the F2F
... want to explain the criteria
... considered a number of platforms and services
... group review on the metadata definition, with feedback is requested

<Zakim> fjh, you wanted to ask if this metatdata has been defined as standard elsewhere as to meaning

fjh: see you have picked the core from the metadata of different specs

Jungkee: refer to a core set of media ontology specs
... media ontology core has 29 properties, most included here
... som core properties are not used in real life
... those have been excluded

<Jungkee> http://www.w3.org/TR/mediaont-10/#core-property-lists

gmandyam: why did you not go with an approach like Tizen media content?

Jungkee: in Tizen 2.0 we dropped a lot of the media metadata functionality
... we just need some practical properties used in real life

gmandyam: it would be desirable for sysapps to reference an actual spec (they are looking to the Tizen media spec)
... would like to bring this to SysApps for possible use in the gallery API to be done there
... Google has an exploratory API, Mozilla has one also

bryan: is there a similar prevalent metadata spec for media as Vcard is for contacts?

richt: the mozilla version has a slightly different list
... we should avoid a long process since we will never get it right anyway

Jungkee: we will try to align the data as much as possible

richt: another approach is just to define a container, and not define the details

bryan: do you need a format attribute

richt: no, it would be a JSON object
... developers want to have agreement and to do it themselves

nwidell: given this will be behind web intents, should be ensure the attributes are consistent with what is typically used in other intents?

Jungkee: that's where I need feedback. I tried to abstract some of the properties
... it will be a more practical approach e.g. in section 5.x in which you can extend the dictionary with a prefix
... in the demo it gets a practical (actually used) data as examples

interop & testing

dom: there are some discussions on structure of the repository
... that is being revised in the testing IG, and changes in how tests are approved may result

<richt> s/developers want to have agreement and to do it themselves/developers want to have agreement and to do it themselves. It's in their interest to agree on a structure but this DAP group has previously rejected this approach./

dom: these are W3C-wide discussions, but what matters is implementing, writing, and reviewing tests
... key is focusing on getting to CR

CoreMob update

gmandyam: (introduces CoreMob)
... F2F in London in Oct, with a few results
... http://rng.io
... is the URI for Ringmark
... initially looking at converting Ringmark into conformance specs, the group is revisiting that with use cases and reqs
... no draft of that yet, hopefully use cases that are complementary will result
... other things of interest, the group is going back to FB's original research
... a pretty good set of data
... we will not be targeting performance for the 1st release, CoreMob 2012

fjh: why go back to use cases and requirements?

gmandyam: it was a mistake, using Ringmark as the basis, as they had to justify the Ring 0 vs Ring 1 etc
... Ringmark is useful but we needed more care in the criteria

<timeless> s/gmandyam:/gmandyam:/

Josh_Soref: they went back as the UC & Reqs weren't developed, and there was no explanation of where they had arrived
... this was a big lesson, to document the problem being addressed
... Ring 0 vs 1 was a side topic
... FB contributed the research, but we focused on the Ringmark tests instead, and that side-trcked us from the useful things
... so the initial input (their analysis) got buried
... and the chain of relevance was not defined
... organization issues also got in the way

fjh: what's the plan with DAP, will they be included some time? who makes that happen?

<timeless> s/trcked/tracked/

dom: DAP does not have to worry or do it. DAP may need to answer queries as to the APIs that have been defined per CoreMob priorities

Josh_Soref: e.g. it was found there were no real-world use cases for the battery API
... the original idea was to build upon the lower rings but the specs are not dependent in the way that supports that
... probably will address the use cases individually

bryan: the HTML Media Capture was listed as a key API

<timeless> bryan: one UC was capturing of images and file upload

<timeless> s/timeless/scribe/

<timeless> bryan: that was the one API listed by coremob

<timeless> s/timeless/scribe/

sensors

<timeless> ?Q

<timeless> s/?Q//

nwidell: 1 year ago we discussed sensor APIs and there was a decision to move ahead with Web Intents based sensors, until the DOM based sensor proposals came from Mozilla
... are we interested in local network sensors? the Web Intents approach did not seem to work out
... the other case was doing everything yourself

fjh: not sure what us being asked for

nwidell: a generic sensor API is in the charter, and there are a lot of use cases for sensors not on the device
... these might be discoverable via some networking; also use cases for sensors in the car
... on the browser side, this would have to be a generic API

richt: the 1st step is use cases, then we agree, but network service discovery could be useful for the networked sensors use cases
... there are a lot of use cases for networked sensors

<fjh> +1 to documenting use cases to understand the approach

richt: e.g. (showing use cases)
... fitness, devices without integrated sensors (as users of externa sensors), home sensors
... we can't connect all the dots, but we can provide a framework for the client side
... since the Web is maturing as a platform, providing these adapters is a good thing
... 1st though is whether there is a priority in anything beyond device-local sensors

<Zakim> Josh_Soref, you wanted to talk about sensors in Cars

Josh_Soref: W3C is wrapping up a car-focused activity; we are also having people talking about running apps anywhere
... the phone might be in the glove box or a dock, displaying on the car screen

<fjh> josh_soref: also about displaying anyway, like signage

Josh_Soref: if the phone is in the glove box and it's dark, the phone can't use its own sensor, and the car may need to provide the sensor for this case
... it would be nice for the phone to be able to use the car screen, and the car's light sensor
... I see a need for this, and considering how Intents mght enable this
... re the roadmap for the car stuff, it may be a bit longer as the lifecycle and time to market is longer

<timeless> s/wrapping/ramping/

Claes: I wanted to say the same things
... I think we shoud start on this

gmandyam: it's good to take a step back, consider alternatives, e.g. HTTP to COAP mapping. what's nice is no change in the browser
... it would be good to take a step back and explain why other industry efforts are insufficent

richt: a number of issues need to be discussed first
... discovery, configuration, interaction (an interface available)?
... without this, it is purely theoretical

<timeless> s/COAP/CoAP/

richt: the UPnP specs provide nothing, some lighting and HVAC

<timeless> CoAP

<timeless> s/timeless/gmandyam/

richt: is the remote sensors industry ready for this? there is a lot of underlying work needed first

nwidell: this is a rapid developer market, mapping to technolgies may not be clear, but it would be good to have this on the agrenda

<timeless> M2M

<timeless> s/timeless/nwidell/

richt: there is a lot to be done outside the Web, and that isn't happening

nwidell: it is happening

dom: it's clear that its coming and we should be ready, but that it's preliminary

<timeless> s/its coming/it's coming/

<richt> s/there is a lot to be done outside the Web, and that isn't happening/there is a lot to be done outside the Web, and that is not ubiquitous today./

dom: the big picture of the need for standards needs to clearer

nwidell: we sure dont want one web solution per underlying technology

<fjh> dom it is too early for specification work, but worthwhile to understand ecosystem and environmnet

Josh_Soref: re monitors, they are using Bluetooth or USB, probably serial protocols
... I assert that there is an app running on those systems that implements the proprietary protocol
... a local service may be running which is exposable via intents

richt: that seems somewhat hacky; someone needs to do the normalization work
... a lot of work needed outside the Web and W3C first

dom: my view is that this will soon be fundamental and I hope the Web can be part of that space
... I would suggest a landscape document

<fjh> +1

<richt> whatever you invent, make it discoverable.

<timeless> s/dont/don't/

bryan: i gave a presentation recently at OMA re this, an the result was that these are very interesting (for mHealth) but we probably need some time for the basic market to develop

dom: the landscape document would help establish what is out there, what is compatible with the Web platform, etc

<richt> you need to want to be part of the web. Requiring proprietary middleware to talk to proprietary sensors over USB is not an indication you (*) want to be a part of the web right now.

<richt> * = sensors.

<fjh> nwidell: discovery, registration, communication problems need to be solved first

dom: this space is big/diverse/fast

nwidell: happy to take an action, but if we don't intend to do anything it may be a waste of effort

<fjh> ACTION: nwidell to provide draft sensors landscape document [recorded in http://www.w3.org/2012/11/02-dap-minutes.html#action01]

<trackbot> Created ACTION-592 - Provide draft sensors landscape document [on Niklas Widell - due 2012-11-09].

dom: if we don't get the information needed, we surely won't be doing anything

http://www.openmobilealliance.org/comms/documents/bangkok_presentations/OMA%20Healthcare%20Workshop%20-%20A%20Web%20of%20mHealth%20Devices.pptx.pdf

calendar API

fjh: we don't seem to be able to move this forward, due to the extended discussions around contacts

bryan: I agree we should get one good intent out the door as a model first

fjh: the calendar recurrence model still seems an issue, we had other problems, etc that have not been addressed in the earlier versions

dom: we can consider the next F2F

fjh: we were in Mass last time

dom: we can't make a decision now, but early April or March might be OK, will consider via an action

<dom> ACTION: dom to build a survey for finding a week for DAP meeting March/April [recorded in http://www.w3.org/2012/11/02-dap-minutes.html#action02]

<trackbot> Created ACTION-593 - Build a survey for finding a week for DAP meeting March/April [on Dominique Hazaël-Massieux - due 2012-11-09].

Actions

<fjh> action-588: I checked with the W3C team - we can publish a LC even during an exclusion period

<trackbot> ACTION-588 Review exclusion period for Ambient light notes added

<fjh> close ACTION-588

<trackbot> ACTION-588 Review exclusion period for Ambient light closed

Other Business

<fjh> thank you everyone for a productive F2F. Thanks to the scribes, Josh, Bryan, Rich, Giusseppe

<fjh> rrs, generate minutes

<fjh> s|rrs, generate minutes||

<timeless> s/... get data at end/Travis: get data at end/

- DRAFT -

Device APIs Working Group F2F

02 Nov 2012

Attendees

Contents